Войти
A Столбцовую СУБД (или систему управления столбцовыми базами данных) система управления базами данных (СУБД), которая хранит таблицы данных по столбцу, а не по строкам. Практическое использование хранилища столбцов и хранилища строк мало отличается в мире реляционных СУБД. И столбчатые, и строковые базы данных могут использовать традиционные языки запросов к базам данных, такие как SQL, для загрузки данных и выполнения запросов. И строковые, и столбцовые базы данных могут стать основой в системе для обслуживания данных для общих инструментов извлечения, преобразования, загрузки (ETL) и визуализации данных. Однако, сохраняя данные в столбцах, а не в строках, база данных может более точно обращаться к данным, которые необходимы для ответа на запрос, а не сканировать и отбрасывать нежелательные данные в строках.
Система управления реляционной базой данных предоставляет данные, которые представляют собой двумерную таблицу, состоящую из столбцов и строк. Например, в базе данных может быть такая таблица:
| RowId | EmpId | Lastname | Firstname | Salary |
|---|---|---|---|---|
| 001 | 10 | Смит | Джо | 60000 |
| 002 | 12 | Джонс | Мэри | 80000 |
| 003 | 11 | Джонсон | Кэти | 94000 |
| 004 | 22 | Джонс | Боб | 55000 |
Эта простая таблица включает идентификатор сотрудника (EmpId), поля имени (Фамилия и Имя) и зарплату (Salary). Этот двухмерный формат является абстракцией. В реальной реализации аппаратное обеспечение хранения требует, чтобы данные были сериализованы в ту или иную форму.
Самыми дорогостоящими операциями с жесткими дисками являются поиски. Для повышения общей производительности связанные данные следует хранить таким образом, чтобы минимизировать количество поисков. Это известно как место ссылки, и основная концепция появляется в ряде различных контекстов. Жесткие диски организованы в серию блоков фиксированного размера, обычно достаточного для хранения нескольких строк таблицы. За счет организации данных таблицы таким образом, чтобы строки помещались в эти блоки, и группировки связанных строк в последовательные блоки, количество блоков, которые необходимо прочитать или найти, во многих случаях сводится к минимуму, а также количество операций поиска.
Обзор Pinnecke et al. описывает методы гибридизации столбцов и строк по состоянию на 2017 год.
Обычным методом хранения таблицы является сериализация каждой строки данных, например:
001: 10, Смит, Джо, 60000; 002: 12, Джонс, Мэри, 80000; 003: 11, Джонсон, Кэти, 94000; 004: 22, Джонс, Боб, 55000;
Когда данные вставляются в таблицу, им присваивается внутренний идентификатор, rowid, который используется внутри системы для ссылки на данные. В этом случае записи имеют последовательные rowidнезависимо от назначенного пользователем empid. В этом примере СУБД использует короткие целые числа для хранения rowids. На практике обычно используются большие числа, 64-битные или 128-битные.
Строковые системы предназначены для эффективного возврата данных для всей строки или записи за минимальное количество операций. Это соответствует общему варианту использования, когда система пытается получить информацию о конкретном объекте, например, контактную информацию пользователя в системе rolodex или информацию о продукте для покупок в Интернете система. Сохраняя данные записи в одном блоке на диске вместе со связанными записями, система может быстро извлекать записи с минимумом дисковых операций.
Строчные системы неэффективны при выполнении операций в масштабе всего набора для всей таблицы, в отличие от небольшого числа конкретных записей. Например, чтобы найти все записи в таблице-примере с зарплатами от 40 000 до 50 000, СУБД должна будет полностью просмотреть всю таблицу в поисках совпадающих записей. В то время как примерная таблица, показанная выше, вероятно, уместится в одном блоке диска, таблица даже с несколькими сотнями строк не будет, и для извлечения данных и их изучения потребуется несколько дисковых операций.
Для повышения производительности такого рода операций (которые очень распространены и обычно используются в СУБД) большинство СУБД поддерживают использование индексов базы данных, в которых хранятся все значения из набора столбцов вместе с указателями rowidобратно в исходную таблицу. Индекс в столбце зарплаты будет выглядеть примерно так:
55000: 004; 60000: 001; 80000: 002; 94000: 003;
Поскольку они хранят только отдельные фрагменты данных, а не целые строки, индексы обычно намного меньше, чем хранилища основной таблицы. Сканирование этого меньшего набора данных снижает количество дисковых операций. Если индекс используется активно, он может значительно сократить время на выполнение обычных операций. Однако поддержание индексов увеличивает нагрузку на систему, особенно когда в базу данных записываются новые данные. В основной таблице должны храниться не только записи, но и любые прикрепленные индексы.
Основная причина, по которой индексы резко повышают производительность для больших наборов данных, заключается в том, что индексы базы данных по одному или нескольким столбцам обычно сортируются по значению, что делает запросы диапазона операциями (как вышеупомянутое «найти все записи с зарплатой от 40 000 до 50 000 ", пример) очень быстро (меньшая временная сложность ).
Ряд строковых баз данных спроектирован так, чтобы полностью уместиться в RAM, в базе данных в памяти. Эти системы не зависят от дисковых операций и имеют равный доступ ко всему набору данных. Это снижает потребность в индексах, поскольку для полного сканирования исходных данных требуется такое же количество операций, как и для полного индекса для типичных целей агрегирования. Поэтому такие системы могут быть проще и меньше, но могут управлять только базами данных, которые умещаются в памяти.
База данных, ориентированная на столбцы, сериализует все значения столбца вместе, затем значения следующего столбца и так далее. В нашем примере таблицы данные будут храниться следующим образом:
10: 001,12: 002,11: 003,22: 004; Смит: 001, Джонс: 002, Джонсон: 003, Джонс: 004; Джо: 001, Мэри: 002, Кэти: 003, Боб: 004; 60000: 001,80000: 002,94000: 003,55000: 004;
В этом макете любой из столбцов более точно соответствует структуре индекса в строковой системе. Это может вызвать путаницу, которая может привести к ошибочному мнению, что хранилище, ориентированное на столбцы, на самом деле «просто» хранилище строк с индексом для каждого столбца. Однако кардинально отличается отображение данных. В строковой индексированной системе первичным ключом является rowid, отображаемый из индексированных данных. В системе, ориентированной на столбцы, первичный ключ - это данные, которые отображаются на основе идентификаторов строк. Это может показаться тонким, но различие можно увидеть в этой общей модификации одного и того же магазина, где два элемента "Jones", указанные выше, сжаты в один элемент с двумя идентификаторами строк:
…; Smith: 001 ; Джонс: 002 004 ; Джонсон: 003;…
Будет ли система, ориентированная на столбцы, более эффективна в работе, во многом зависит от автоматизированной рабочей нагрузки. Операции, извлекающие все данные для данного объекта (всей строки), выполняются медленнее. Система на основе строк может извлекать строку за одно чтение с диска, тогда как в базе данных по столбцам требуются многочисленные дисковые операции для сбора данных из нескольких столбцов. Однако эти операции с целой строкой обычно редки. В большинстве случаев извлекается только ограниченный набор данных. В приложении rolodex, например, сбор имени и фамилии из множества строк для построения списка контактов гораздо более распространен, чем чтение всех данных для любого отдельного адреса. Это еще более верно для записи данных в базу данных, особенно если данные имеют тенденцию быть «разреженными» с множеством дополнительных столбцов. По этой причине хранилища столбцов продемонстрировали отличную реальную производительность, несмотря на многие теоретические недостатки.
Секционирование, индексирование, кэширование, представления, кубы OLAP и транзакционные системы, такие как ведение журнала с упреждающей записью или мультиверсионное управление параллелизмом, существенно влияют на физическую организацию любой системы. При этом системы РСУБД, ориентированные на оперативную обработку транзакций (OLTP), более ориентированы на строки, тогда как системы, ориентированные на оперативную аналитическую обработку (OLAP), представляют собой баланс между ориентированными на строки и столбцами. -ориентированный.
Сравнение между строками и столбцами баз данных обычно связано с эффективностью доступа к жесткому диску для данной рабочей нагрузки, поскольку время поиска невероятно долго по сравнению с другими узкими местами в компьютерах. Например, типичный жесткий диск Serial ATA (SATA) имеет среднее время поиска от 16 до 22 миллисекунд, в то время как доступ к DRAM на процессоре Intel Core i7 занимает в среднем 60 наносекунд, что почти в 400 000 раз быстрее. Ясно, что доступ к диску является основным узким местом при работе с большими данными. Столбчатые базы данных повышают производительность за счет уменьшения объема данных, которые необходимо прочитать с диска, как за счет эффективного сжатия похожих столбчатых данных, так и за счет чтения только данных, необходимых для ответа на запрос.
На практике столбчатые базы данных хорошо подходят для OLAP -подобных рабочих нагрузок (например, хранилищ данных ), которые обычно включают очень сложные запросы ко всем данным (возможно, петабайт ). Однако для записи данных в столбчатую базу данных необходимо проделать некоторую работу. Транзакции (INSERT) должны быть разделены на столбцы и сжиматься по мере хранения, что делает их менее подходящими для рабочих нагрузок OLTP. Строковые базы данных хорошо подходят для OLTP -подобных рабочих нагрузок, которые в большей степени загружены интерактивными транзакциями. Например, получение всех данных из одной строки более эффективно, когда эти данные расположены в одном месте (минимизируя поиск на диске), как в строчно-ориентированных архитектурах. Однако системы, ориентированные на столбцы, были разработаны как гибриды, способные выполнять как операции OLTP, так и OLAP. Некоторые из ограничений OLTP, с которыми сталкиваются такие системы, ориентированные на столбцы, опосредуются использованием (среди прочего) хранения данных в памяти. Системы с ориентацией на столбцы, подходящие как для ролей OLAP, так и для OLTP, эффективно сокращают общий объем данных, устраняя необходимость в отдельных системах.
Данные столбца имеют единый тип; следовательно, есть некоторые возможности для оптимизации размера хранилища, доступные для данных, ориентированных на столбцы, которые недоступны для данных, ориентированных на строки. Например, многие популярные современные схемы сжатия, такие как LZW или кодирование длин серий, используют для сжатия подобие смежных данных. Отсутствующие значения и повторяющиеся значения, часто встречающиеся в клинических данных, могут быть представлены двухбитовым маркером. Хотя те же методы могут использоваться для данных, ориентированных на строки, типичная реализация дает менее эффективные результаты.
Для улучшения сжатия также может помочь сортировка строк. Например, используя индексы битовой карты, сортировка может улучшить сжатие на порядок. Чтобы максимизировать преимущества сжатия лексикографического порядка по сравнению с кодированием длин серий, лучше всего использовать столбцы с низкой мощностью в качестве ключей первой сортировки. Например, для таблицы со столбцами "пол", "возраст", "имя" лучше всего сначала выполнить сортировку по значению "пол" (количество элементов равно двум), затем по возрасту (количество элементов <128), then name.
, сжатие столбцов приводит к сокращению дискового пространства. за счет эффективности извлечения. Чем сильнее достигается сжатие смежных областей, тем сложнее может стать произвольный доступ, поскольку для чтения может потребоваться несжатие данных. Поэтому в архитектуру, ориентированную на столбцы, иногда добавляются дополнительные механизмы, направленные на минимизацию необходимость доступа к сжатым данным.
Хранилища по столбцам или транспонированные файлы были реализованы с первых дней разработки СУБД. TAXIR был первым приложением системы хранения баз данных по столбцам с В 1969 году основное внимание уделялось поиску информации в биологии. Клинические данные из историй болезни пациентов с гораздо большим количеством атрибутов, чем можно было проанализировать, были обработаны в 1975 году и позже с помощью системы баз данных, ориентированной на время (TODS). Статистическое управление Канады внедрило р Система APID в 1976 году и использовала ее для обработки и извлечения данных канадской переписи населения и жилищного фонда, а также некоторых других статистических приложений. RAPID был передан другим статистическим организациям во всем мире и широко использовался в 1980-х годах. Он продолжал использоваться Статистическим управлением Канады до 1990-х годов.
Другая база данных, ориентированная на столбцы, была SCSS.
Более поздние пакеты баз данных, ориентированных на столбцы, включали:
Примерно с 2004 года появились дополнительные коммерческие и открытые реализации. MonetDB был выпущен под лицензией с открытым исходным кодом 30 сентября 2004 года, за ним последовал ныне несуществующий C-Store.
C-store был университетским проектом, который в конечном итоге, когда остался член команды Майкл Стоунбрейкер, это привело к созданию Vertica, которую он стал соучредителем в 2005 году.
Проект X100, связанный с MonetDB, превратился в VectorWise. Druid - это хранилище данных с ориентацией на столбцы, исходный код которого был открыт в конце 2012 года и сейчас используется многими организациями.
Классический Реляционная СУБД может использовать стратегии, ориентированные на столбцы, смешивая таблицы, ориентированные на строки и столбцы. Несмотря на сложность СУБД, этот подход доказал свою ценность с 2010 года по настоящее время. Например, в 2014 году Citusdata представила ориентированные на столбцы таблицы для PostgreSQL, а McObject добавила поддержку столбчатого хранилища с выпуском eXtremeDB Financial Edition в 2012 году, который затем был использован для установления нового стандарта производительность для независимого проверенного эталонного теста STAC-M3.
