Колонно-ориентированная СУБД
Из Википедии, бесплатной энциклопедии
  (Перенаправлено из базы данных Columnar )
Перейти к навигации Перейти к поиску

А СУБД колонка-ориентированный или столбчатый СУБД является системой управления базами данных (СУБД) , которая хранит данные таблицы по столбцу , а не по строкам. Практическое использование хранилища столбцов и хранилища строк мало отличается в мире реляционных СУБД . И столбцовые, и строковые базы данных могут использовать традиционные языки запросов к базам данных, такие как 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;

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

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

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

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

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), представляют собой баланс между ориентированными на строки и столбцами.

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

Сравнение между ориентированными на строки и столбцами базами данных обычно связано с эффективностью доступа к жесткому диску для данной рабочей нагрузки, поскольку время поиска невероятно велико по сравнению с другими узкими местами в компьютерах. Например, типичный жесткий диск с интерфейсом Serial 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]

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

  • 1993: KDB
  • 1995: Sybase IQ

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

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

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

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

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

  • Хранилище данных
  • Список колоночных СУБД
  • AOS и SOA
  • RCFile
  • BigQuery

использованная литература

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

внешние ссылки

  • Различение двух основных типов магазинов-столбцов
  • VLDB 2009 Tutorial - обзор
  • Обзор гибридной колоночно-ориентированной СУБД
  • Плетение взаимосвязей для производительности кэша - макет блока с ориентацией на столбцы
  • Проектирование и реализация современных систем баз данных, ориентированных на столбцы
Источник « https://en.wikipedia.org/w/index.php?title=Column-oriented_DBMS&oldid=1049722856 »
Contribute a better translation