PostgreSQL - как лучше хранить очень большой объем данных?

На graylog2 глянь лучше.

юзаю его для других целей, но у него много недостатков на больших объемов данных

Ок, а не думал использовать cassandra для логов?

Просто имел опыт с постргом и большими обемами данных, впечатления не очень.

лучше хранить в хадупе

SciDB?

Почему размер таблицы с данными должен беспокоить? Данные бинарные?

плюсую хадуп, для хранения и агрегации большого числа логов самое то

Вполне разумная схема. Посмотри еще как партиционирование в postgresql делается.

В Cassandra нет аналитики

Собственно вопрос - может лучше как-нибудь по другому хранить эти данные?

PG, конечно, хорошая СУБД, но для логов реляционку лучше не юзать. Пишите тупо в файлы обычные или бинарные логи, для каждого product_id отдельная директория, каждый день - отдельный файл. Проще и быстрее ничего не будет.

Во всём остальном ход мыслей верный, т.е. костылить партиционирование. Кроме этого ещё нужно будет настроить PG на относительно быстрые инсерты. Это выключение синхронных коммитов + тюнинг WALа, труёвый ACID здесь не нужен.

А для логов разве надо? Вроде же там просто выборка диапазонов записей по фильтру?

надо, как ты будешь склеивать разные логи? хадуп для огромных объемов логов почти идеален

Да ну, для каждой задачи писать таску. Да и запускать не быстро. Ну только если логов действительно ооочень много все это имеет смысл.

Да ну, для каждой задачи писать таску

Конечно. А в чем принципиальная разница между таской на каком-нибудь перле и sql-запросом? Если напрягает, то hive прикрутить можно.

Ну только если логов действительно ооочень много все это имеет смысл

Логи имеют свойство расти в объемах экспоненциально. Если сейчас за год получается 5 терабайт, то через год может быть уже 15. Геморройно потом будет съезжать с не масштабируемых решений.

Хадуп + hive для adhoc запросов. Постгрес обкекается на таких объемах.

Кстати, 10-20GB это объем нежатых логов? Если что, RC-файлы (hive) достаточно хорошо могут его сократить.

Кстати, 10-20GB это объем нежатых логов?

да, это размер plain-text

Данные бинарные?

нет, plain-text: числа, строки и время

Просто имел опыт с постргом и большими обемами данных, впечатления не очень.

что именно было «не очень»?

да, это размер plain-text

Тогда hadoop твой выбор. Даже не смотри в сторону реляционок. В последние можешь выгружать посчитанную аналитику.

Кроме этого ещё нужно будет настроить PG на относительно быстрые инсерты.

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

что именно было «не очень»?

«Ручное» партицирование очень быстро утомляет. Таблички больше 30GB начинают медленно шевелится.

Тогда hadoop твой выбор. Даже не смотри в сторону реляционок. В последние можешь выгружать посчитанную аналитику.

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

если я захочу перейти на хадуп мне нужно будет много слабых серверов вроде, или нет?

Не обязательно. Он и на одной тачке прекрасно шевелится пока в IO не упирается.

За какой период времени нужно будет строить отчеты по всем product_id? Если больше месяца, то это будет единственной проблемой.

У тебя тут прямо просится кассандра с product_id в качестве row key, и потом сортировка по дате внутри product_id. Тогда правда желательно чтобы для некоторых продуктов не было на порядки больше данных чем для других

у меня нет задачи строить репорт по всем product_id. к постгрессу сейчас прикручено веб-приложение и операторы сами вводят интересующее их product_id и время. постгресс возвращает данные за 2-3 сек для 1 месяца.

Сейчас вожусь с logstash/elascticsearch/kibana3/lumberjack.

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

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

Один инстанс logstash+один инстанс elasticsearch прилично справляются с индексом около 30 гигов, больше - начинают сильно тормозить и надо добавлять больше машинок.

В общем рекомендую хотя бы посмотреть.

Как-то вот так оно выглядит: http://itmages.ru/image/view/1219520/65eb17fe

Я просто предпологаю

* Скорее всего эти данные не понадобятся * Если нужны, то самые последние * Редко будут нужны самые старые Храни в виде запакованных файлов разбитых по ID. За небольшой последний срок можно и в PG подержать

Селекты довольно долго выполнялись. Индексы, кеши и все что мог настроил. База гигов 30 была.