Що робить стовпчикові бази даних придатними для наукових даних?
Відповіді:
Колоноорієнтована база даних (= стовпчастий сховище даних) зберігає дані таблиці стовпця за стовпцем на диску, тоді як орієнтована на рядки база даних зберігає дані таблиці за рядком.
Є дві основні переваги використання баз даних, орієнтованих на стовпці, порівняно з базою даних, орієнтованих на рядки. Перша перевага стосується кількості даних, яку потрібно прочитати, якщо ми виконуємо операцію лише з кількома функціями. Розглянемо простий запит:
SELECT correlation(feature2, feature5)
FROM records
Традиційний виконавець прочитав би всю таблицю (тобто всі функції):
Натомість, використовуючи підхід на основі стовпців, ми просто мусимо читати стовпці, які цікавлять:
Друга перевага, яка також дуже важлива для великих баз даних, полягає в тому, що зберігання на основі стовпців дозволяє краще стискати, оскільки дані в одному конкретному стовпчику дійсно однорідні, ніж у всіх стовпцях.
Основний недолік підходу, орієнтованого на стовпець, полягає в тому, що маніпулювання (пошук, оновлення чи видалення) цілого рядка неефективне. Однак ситуація має виникати рідко в базах даних для аналітики ("складування"), що означає, що більшість операцій є лише для читання, рідко читаються багато атрибутів в одній таблиці, а записи - лише додавання.
Деякі RDMS пропонують варіант орієнтованого на стовпчик системи зберігання даних. Наприклад, PostgreSQL в основному не має можливості зберігати таблиці на основі стовпців, але Greenplum створив закритий джерело (DBMS2, 2009). Цікаво, що Greenplum також стоїть за бібліотекою з відкритим кодом для масштабованої аналітики в базах даних, MADlib (Hellerstein et al., 2012), що не випадково. Зовсім недавно CitusDB, стартап, що працює над швидкісною аналітичною базою даних, випустив власне розширення стовпців магазину з відкритим кодом для PostgreSQL, CSTORE (Miller, 2014). Система Google для широкомасштабного машинного навчання Sibyl також використовує формат даних, орієнтований на стовпці (Chandra et al., 2010). Ця тенденція відображає зростаючий інтерес до орієнтованого на стовпці сховища для масштабної аналітики. Stonebraker та ін. (2005) далі обговорюють переваги СУБД, орієнтованих на стовпці.
Два конкретні випадки використання: Як зберігається більшість наборів даних для широкомасштабного машинного навчання?
(Велика частина відповіді приходить з Додатка С: BeatDB: Підхід від кінця до кінця , щоб представити saliencies з масивних наборів даних сигналу Франка Dernoncourt, СМ, дисертація, MIT Відділ по EECS. )
Це залежить від того, що ти робиш.
У магазинах стовпців є дві основні переваги:
- цілі стовпці можна пропустити
- Стиснення довжини пробігу краще працює на стовпцях (для певних типів даних; зокрема, з кількома різними значеннями)
Однак вони також мають недоліки:
- багатьом алгоритмам знадобляться всі стовпці і записуватимуться лише за раз (наприклад, k-засоби) або, можливо, навіть потрібно обчислити матрицю попарної відстані
- методи стиснення добре працюють лише для розріджених типів даних і факторів, але не дуже добре для подвійних значень безперервних даних
- додатки в магазинах стовпців коштують дорого, тому не ідеально підходять для потокового / зміни даних
Стовпчастий накопичувач дуже популярний для OLAP, який називається "дурною аналітикою" (Майкл Стоунбракер), і звичайно для попередньої обробки, де, можливо, вам буде цікаво відкинути цілі стовпці (але вам потрібно спочатку мати структуровані дані - ви не зберігаєте JSON в стовпчику формат). Оскільки стовпчастий макет дуже приємний, наприклад, підрахунок, скільки яблук ви продали минулого тижня.
Для більшості випадків використання наукових / наукових даних, база даних масивів, здається, є способом пройти (плюс, звичайно, неструктуровані вхідні дані). Наприклад, SciDB та RasDaMan.
У багатьох випадках (наприклад, глибоке вивчення) матриці та масиви - це потрібні вам типи даних, а не стовпці. MapReduce тощо, звичайно, може бути корисним для попередньої обробки. Можливо, навіть дані стовпців (але база даних масивів зазвичай також підтримує стиснення, подібне до стовпців).
Я не використовував стовпчасту базу даних, але я використовував формат файлу стовпців із відкритим кодом, який називається Паркет, і я думаю, що переваги, ймовірно, однакові - швидша обробка даних, коли потрібно лише запитувати невеликий підмножину великого кількість стовпців. У мене був запит на близько 50 терабайт файлів Avro (формат файлів, орієнтований на ряд) з 673 стовпцями, що займало близько півтори години на кластері Hadoop 140 вузлів. З Паркетом той самий запит зайняв близько 22 хвилин, тому що мені було потрібно лише 5 стовпців.
Якщо у вас була невелика кількість стовпців або ви використовували велику частку своїх стовпців, я не думаю, що стовпчаста база даних не мала б великої різниці порівняно з орієнтованою на ряд, тому що вам все одно доведеться в основному сканувати всі ваші дані. Я вважаю, що стовпчикові бази даних зберігають стовпці окремо, тоді як рядки, орієнтовані на рядки, зберігають рядки окремо. Ваш запит буде швидше, коли ви зможете прочитати менше даних з диска.
Це посилання пояснює більше деталей.
Примітка. Це моє запитання, і я дуже вдячний за чудові відповіді, які допомогли мені зрозуміти цю концепцію.
Отже, я б пояснив поняття так, як я зрозумів:
Як правило, дані в базах даних зберігаються в пам'яті у таких форматах:
Розглянемо цю дату:
X1 X2
1 0.7091409 -1.4061361
2 -1.1334614 -0.1973846
3 2.3343391 -0.4385071
У реляційному магазині на основі рядків він зберігається так:
1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071
у вигляді рядків.
У стовпчастому магазині воно зберігатиметься так:
1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071
у вигляді стовпців.
Отже, що це означає?
Це означає, що вставка (та оновлення) та видалення швидко зберігаються в магазині стовпців на основі рядків, оскільки це лише видалення останніх кількох значень або перших кількох значень. Однак у стовпчикових сховищах це не так, оскільки значення в кожному сховищі блоків потрібно видалити.
Однак, коли виникає потреба у стовпчикових агрегатах та операціях, стовпчикові сховища мають перевагу над їх аналогами на основі рядків, оскільки вони зберігаються в стовпцях, і, як результат, отримати доступ до окремих стовпців дуже просто.