Что такое столбец базы данных

Что такое столбцовая (колоночная) база данных?

В столбцовой БД данные каждого столбца хранятся отдельно (независимо) от других столбцов. Такой принцип хранения позволяет при выполнении запроса считывать с диска данные только тех столбцов, которые непосредственно участвуют в этом запросе. Обратная сторона такого принципа хранения заключается в том, что выполнение операций над строками становится более затратным. ClickHouse — типичный пример столбцовой СУБД.

Ключевые преимущества столбцовой СУБД:

• выполнение запросов над отдельными столбцами таблицы, а не над всей таблицей сразу;
• агрегация запросов на больших объемах данных;
• сжатие данных в столбцах.

Ниже — иллюстрация того, как извлекаются данные для отчетов при использовании обычной строковой СУБД и столбцовой СУБД:

Стандартная строковая СУБД

Столбцовая СУБД

Для аналитических приложений столбцовые СУБД предпочтительнее, так как в них можно хранить много столбцов в таблице просто на всякий случай, и это не будет сказываться на скорости чтения данных. Столбцовые СУБД предназначены для обработки и хранения больших данных. Они прекрасно масштабируются при помощи распределенных кластеров на относительно недорогих серверах — для увеличения производительности. В ClickHouse для этого используются распределенные и реплицированные таблицы.

Структура баз данных — Основы SQL

Почти все приложения работают с большим количеством информации, которая хранится в виде таблиц в базах данных.

В этом уроке мы более подробно поговорим о структурах и выясним, как устроены таблицы и базы данных.

Что такое таблица

Рассмотрим для примера Хекслет. Мы храним информацию о студентах и о курсах. При этом нужно разнести информацию по двум разным таблицам, чтобы было удобно работать. Другими словами, в разных таблицах мы храним разные сущности.

В базе данных Хекслета сущность «Студенты» будет храниться в одной таблице, сущность «Курсы» — в другой.

Сама таблица представляет собой набор столбцов и строк. Пересечение столбца и строки — это ячейка.

В таблице «Студенты» каждая строка содержит в себе информацию об одном конкретном человеке. Еще строки называют записями.

Каждый столбец определяет, какого типа данные хранятся в ячейке, например:

• Имя
• Фамилия
• Год рождения
• Дата регистрации

Еще столбцы иногда называют полями.

Таблица с данными студентов Хекслета может выглядеть так:

Таблицы в базах данных

Многие привычные приложения содержат десятки, сотни и тысячи таблиц с разнообразными данными.

Чтобы всем было удобно работать с такими объемами данных, к таблицам предъявляются конкретные требования:

• Название таблицы. Оно должно быть уникально в рамках одной базы данных. Название таблицы мы задаем при создании, но его можно изменить при необходимости
• Столбцы или поля. У каждого поля уникальное имя в рамках одной таблицы
• Тип данных столбца. Он ограничивает набор допустимых значений, которые можно присвоить столбцу. Например, в столбец числового типа нельзя записать текстовые строки. Тип данных присваивается каждому столбцу
• Строки или записи. Их количество в разных таблицах сильно отличается — от нескольких штук до миллиардов записей. В базах данных нет никаких гарантий относительно порядка строк в таблице

Базы данных, в которых данные хранятся в виде таких таблиц, называются реляционными базами данных. Работать с ними можно с помощью реляционных СУБД.

Структура таблиц

Таким образом, каждая таблица должна иметь определенную структуру.

Эта структура определяет столбцы и включает в себя имена полей и их типы:

first_name string last_name string email string created_at datetime

Рассмотрим этот пример подробнее. В нем прописаны названия полей и типы:

• Поля first_name , last_name и email содержат обычный текст, поэтому мы задаем тип данных string (строки)
• В поле created_at мы сохраняем дату добавления пользователя в систему. Для этого поля установлен тип данных datetime , поэтому туда нельзя записать текст

Вот такую таблицу мы можем создать с этими полями:

Что такое столбец базы данных

5.4.1. Реляционные базы данных

Все реляционные базы данных используют в качестве модели хранения данных двумерные таблицы. Эта модель выбрана потому что она в основном знакома всем пользователям и рассматривается как «естественный» путь представления данных. Любая система данных, не имеет значения какой сложности, может быть сведена к набору таблиц (или «отношений» в терминологии СУРБД) с некоторой избыточностью. Избыточность контролируется путем приведения отношений к канонической «нормальной» форме, которая минимизирует ненужную избыточность без уменьшения связей между элементами данных.

1. Каждое отношение (таблица) может быть представлено в виде прямоугольного массива со следующими свойствами:
2. Каждая ячейка в таблице представляет точно один элемент данных; нет повторяющихся групп.
3. Каждая таблица имеет однородные столбцы; все элементы в любом из столбцов одного и того же вида.
4. Каждому столбцу назначено определенное имя.
5. Все строки различны; дублировать строки не разрешается.
6. И строки, и столбцы не зависят от последовательности; просмотр в различной последовательности не может изменить информационное содержание отношения.

Каждая строка олицетворяет уникальный элемент данных, который ею и описывается.

Столбцы представляют собой отдельные куски информации (атрибуты данных), которые известны о данном элементе. Строки обычно называют записями, а столбцы — полями.

Кроме того, для обработки отношений разрешены только следующие операции:

1. Добавить и Удалить запись. (Редактирование косвенно разрешено в виде конкатенации операций «Добавить» и «Удалить»)
2. Соединение (при котором временное отношение создается путем соединения информации двух отношений, используя общие поля).
3. Выборка (в которой выбирается подмножество записей в отношении, основываясь на определенных значениях или ряде значений в выбранных полях).

Другие операции с данными обычно не поддерживаются в базах с реляционной структурой. Добавление произвольных данных, которые, например, не соответствуют ни одному полю в описании данных, запрещено. Добавление поля для произвольных данных потребовало бы перестройки (реструктурирования) базы данных. А этот, зачастую очень длительный, процесс может выполняться только когда базой данных никто не пользуется.

Вообще, лишь немногие реальные базы данных могут быть описаны при помощи единственной таблицы. Большинство приложений используют множество таблиц, которые содержат столбцы (поля) с одинаковым именем. Эти общие данные позволяют объединяя две (или несколько) таблицы, строить осмысленные ассоциации. Лучше всего это иллюстрируется примером. Рассмотрим два отношения » Служащий » и » Отдел «, показанные на рис.5.14.

Рис. 5.14. Отношения «Служащий» и «Отдел».

В этом примере поля Номер Служащего и Номер Отдела выделены; это указывает на то, что эти поля — первичные ключи. Это означает, что элементы данных в этих полях единственным образом определяют запись (т.е. никакие две записи не имеют одинакового элемента данных в ключевом поле). Более того, поле N отдела обнаруживается в обеих таблицах. Это позволяет объединить две таблицы таким образом, чтобы, например, определять Название отдела для любого заданного Служащего .

Во многих случаях это объединение не такое простое. Предположим, нам требуется найти способ для определения, кто является Руководителем для любого Служащего . Мы могли бы создать следующую структуру данных (рис.5.15).

Эта на вид интуитивная структура может вызвать проблемы из-за избыточности связи отношения «Руководитель», связанного с отношением «Служащий» как напрямую, так и через отношение «Отдел». Эта избыточность позволяет руководителю служащего отличаться от руководителя отдела служащего. Если это не разрешено, то приведенная структура таблиц не подходит.

Рис. 5.15. Отношения «Служащий», «Отдел» и «Руководитель».

Вместо нее более подходящей была бы структура, представленная на рис.5.16.

Эта структура удаляет избыточность, которая позволяет Служащему иметь Руководителя , отличного от Руководителя его Отдела . Но делая это, она удаляет прямую связь, которая может быть желательна с точки зрения производительности больших баз данных. Эта взаимосвязь между производительностью и целостностью данных присутствует фактически во всех моделях баз данных.

Простой реальный пример может потребовать еще более сложной структуры.

Пусть Служащий является членом более чем одного Отдела . Правила соединения в реляционных базах данных не разрешают связей «многие-ко-многим» (которые можно обозначить при помощи стрелки с двойным указателем на каждом конце). Чтобы представить отношение с такими связями (например, каждый Отдел имеет многочисленных Служащих и каждый Служащий может быть членом Многочисленных Отделов ), нам надо создать отдельное отношение, которое является гибридом двух столбцов (рис.5.17):

Рис. 5.17. Отношения «Служащий», «Назначение»,

«Отдел» и «Руководитель».

Здесь отношение » Назначение » содержит запись для каждого отдела, сотрудником которого является служащий. То есть, если Служащий работает в Отделе , то соответствующие Номер Служащего и Номер отдела обнаруживаются точно в одной записи отношения » Назначение «. Поле Номер Назначения фактически не нужно, так как Номер Служащего и Номер Отдела могут вместе служить ключем. В большинстве (но не во всех) СУРБД разрешены отношения с составными ключами. Для тех из них, в которых ключ должен быть представлен обязательно одним полем, структура будет такой, как представлена выше.

«Естественный подход» с использованием таблиц может оказаться еще более «притянутым за уши», когда данные — разреженные. Разреженные данные означают, что не каждое поле в каждой записи содержит данные. В некоторых приложениях данные очень разреженные — только несколько из большого числа столбцов, определенных для данного отношения, могут содержать данные в каком-либо заданном ряду. Если в реальном приложении типично, что данные разреженные, то обычно пользователь не рассматривает их как табличные. Например, представим отношение, описывающее посещение пациентом врача. Оно может иметь поля, которые содержат результаты обследования: радиограмма, ультразвук, температура, вес и т.д. Большинство из этих полей может быть пусто для какого-либо пациента. Представить их в качестве полей таблицы в лучшем случае противоестественно. Более естественно представить эти данные в виде списка элементов, чем в качестве полей таблицы. Воплотить в жизнь эту точку зрения пользователя в реляционной базе данных нелегко. Эти различные элементы нельзя занести в одну таблицу, так как они нарушают однородность столбца — данные, хранящиеся в полях, не все одного типа, как это требуется в реляционных таблицах.

Реляционные базы данных были бы совсем непригодны, если бы эти разреженные данные действительно хранились внутри прямоугольного массива, так как для этих пустых элементов данных надо было бы выделять пространство. В действительности, большинство современных СУРБД используют таблицы как «логические» структуры, но в качестве внутренних «физических» структур используют структуры, которые могут хранить редкие данные более эффективным способом, таким как В-дерево. Выбор физической структуры иногда предоставляется разработчику БД как возможность оптимизации производительности.

Что такое столбчатая база данных?

Столбчатые базы данных в сравнении с реляционными базами данных

Реляционные базы данных оптимизированы для хранения строк данных и применяются, как правило, для транзакционных приложений. Столбчатые базы данных оптимизированы для быстрого извлечения столбцов данных и применяются, как правило, в аналитических приложениях. Использование столбчатых таблиц баз данных для хранения оказывает большое влияние на производительность аналитических запросов, поскольку значительно снижает общие требования к операциям дискового ввода-вывода и сокращает объем данных, которые требуется загружать с диска.

Как и другие базы данных NoSQL, столбчатые базы данных предназначены для горизонтального масштабирования с использованием распределенных кластеров недорогого оборудования для увеличения пропускной способности, что делает их идеальным решением для хранения данных и обработки больших данных.