Какую БД выбрать, для работы со сложными фильтрами (WHERE условиями)?

Question

[last7]

Допустим, есть интернет-магазин, который собирает информацию о поведении покупателей и такой информации уже на 50М строк в БД (Postgres). И встала задача просматривать (в реал-тайме) сколько покупателей сделало то-то и то-то. К примеру, купил телевизор, просмотрел каталог с чайниками 5 раз, у которого указана фамилия, и заходивший 4 месяца назад на сайт. Другими словами агрегировать информацию, по разными фильтрам, заранее не известным, беглый взгляд по ТЗ выявил, то минимальные будут включать 10-12 условий.

Мысли были разные: создать огромную таблицу со всеми данными, а затем простыми WHERE / GROUP BY выбирать данные; таблица будет большая, но можно будет избавиться от JOIN-нов. Была идея взять MongoDB и его агрегации, но пишут, что они не так уж и быстры. Советовали взять колоночную БД, но данных на мой взгляд не так много и вряд ли это целесообразно.

Кто сталкивался, подскажите какие технологии смотреть?

P.S. Реал-тайм это 15 сек максимум.

Comments

[sim3x]

слишком общий вопрос
Когда что-то не будет получаться с постгресом - спрашивай

[last7]

sim3x: ок, спасибо, не получается вот что: обычный запрос включает 7 LEFT JOIN (порядок выборки 5-7 минуты), в денормализованной таблице (поэксперементировал на 200 колонках) скорость выше 1-2 минуты (без индексов). Но если денормализововать полностью будет 1000 колонок, стоит ли это делать?

[sim3x]

last7:
>порядок выборки 5-7 минуты
сделать https://wiki.postgresql.org/wiki/Using_EXPLAIN
пофиксить узкие места

Денормализовать и сравнить результат по времени

>10-12 условий
>на 200 колонках
> 1000 колонок
тут что-то не сходится

>скорость выше 1-2 минуты (без индексов)
зачем без индексов что-то делать?

[igruschkafox]

очень похоже что Вам просто требуется кубик сделать ...

Answer 1

[Пума Тайланд]

ну пусть в постгресе все и варится

Answer 2

[romy4]

это типа Отчёты? если да, то под каждый создаётся своя агрегационная таблица.

Comments

[last7]

Нет, не отчеты, а именно фильтрация данных.

[romy4]

last7: частота такой незаурядной фильтрации какая?

[last7]

romy4: в день таких запросов будет порядка 10-50

[romy4]

last7: в таком случае стоит узнать более конкретные задачи по такой отчётности и создать максимально возможные подготовленные данные.

[last7]

romy4: интересный вариант, спасибо. Но подойдет ли для этого постгря? Не будет более эффективно сложить в noSQL БД? Где процесс формирования данных положить на плечи mapreduce?

[romy4]

last7: постгря для этого хорошо подходит.

Answer 3

[Сергей]

Вам, видимо, нужен некий OLAP-куб.

Comments

[romy4]

который можно создать в postgres

[last7]

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

[Сергей]

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