Хранилища столбцов: сравнение баз данных на основе столбцов

Question

Я действительно изо всех сил пытался превратить SQL Server в нечто такое, что, откровенно говоря, никогда не будет. Мне нужна база данных для моей аналитической работы. БД должна быть быстрой и НЕ требует всей регистрации и других накладных расходов, обнаруженных в типичных базах данных (SQL Server, Oracle, DB2 и т. Д.)

Вчера я слушал Майкла Стоунбрейкера, выступавшего на конференции Money: Tech , и я продолжал думать: «Я на самом деле не сумасшедший. Есть лучший способ!» Он говорит об использовании хранилищ столбцов вместо баз данных, ориентированных на строки. Я зашел на страницу Википедии для магазинов колонок и вижу несколько проектов с открытым исходным кодом (которые мне нравятся) и несколько коммерческих / проектов с открытым исходным кодом (которые я не до конца понимаю).

Мой вопрос таков: в прикладной аналитической среде чем отличаются разные БД на основе столбцов? Как я должен думать о них? Кто-нибудь имеет практический опыт работы с системами с несколькими столбцами? Могу ли я использовать свой опыт работы с SQL на этих БД или мне придется изучать новый язык?

В конечном итоге я собираюсь перенести данные в R для анализа.

РЕДАКТИРОВАТЬ: Меня попросили дать некоторые пояснения в том, что именно я пытаюсь сделать. Итак, вот пример того, что я хотел бы сделать: Создайте таблицу с 4 миллионами строк и 20 столбцами (5 димов, 15 фактов). Создайте 5 таблиц агрегации, которые рассчитывают максимальные, минимальные и средние значения для каждого факта. Присоедините эти 5 агрегатов к стартовой таблице. Теперь вычислите процентное отклонение от среднего значения, процентное отклонение минимума и процентное отклонение от максимума для каждой строки и добавьте его в исходную таблицу. Эти данные таблицы не получают новые строки каждый день, они ПОЛНОСТЬЮ заменяются, и процесс повторяется. Небеса запрещают, если процесс должен быть остановлен. И логи ... ооооо логи! :)

Answer 1

Короткий ответ: для аналитических данных хранилище столбцов будет быстрее, с меньшими затратами на настройку.

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

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

Оказывается, это дает базе данных огромную возможность для сжатия значений. Например, если строковый столбец имеет среднюю длину 20 байтов, но имеет только 25 различных значений, база данных может сжаться примерно до 5 битов на значение. Базы данных хранилища столбцов часто могут работать без распаковки данных.

Часто в информатике существует компромисс между вводом-выводом и временем ЦП, но в хранилищах столбцов усовершенствования ввода-вывода часто улучшают местность ссылок, уменьшают активность подкачки в кэш-памяти и допускают более высокие коэффициенты сжатия, так что ЦП также выигрывает.

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

Другим фактором является использование массивно-параллельной (MMP) базы данных. Существуют базы данных MMP-хранилища строк и столбцов. Базы данных MMP могут масштабироваться до сотен или тысяч узлов и позволяют хранить огромные объемы данных, но иногда имеют компромиссы, такие как более слабое представление о транзакциях или не совсем SQL-язык запросов.

Я бы порекомендовал вам попробовать LucidDB. (Отказ от ответственности: я приверженец LucidDB.) Это база данных хранилища столбцов с открытым исходным кодом, оптимизированная для аналитических приложений, а также имеет другие функции, такие как растровые индексы. В настоящее время он работает только на одном узле, но эффективно использует несколько ядер и может обрабатывать разумные объемы данных без особых усилий.

Answer 2

4 миллиона строк, умноженных на 20 столбцов, умноженных на 8 байтов, для 640 мегабайт. Следуя практическому правилу, согласно которому R создает три временных копии для каждого объекта, мы получаем около 2 ГБ. Это не много по сегодняшним стандартам.

Так что это должно быть выполнимо в памяти на подходящей 64-битной машине с «приличным» количеством оперативной памяти (скажем, 8 ГБ или более). Установка Ubuntu или Debian (возможно, в серверной версии) может быть выполнена за несколько минут.

Answer 3

У меня есть некоторый опыт работы с изданием Infobright Community --- column-or. дБ, основано на mysql.

Pro:

• вы можете использовать mysql interfaces / odbc mysql драйверы, тоже из R
• достаточно быстрые запросы на больших блоках выбора данных (из-за KnowledgeGrid и пакетов данных)
• очень быстрый родной загрузчик данных и разъемы для ETL (talend, kettle)
• оптимизировал именно те операции, которые используются мной (и я думаю, что большинство из нас) (выбор по уровням факторов, объединение и т. Д.)
• специальная опция "поиска" для оптимизированного хранения переменных R-фактора;) (хорошо, переменные char / varchar с относительно небольшим числом уровней / числом строк)
• FOSS
• опция платной поддержки

Минусы:

• без операций вставки / обновления в Community Edition (пока?), Загрузка данных только через встроенный загрузчик данных / разъемы ETL
• нет официальной поддержки utf-8 (сортировка / сортировка и т. Д.), Запланировано на третий квартал 2009 года
• нет функций в агрегатных запросах, например пока выберите месяц (дату) из ...), запланировано на июль (?) 2009 г., но из-за хранения столбцов я предпочитаю просто создавать столбцы даты для каждого уровня агрегации (номер недели, месяц, ...) *
• не может быть установлен на существующий сервер mysql в качестве механизма хранения (из-за собственного оптимизатора, если я правильно понял), но вы можете установить Infobright & mysql на разные порты, если вам нужен

Резюме: Хорошее решение FOSS для ежедневных аналитических задач, а также, я думаю, ваших задач.

Answer 4

Вот мои 2 цента: SQL-сервер плохо масштабируется. Мы попытались использовать SQL-сервер для хранения финансовых данных в режиме реального времени (т. Е. Ценовые отметки на 100 символов). В первые две недели он работал идеально, а затем все медленнее и медленнее по мере увеличения размера базы данных и, наконец, остановился, слишком медленно, чтобы вставлять каждую цену по мере ее поступления. Мы пытались обойти это, перемещая данные из активной базы данных в автономное хранилище каждую ночь, но в конечном итоге проект был заброшен, поскольку он просто не работал.

Итог: если вы планируете хранить большое количество данных (> 1 ГБ), вам нужно что-то, что масштабируется должным образом, и это, вероятно, означает базу данных столбцов.

Answer 5

Мы могли бы лучше помочь вам принять обоснованное решение, если бы вы описали [1] свою конкретную цель и [2] проблемы, с которыми вы столкнулись в SQL Server.

Answer 6

Это похоже на изменение реализации (двумерный массив в главном порядке столбца, а не в главном порядке строки), а не изменение интерфейса.

Подумайте о модели «стратегии», а не о полной смене парадигмы. Конечно, я никогда не использовал эти продукты, так что на самом деле они могут вызвать сдвиг парадигмы в вашем горле. Хотя я не знаю почему.