Здравствуйте, kaa.python, Вы писали:

KP>Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе Postgres и занимает около 200Гб, из которых в активном подсчете участвуют около 100Гб почти сплошь являясь индексами. Растет объем довольно бодро и к концу года по моим прикидкам должно быть около 400-500Гб.
KP>Система начинала было затыкаться, …

То есть, проблема, которую требуется сейчас решить — поскорее "считать разную статистику", правильно?

Вы разбирались с тем, откуда появляются "затыки"?

• Просто ли это объём обрабатываемых данных или "помноженный" (грубо говоря) на частоту записей?
  То есть, еа тех же объёмах, но в режиме "рид онли" на сколько всё лучше? На сколько резво нужно в расчётах учитывать недавно добавленные данные?
  
• Анализировали планы запросов, нельзя ли как-то оптимизировать индексы?

KP>Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.

Все перечисленные метрики отлично поддаются пред-агрегации (другое дело, медиана, например).
Выбираете нужные вам измерения (поля, по которым необходима группировка и фильтрация; в том числе время — дни/часы/минуты, смотря какая точность вам нужна) и подсчитываете метрики ("различные суммы, минимум/среднее/максимум"; для среднего нужен будет ещё и вес) по этим самым группам. С некой периодичностью пересчитываете их и добавляете новые строки. При построении отчёта досчитывыете эти пред-агрегаты.

Я немного не в курсе Postgres и не понял про массивы в данных. Можно пример?

Здравствуйте, kaa.python, Вы писали:

KP>Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе Postgres и занимает около 200Гб, из которых в активном подсчете участвуют около 100Гб почти сплошь являясь индексами. Растет объем довольно бодро и к концу года по моим прикидкам должно быть около 400-500Гб.
KP>Система начинала было затыкаться, …

То есть, проблема, которую требуется сейчас решить — поскорее "считать разную статистику", правильно?

Вы разбирались с тем, откуда появляются "затыки"?

• Просто ли это объём обрабатываемых данных или "помноженный" (грубо говоря) на частоту записей?
  То есть, при тех же объёмах, но в режиме "рид онли" на сколько всё лучше? На сколько резво нужно в расчётах учитывать недавно добавленные данные?
  
• Анализировали планы запросов, нельзя ли как-то оптимизировать индексы?

KP>Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.

Все перечисленные метрики отлично поддаются пред-агрегации (другое дело медиана, например).

Выбираете нужные вам измерения (поля, по которым необходима группировка и фильтрация; в том числе время — дни/часы/минуты, смотря какая точность вам нужна) и подсчитываете метрики ("различные суммы, минимум/среднее/максимум"; для среднего нужен будет ещё и вес) по этим самым группам. С некой периодичностью пересчитываете их и добавляете новые строки. При построении отчёта досчитывыете эти пред-агрегаты.

Я немного не в курсе Postgres и не понял про массивы в данных. Можно пример?