Столбцы: сравнение базирующихся на столбцах баз данных

Question

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

Вчера я слушал Michael Stonebraker speak at the Money:Tech conference, и я продолжал думать: «Я не действительно сумасшедший. Там лучший способ! " Он говорит об использовании column stores вместо баз данных, ориентированных на строки. Я перешел на страницу Википедии для column stores, и я вижу несколько проектов с открытым исходным кодом (что мне нравится) и несколько коммерческих/открытых исходных проектов (которые я не совсем понимаю).

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

У меня есть опыт работы с сообществом Infobright --- column-or. db, основанный на mysql.

Pro:

• вы можете использовать MySQL интерфейсы/ODBC драйвер MySQL, от R тоже
• достаточно быстро запросов на больших кусках выбора данных (из-за KnowledgeGrid пакетов & данных)
• очень быстро нативный загрузчик данных и разъемы для ETL (talend, kettle)
• оптимизировал именно те операции, которые я (и я думаю, большинство из нас) используют (выбор по уровням факторов, соединение и т. д.)
• специальная опция «поиск» для оптимизации хранения переменных факторов R;) (ОК, символ/VARCHAR переменные с относительно небольшим числом уровней/число строк)
• СОПО
• заплатил вариант поддержки
• ?

Минусы:

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

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

Answer 5

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

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

Answer 6

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

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