Колонно-ориентированная СУБД - Column-oriented DBMS

А колоночная СУБД или же колоночная СУБД это система управления базами данных (СУБД), которая хранит таблицы данных столбец а не по строкам. Практическое использование хранилища столбцов по сравнению с хранилищем строк мало отличается в реляционная СУБД Мир. И столбцовые, и строковые базы данных могут использовать традиционные языки запросов к базам данных, такие как SQL, для загрузки данных и выполнения запросов. И строковые, и столбцовые базы данных могут стать основой системы для обслуживания данных для общих извлечь, преобразовать, загрузить (ETL) и визуализация данных инструменты. Однако, сохраняя данные в столбцах, а не в строках, база данных может более точно обращаться к данным, которые необходимы для ответа на запрос, а не сканировать и отбрасывать нежелательные данные в строках.

Описание

Фон

Система управления реляционной базой данных предоставляет данные, которые представляют собой двумерную таблицу столбцов и строк. Например, в базе данных может быть такая таблица:

RowIdEmpIdФамилияИмяЗарплата
00110СмитДжо60000
00212ДжонсМэри80000
00311ДжонсонКэти94000
00422ДжонсБоб55000

Эта простая таблица включает идентификатор сотрудника (EmpId), поля имени (Фамилия и Имя) и зарплату (Salary). Этот двухмерный формат является абстракцией. В реальной реализации аппаратное обеспечение хранения требует, чтобы данные были сериализованный в ту или иную форму.

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

Обзор Pinnecke et al.[1] описывает методы гибридизации столбцов и строк по состоянию на 2017 год.

Рядно-ориентированные системы

Распространенный метод хранения таблицы - сериализация каждой строки данных, например:

001: 10, Смит, Джо, 60000; 002: 12, Джонс, Мэри, 80000; 003: 11, Джонсон, Кэти, 94000; 004: 22, Джонс, Боб, 55000;

Когда данные вставляются в таблицу, им присваивается внутренний идентификатор, рядовой который используется внутри системы для ссылки на данные. В этом случае записи имеют последовательные рядовойs независимо от назначенного пользователем эмпид. В этом примере СУБД использует короткие целые числа для хранения рядовойс. На практике обычно используются более крупные числа, 64-битные или 128-битные.

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

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

Чтобы повысить производительность такого рода операций (которые очень распространены и обычно используются в СУБД), большинство СУБД поддерживают использование индексы базы данных, которые хранят все значения из набора столбцов вместе с рядовой указатели обратно в исходную таблицу. Индекс в столбце зарплаты будет выглядеть примерно так:

55000:004; 60000:001;80000:002;94000:003;

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

Основная причина, по которой индексы резко повышают производительность для больших наборов данных, заключается в том, что индексы базы данных по одному или нескольким столбцам обычно сортируются по значению, что делает диапазон запросов операции (например, приведенный выше пример "найти все записи с зарплатой от 40 000 до 50 000") очень быстро (ниже временная сложность ).

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

Колонно-ориентированные системы

База данных, ориентированная на столбцы, сериализует все значения столбца вместе, затем значения следующего столбца и так далее. В нашем примере таблицы данные будут храниться следующим образом:

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, отображаемый из индексированных данных. В системе, ориентированной на столбцы, первичный ключ - это данные, которые отображаются на основе идентификаторов строк.[2] Это может показаться тонким, но различие можно увидеть в этой общей модификации одного и того же магазина, в которой два элемента "Jones", указанные выше, сжаты в один элемент с двумя идентификаторами строк:

…; Смит: 001;Джонс: 002 004; Джонсон: 003;…

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

Разбиение, индексация, кеширование, просмотры, Кубы OLAP, и транзакционные системы, такие как ведение журнала с упреждающей записью или же мультиверсионный контроль параллелизма все это существенно влияет на физическую организацию любой системы. Тем не менее, онлайн-обработка транзакций (OLTP)-ориентированные системы РСУБД более ориентированы на строки, в то время как онлайн-аналитическая обработка Системы, ориентированные на (OLAP), представляют собой баланс между ориентированными на строки и столбцами.

Преимущества

Сравнение между базами данных, ориентированными на строки и столбцами, обычно связано с эффективностью доступа к жесткому диску для данной рабочей нагрузки, поскольку время поиска невероятно длинный по сравнению с другими узкими местами в компьютерах. Например, типичный Последовательный ATA (SATA) среднее время поиска на жестком диске составляет от 16 до 22 миллисекунд. [4] в то время как доступ к DRAM на процессоре Intel Core i7 занимает в среднем 60 наносекунд, что почти в 400 000 раз быстрее.[5] Ясно, что доступ к диску является основным узким местом при работе с большими данными. Столбчатые базы данных повышают производительность за счет уменьшения объема данных, которые необходимо прочитать с диска, как за счет эффективного сжатия похожих столбчатых данных, так и за счет чтения только данных, необходимых для ответа на запрос.

На практике столбцовые базы данных хорошо подходят для OLAP -подобные рабочие нагрузки (например, хранилища данных ), которые обычно включают очень сложные запросы ко всем данным (возможно петабайты ). Однако для записи данных в столбчатую базу данных необходимо проделать некоторую работу. Транзакции (INSERT) должны быть разделены на столбцы и сжиматься по мере хранения, что делает их менее подходящими для рабочих нагрузок OLTP. Строковые базы данных хорошо подходят для OLTP -подобные рабочие нагрузки, которые в большей степени загружены интерактивными транзакциями. Например, получение всех данных из одной строки более эффективно, когда эти данные расположены в одном месте (минимизируя поиск на диске), как в строчно-ориентированных архитектурах. Однако системы, ориентированные на столбцы, были разработаны как гибриды, способные выполнять как операции OLTP, так и OLAP. Некоторые из ограничений OLTP, с которыми сталкиваются такие системы, ориентированные на столбцы, опосредуются с использованием (среди прочего) в памяти хранилище данных.[6] Системы с ориентацией на столбцы, подходящие как для ролей OLAP, так и для OLTP, эффективно сокращают общий объем данных, устраняя необходимость в отдельных системах.[7]

Сжатие

Данные столбца имеют единый тип; поэтому есть некоторые возможности для оптимизации размера хранилища, доступные для данных с ориентацией на столбцы, которые недоступны для данных с ориентацией на строки. Например, многие популярные современные схемы сжатия, такие как LZW или же кодирование длин серий, используйте для сжатия сходство соседних данных. Отсутствующие значения и повторяющиеся значения, часто встречающиеся в клинических данных, могут быть представлены двухбитовым маркером.[8] Хотя те же методы можно использовать для строковых данных, типичная реализация даст менее эффективные результаты.[9][10]

Чтобы улучшить сжатие, также может помочь сортировка строк. Например, используя индексы растровых изображений, сортировка может улучшить сжатие на порядок.[11] Чтобы максимизировать преимущества сжатия лексикографический порядок относительно кодирование длин серий, лучше всего использовать низко-мощность столбцы в качестве ключей первой сортировки.[12] Например, для таблицы со столбцами «пол», «возраст», «имя» лучше всего отсортировать сначала по значению «пол» (количество элементов два), затем по возрасту (количество элементов <128), а затем по имени.

Столбцовое сжатие позволяет сократить дисковое пространство за счет эффективности поиска. Чем больше достигается соседнее сжатие, тем сложнее может стать произвольный доступ, так как для чтения может потребоваться несжатие данных. Таким образом, колоночные архитектуры иногда дополняются дополнительными механизмами, направленными на минимизацию необходимости доступа к сжатым данным.[13]

История

Колоночные хранилища или транспонированные файлы были реализованы с первых дней разработки СУБД. TAXIR был первым приложением системы хранения баз данных, ориентированной на столбцы, с упором на поиск информации в биологии.[14] в 1969 году. Клинические данные из историй болезни пациентов с гораздо большим количеством атрибутов, чем можно было проанализировать, были обработаны в 1975 году и позже с помощью системы баз данных, ориентированной на время (TODS).[8] Статистическое управление Канады внедрила систему RAPID[15] в 1976 г. и использовал его для обработки и извлечения данных переписи населения и жилищного фонда Канады, а также для ряда других статистических приложений. RAPID был передан другим статистическим организациям во всем мире и широко использовался в 1980-х годах. Он продолжал использоваться Статистическим управлением Канады до 1990-х годов.

Еще одна колоночная база данных была SCSS.[16][17][18]

Более поздние пакеты баз данных, ориентированных на столбцы, включали:

Примерно с 2004 года появились дополнительные коммерческие реализации и реализации с открытым исходным кодом. MonetDB был выпущен под лицензия с открытым исходным кодом 30 сентября 2004 г.,[19] за которым следует ныне несуществующий C-Магазин.[20]

C-store был университетским проектом, который в конечном итоге с членами команды Майкл Стоунбрейкер оставаясь, привело к Vertica, соучредителем которой он был в 2005 году.[21][22]

Проект X100, связанный с MonetDB, превратился в VectorWise.[23][24] Друид - это хранилище данных с ориентацией на столбцы, исходный код которого был открыт в конце 2012 года и сейчас используется многими организациями.[25]

Классический Реляционная СУБД может использовать стратегии, ориентированные на столбцы, смешивая таблицы, ориентированные на строки и столбцы. Несмотря на сложность СУБД, этот подход доказал свою ценность с 2010 года по настоящее время. Например, в 2014 году Citusdata представила ориентированные на столбцы таблицы для PostgreSQL[26] а McObject добавила поддержку столбчатого хранилища с выпуском eXtremeDB Финансовый выпуск 2012 г.[27] который затем был использован для установления нового стандарта производительности для теста STAC-M3, прошедшего независимую проверку.[28]

Смотрите также

Рекомендации

  1. ^ Маркус Пиннеке; Дэвид Бронеске; Габриэль Камперо Дюран; Гюнтер Сааке (2017). Подходят ли базы данных для гибридных рабочих нагрузок на графических процессорах? Перспектива Storage Engine (PDF). IEEE 33-я Международная конференция по инженерии данных (ICDE). Дои:10.1109 / ICDE.2017.237.
  2. ^ Даниэль Абади; Сэмюэл Мэдден (31 июля 2008 г.). «Развенчание еще одного мифа: магазины в колонках против вертикального разделения». Столбец базы данных. Архивировано из оригинал 4 декабря 2008 г.
  3. ^ Ставрос Харизопулос; Даниэль Абади; Питер Бонч. "Системы баз данных с ориентацией на столбцы" (PDF). Учебное пособие по VLDB 2009. п. 5.
  4. ^ Мазьеро, Мануэль (8 января 2013 г.). «Обзор Western Digital WD4001FAEX 4 ТБ: снова в черном». Оборудование Тома.
  5. ^ Левинталь, доктор Дэвид (2009). «Руководство по анализу производительности для процессоров Intel® Core ™ i7 и Intel® Xeon ™ 5500» (PDF). Intel. п. 22. Получено 2017-11-10.
  6. ^ «Сжатие транзакционных данных в гибридных базах данных OLTP и OLAP» (PDF). Получено 1 августа, 2017.
  7. ^ «Общий подход к базе данных для OLTP и OLAP с использованием базы данных столбцов в памяти» (PDF). Получено 1 августа, 2017.
  8. ^ а б Стивен Вейл; Джеймс Ф. Фрайс; Джио Видерхольд; Франк Джермано (1975). «Модульная система клинических баз данных с самоописанием». Компьютеры в биомедицинских исследованиях. 8 (3): 279–293. Дои:10.1016/0010-4809(75)90045-2.
  9. ^ Д. Дж. Абади; С. Р. Мэдден; Н. Хачем (2008). Хранилища-столбцы и хранилища-строки: насколько они на самом деле отличаются?. SIGMOD’08. С. 967–980.
  10. ^ Бруно, Н. (2009). «Учим старого слона новым трюкам» (PDF). arXiv:0909.1758 [cs.DB ].
  11. ^ Даниэль Лемир, Оуэн Касер, Камель Ауиш, «Сортировка улучшает индексы растровых изображений с выравниванием по словам», Инженерия данных и знаний, Volume 69, Issue 1 (2010), pp. 3-28.
  12. ^ Дэниел Лемир и Оуэн Касер, Изменение порядка столбцов для меньших индексов, Информационные науки 181 (12), 2011 г.
  13. ^ Доминик Слензак; Якуб Врублевски; Виктория Иствуд; Петр Сынак (2008). Brighthouse: аналитическое хранилище данных для специальных запросов (PDF). Материалы 34-й конференции VLDB. Окленд, Новая Зеландия. Архивировано из оригинал (PDF) на 2016-05-07. Получено 2009-05-04.
  14. ^ Джордж Ф. Эстабрук; Роберт С. Брилл (ноябрь 1969 г.). «Теория вступившего в ТАКСИР». Математические биологические науки. 5 (3–4): 327–340. Дои:10.1016/0025-5564(69)90050-9.
  15. ^ «СУБД для больших статистических баз данных». acm.org. Vldb '79. 1979. С. 319–327.
  16. ^ уже на рынке к сентябрю 1977 г.
  17. ^ SCSS: Руководство пользователя диалоговой статистической системы SPSS. 1980. ISBN  978-0070465336.
  18. ^ «SCSS от SPSS, Inc». ComputerWorld. 26 сентября 1977 г. с. 28.
  19. ^ «Краткая история о нас». monetdb.org.
  20. ^ "C-Store". mit.edu. Архивировано из оригинал на 2012-03-21. Получено 2008-01-22.
  21. ^ "Аналитическая база данных Vertica: C-Store 7 лет спустя" (PDF) " (PDF). VLDB.org. 28 августа 2012 г.
  22. ^ Чарльз Бэбкок (21 февраля 2008 г.). «Пионер баз данных переосмысливает лучший способ организации данных». Информационная неделя. Получено 2018-12-08.
  23. ^ Марцин Жуковски; Питер Бонч (20 мая 2012 г.). От x100 к векторному: возможности, проблемы и вещи, о которых не задумывается большинство исследователей. Материалы Международной конференции ACM SIGMOD 2012 по управлению данными. ACM. С. 861–862. Дои:10.1145/2213836.2213967. ISBN  978-1-4503-1247-9.
  24. ^ Д. Инкстер; М. Жуковски; П.А. Бонч (20 сентября 2011 г.). «Интеграция VectorWise с Ingres». Запись ACM SIGMOD. 40 (3): 45. CiteSeerX  10.1.1.297.4985. Дои:10.1145/2070736.2070747.
  25. ^ "Друид". druid.io.
  26. ^ https://github.com/citusdata/cstore_fdw/graphs/contributors
  27. ^ Соджани, Сандип (19 июня 2012 г.). «СУБД в оперативной памяти McObject eXtremeDB Financial Edition преодолевает узкое место в управлении данными на рынках капитала». гид по бобам.
  28. ^ Совет по эталонам STAC, Руководство (3 ноября 2012 г.). «McObject eXtremeDB 5.0 Financial Edition с системой хранения Kove XPD L2, сервером Dell PowerEdge R910 и Mellanox ConnectX-2 и коммутатором MIS5025Q QDR InfiniBand». STAC.

внешняя ссылка