stringtranslate.com

Столбцово-ориентированная СУБД

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

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

Описание

Фон

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

Эта простая таблица включает идентификатор сотрудника (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;

В этом макете любой из столбцов более точно соответствует структуре индекса в системе, ориентированной на строки. Это может вызвать путаницу, которая может привести к ошибочному мнению, что хранилище, ориентированное на столбцы, «на самом деле просто» хранилище строк с индексом для каждого столбца. Однако кардинально отличается отображение данных. В системе, ориентированной на строки, индексы сопоставляют значения столбцов с идентификаторами строк, тогда как в системе, ориентированной на столбцы, столбцы сопоставляют идентификаторы строк со значениями столбцов. [2] Это может показаться незаметным, но разницу можно увидеть в этой общей модификации одного и того же хранилища, в которой два элемента «Джонс», приведенные выше, сжаты в один элемент с двумя идентификаторами строк:

…;Смит: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]

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

Примерно с 2004 года появились дополнительные реализации с открытым исходным кодом и коммерческие реализации. MonetDB был выпущен под лицензией с открытым исходным кодом 30 сентября 2004 года, за ним последовал ныне несуществующий 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. -М3 бенчмарк. [28]

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

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

  1. ^ Маркус Пиннеке; Дэвид Бронеске; Габриэль Камперо Дюран; Гюнтер Сааке (2017). Подходят ли базы данных для гибридных рабочих нагрузок на графических процессорах? Взгляд на механизм хранения (PDF) . 33-я Международная конференция IEEE по инженерии данных (ICDE). дои : 10.1109/ICDE.2017.237.
  2. ^ Дэниел Абади; Сэмюэл Мэдден (31 июля 2008 г.). «Развенчивание еще одного мифа: хранилища столбцов против вертикального секционирования». Столбец базы данных. Архивировано из оригинала 4 декабря 2008 года.
  3. ^ Ставрос Харизопулос; Дэниел Абади; Питер Бонч. «Столбцово-ориентированные системы баз данных» (PDF) . Учебное пособие по VLDB 2009 . п. 5.
  4. ↑ Масьеро, Мануэль (8 января 2013 г.). «Обзор WD4001FAEX емкостью 4 ТБ от Western Digital: снова в черном» . Аппаратное обеспечение Тома .
  5. ^ Левинталь, Дэвид (2009). «Руководство по анализу производительности процессоров Intel® Core™ i7 и процессоров Intel® Xeon™ 5500» (PDF) . Интел. п. 22 . Проверено 10 ноября 2017 г.
  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. ПМИД  1157469.
  9. ^ DJ Абади; С.Р. Мэдден; Н. Хашем (2008). Хранилища по столбцам и хранилища по строкам: насколько они на самом деле отличаются? . стр. 967–980. {{cite book}}: |work=игнорируется ( помощь )
  10. ^ Бруно, Н. (2009). «Обучаем старого слона новым трюкам». arXiv : 0909.1758 [cs.DB].
  11. ^ Дэниел Лемир, Оуэн Кейзер, Камель Ауиш, «Сортировка улучшает индексы растровых изображений с выравниванием по словам», Data & Knowledge Engineering , Том 69, Выпуск 1 (2010), стр. 3-28.
  12. ^ Дэниел Лемир и Оуэн Касер, Изменение порядка столбцов для меньших индексов, Информационные науки 181 (12), 2011
  13. ^ Доминик Слензак; Якуб Врублевски; Виктория Иствуд; Петр Синак (2008). Brighthouse: хранилище аналитических данных для специальных запросов (PDF) . Материалы 34-й конференции ВЛДБ. Окленд, Новая Зеландия. Архивировано из оригинала (PDF) 7 мая 2016 г. Проверено 4 мая 2009 г.
  14. ^ Джордж Ф. Эстабрук; Роберт С. Брилл (ноябрь 1969 г.). «Теория присоединения TAXIR». Математические биологические науки . 5 (3–4): 327–340. дои : 10.1016/0025-5564(69)90050-9.
  15. ^ «СУБД для больших статистических баз данных». acm.org . Влдб '79. 1979. стр. 319–327.
  16. ^ уже на рынке к сентябрю 1977 г.
  17. ^ Не, Норман Х. (1980). SCSS: Руководство пользователя по диалоговой статистической системе SPSS . МакГроу-Хилл. ISBN 978-0070465336.
  18. ^ "SCSS от SPSS, Inc" . Компьютерный мир . 26 сентября 1977 г. с. 28.
  19. ^ «Краткая история о нас». monetdb.org .
  20. ^ "C-Магазин". mit.edu . Архивировано из оригинала 5 марта 2012 г. Проверено 22 января 2008 г.
  21. ^ «Аналитическая база данных Vertica: C-Store 7 лет спустя» (PDF)» (PDF) . VLDB.org . 28 августа 2012 г.
  22. ↑ Чарльз Бэбкок (21 февраля 2008 г.). «Database Pioneer переосмысливает лучший способ организации данных». Информационная неделя . Проверено 8 декабря 2018 г.
  23. ^ Марцин Жуковски; Питер Бонч (20 мая 2012 г.). «От x100 к векторному». Материалы Международной конференции ACM SIGMOD 2012 по управлению данными . АКМ. стр. 861–862. дои : 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 . дои : 10.1145/2070736.2070747. S2CID  6372175. 
  25. ^ «Друид». Друид.io .
  26. ^ "Цитусданные". github.com .
  27. ↑ Сауджани, Сандип (19 июня 2012 г.). «СУБД McObject eXtremeDB Financial Edition In-Memory преодолевает узкое место в управлении данными на рынках капитала». руководство по бобам .
  28. ^ Совет по эталонным показателям STAC, Руководство (3 ноября 2012 г.). «McObject eXtremeDB 5.0 Financial Edition с системой хранения данных Kove XPD L2, сервером Dell PowerEdge R910, Mellanox ConnectX-2 и коммутатором MIS5025Q QDR InfiniBand». СТАК .

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