Смешивать колонки и строки ориентированных баз данных?

Question

В настоящее время я пытаюсь улучшить производительность веб-приложения. Цель приложения - предоставить (real time) analytics. У нас есть модель базы данных, похожая на star schema, несколько таблиц фактов и множество таблиц измерений. База данных работает с Mysql и MyIsam движком.
Размер таблицы фактов может легко войти в верхние миллионы, а некоторые таблицы измерений также могут достигнуть миллионов.
Теперь дело в том, что запросы на выборку могут стать очень медленными, если таблицы измерений объединяются на таблицах фактов, а также выполняются агрегации. Первое, что приходит на ум при прослушивании, - почему бы не пересчитать данные? Это невозможно, поскольку пользователям разрешено использовать несколько свободно настраиваемых фильтров.

Так что мне нужна система «все в одном», подходящая для любых целей;) К сожалению, она еще не была изобретена. Вот и пришла идея объединить 2 существующие системы. Смешивание базы данных row oriented и column oriented (например, например infinidb или infobright). Сохраните решение MySQL MySQL от MySQL (для быстрых вставок и запросов на основе строк) и добавьте в него базу данных, ориентированную на столбцы (для быстрых операций агрегации на нескольких столбцах), и периодически (ночью) заполняйте ее с помощью cronjob. Проблема может возникнуть, когда запрашиваются текущие данные (это должно быть в режиме реального времени), поэтому мне, возможно, потребуется получить данные из обеих баз данных, что может усложнить ситуацию.

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

Итак, вопрос в том, хорошая ли это идея? Может быть, кто-то уже сделал это? Может быть, есть лучшие способы сделать это.

У меня пока нет опыта работы с базами данных, ориентированными на столбцы, и я также не уверен, как должна выглядеть его схема. Первые тесты показали хорошую производительность на той же самой структуре star schema like, но также на структуре big table like.

Надеюсь, этот вопрос подходит для SO.

Answer 1

Greenplum , который является проприетарным (но в основном свободным от пива) расширением для PostgreSQL, поддерживает как ориентированные на столбцы, так и ориентированные на строки таблицы с высокой настраиваемой компрессией.Кроме того, вы можете смешать настройки в одной таблице , если ожидаете, что некоторые части будут испытывать большую транзакционную нагрузку, а другие - нет.Например, последний год может быть ориентированным на строки и несжатым, ориентированным на столбцы предыдущего года и сжатым quicklz, а также ориентированным на столбцы всех предыдущих лет и сжатым bz2.

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

(Отказ от ответственности: IЯ имел дело с Greenplum профессионально, но только в контексте оценки их программного обеспечения для покупки.)

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

В частности, нормализация почти никогда не стоит усилий, и иногда вы можете получить большой прирост производительностипутем денормализации до погранично-комических уровней красногоundancy.Если данные никогда не попадают на диск в несжатом состоянии, вам может быть не важно, что вы повторяете имя каждого клиента 40000 раз. Алгоритмы сжатия Infobright разработаны специально для такого рода приложений, и нередко получается соотношение 40: 1 между логическими и физическими размерами ваших таблиц.