Каковы некоторые преимущества столбчатых хранилищ данных, которые делают их более подходящими для анализа данных и аналитики?
23
Колонно-ориентированная база данных (= столбцовое хранилище данных) хранит данные таблицы столбец за столбцом на диске, в то время как ориентированная на строки база данных хранит данные таблицы строка за строкой.
Существует два основных преимущества использования базы данных, ориентированной на столбцы, по сравнению с базой данных, ориентированной на строки. Первое преимущество относится к объему данных, которые необходимо прочитать, если мы выполним операцию только с несколькими функциями. Рассмотрим простой запрос:
SELECT correlation(feature2, feature5)
FROM records
Традиционный исполнитель прочитал бы всю таблицу (т.е. все функции):
Вместо этого, используя наш подход на основе столбцов, мы просто должны прочитать интересующие столбцы:
Второе преимущество, которое также очень важно для больших баз данных, заключается в том, что хранилище на основе столбцов обеспечивает лучшее сжатие, поскольку данные в одном конкретном столбце действительно однородны, чем во всех столбцах.
Основным недостатком подхода, ориентированного на столбцы, является то, что манипулирование (поиск, обновление или удаление) всей данной строки неэффективно. Однако такая ситуация должна возникать редко в базах данных для аналитики («хранилище»), что означает, что большинство операций доступны только для чтения, редко читают много атрибутов в одной и той же таблице, а записи - только добавления.
Некоторые RDMS предлагают опцию механизма хранения на основе столбцов. Например, PostgreSQL изначально не имеет возможности хранить таблицы на основе столбцов, но Greenplum создал таблицу с закрытым исходным кодом (СУБД2, 2009). Интересно, что Greenplum также стоит за библиотекой с открытым исходным кодом для масштабируемой аналитики в базе данных, MADlib (Hellerstein et al., 2012), что не случайно. Совсем недавно CitusDB, стартап, работающий с высокоскоростной аналитической базой данных, выпустил свое собственное расширение для столбцов хранилища с открытым исходным кодом для PostgreSQL, CSTORE (Miller, 2014). Система Google для крупномасштабного машинного обучения Сибил также использует ориентированный на столбцы формат данных (Chandra et al., 2010). Эта тенденция отражает растущий интерес к хранилищу с ориентацией на столбцы для крупномасштабной аналитики. Stonebraker et al. (2005) далее обсудить преимущества столбцово-ориентированной СУБД.
Два конкретных варианта использования: как хранится большинство наборов данных для крупномасштабного машинного обучения?
(Большая часть ответа дана в Приложении C к: BeatDB: сквозной подход к раскрытию характеристик из массивных наборов данных сигналов. Franck Dernoncourt, SM, диссертация, MIT Dept of EECS )
Это зависит от того, что вы делаете.
Колоночные магазины имеют два ключевых преимущества:
Однако они также имеют недостатки:
Хранение столбцов действительно популярно для OLAP, также называемой «глупой аналитикой» (Майкл Стоунбрейкер), и, конечно, для предварительной обработки, когда вы действительно можете быть заинтересованы в отбрасывании целых столбцов (но сначала вам нужно иметь структурированные данные - вы не храните JSON в столбчатых столбцах). формат). Потому что столбчатый макет очень удобен, например, для подсчета того, сколько яблок вы продали на прошлой неделе.
Для большинства случаев использования в науке / науке данных, как представляется, лучше всего использовать базы данных массивов (плюс, конечно, неструктурированные входные данные). Например, SciDB и RasDaMan.
Во многих случаях (например, глубокое обучение) матрицы и массивы - это нужные вам типы данных, а не столбцы. Конечно, MapReduce и другие могут быть полезны при предварительной обработке. Может быть, даже данные столбца (но база данных массива обычно также поддерживает сжатие в виде столбцов).
источник
Я не использовал столбцовую базу данных, но я использовал формат столбцов с открытым исходным кодом, называемый Parquet, и я думаю, что преимущества, вероятно, те же - более быстрая обработка данных, когда вам нужно только запросить небольшое подмножество большого Число столбцов. У меня был запрос, выполняющий около 50 терабайт файлов Avro (формат файла с ориентацией на строки) с 673 столбцами, что заняло около полутора часов в кластере Hadoop из 140 узлов. С Parquet тот же запрос занял около 22 минут, потому что мне нужно было только 5 столбцов.
Если бы у вас было небольшое количество столбцов или вы использовали большую часть столбцов, я не думаю, что столбцовая база данных будет иметь большое значение по сравнению со строкой, потому что вам все равно придется в основном сканировать все ваши данные. Я считаю, что столбчатые базы данных хранят столбцы отдельно, тогда как ориентированные на строки базы данных хранят строки отдельно. Ваш запрос будет быстрее, если вы сможете прочитать меньше данных с диска.
Эта ссылка объясняет больше деталей.
источник
Примечание: это мой вопрос, и я действительно благодарен за замечательные ответы, которые помогли мне понять концепцию.
Итак, я бы объяснил концепцию так, как я понял:
Как правило, данные в базах данных хранятся в памяти в следующих форматах:
Рассмотрим эту информацию:
В реляционном хранилище на основе строк оно хранится так:
в виде рядов.
В столбчатом хранилище это будет храниться так:
в форме столбцов.
Итак, что это значит?
Это означает, что вставка (и обновление) и удаление выполняются быстро в хранилище столбцов на основе строк, поскольку это просто удаление последних нескольких значений или первых нескольких значений. Однако в столбчатых хранилищах дело обстоит иначе, так как значение в каждом хранилище блоков необходимо удалить.
Тем не менее, когда есть необходимость в столбчатых агрегатах и операциях, столбчатые хранилища имеют преимущество перед своими основанными на строках аналогами, поскольку они хранятся по столбцам, и в результате доступ к отдельным столбцам очень прост.
источник