Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе Postgres и занимает около 200Гб, из которых в активном подсчете участвуют около 100Гб почти сплошь являясь индексами. Растет объем довольно бодро и к концу года по моим прикидкам должно быть около 400-500Гб.
Система начинала было затыкаться, но ее удалось довольно хорошо ускорить (от 2 до 20 раз) банальной денормализацией ряда таблиц, но замеры показывают что на долго ситуацию так не исправить. Довольно многообещающим выглядит секционирование, которое завезли в PG12, но мало ли...
Так вот, что сейчас рекомендовано использовать для подсчетов на лету если у тебя есть пара сотен гигабайт данных? Если у кого-либо есть практика с секционированием из PG12 тоже было бы интересно узнать впечатления.
Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.
Здравствуйте, kaa.python, Вы писали:
KP>Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе Postgres и занимает около 200Гб, из которых в активном подсчете участвуют около 100Гб почти сплошь являясь индексами. Растет объем довольно бодро и к концу года по моим прикидкам должно быть около 400-500Гб.
Данные, я так понимаю, не меняются, а только добавляются.
KP>Система начинала было затыкаться, но ее удалось довольно хорошо ускорить (от 2 до 20 раз) банальной денормализацией ряда таблиц, но замеры показывают что на долго ситуацию так не исправить. Довольно многообещающим выглядит секционирование, которое завезли в PG12, но мало ли...
А за счет чего секционирование может ускорить операции в данном случае?
KP>Так вот, что сейчас рекомендовано использовать для подсчетов на лету если у тебя есть пара сотен гигабайт данных? Если у кого-либо есть практика с секционированием из PG12 тоже было бы интересно узнать впечатления. KP>Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.
Надо подсчитывать промежуточные данные (по группам, периодам и т.п.). При запросах статистики агрегировать эти промежуточные (уже агрегированные) данные.
Здравствуйте, Буравчик, Вы писали:
Б>Данные, я так понимаю, не меняются, а только добавляются.
Изменяются иногда, но не удаляются.
Б>А за счет чего секционирование может ускорить операции в данном случае?
За счет того, что одну таблицу можно разбить на несколько секций с разными типами группировки: по времени и т.п. Индексы сильно уменьшатся (разобьются на составляющие), что было бы полезно. Сейчас база частенько bitmap scan, а то и вообще sequential scan устраивает, так как индексы слишком большие.
Б>Надо подсчитывать промежуточные данные (по группам, периодам и т.п.). При запросах статистики агрегировать эти промежуточные (уже агрегированные) данные.
Не выйдет к сожалению из за специфики данных. Сейчас всё что можно уже подсчитывается, но слишком много вариативности в запросах пользователя.
Здравствуйте, kaa.python, Вы писали:
Б>>Надо подсчитывать промежуточные данные (по группам, периодам и т.п.). При запросах статистики агрегировать эти промежуточные (уже агрегированные) данные.
KP>Не выйдет к сожалению из за специфики данных. Сейчас всё что можно уже подсчитывается, но слишком много вариативности в запросах пользователя.
А можно пример?
Как правило всем нужны итоги кратные месяцу/недели/декаде. И схема Буравчика работает очень хорошо.
Здравствуйте, wraithik, Вы писали:
W>А можно пример? W>Как правило всем нужны итоги кратные месяцу/недели/декаде. И схема Буравчика работает очень хорошо.
Да, можно, если упрощенно, то есть куча (десятки миллионов) событий, к которым относятся разные атрибуты, например сотни тысяч участников событий (1 или больше участник на событие). Пользователь может фильтровать выборку по атрибутам событий в произвольные моменты времени без привязки к каким-то конкретным периодам. Поэтому закешировать вообще без шансов, так как пользователь может задать совершенно любую выборку. Вернее как, мы сейчас кэшируем, но это разве что на скорости повторной отдачи данных, если пользователь страничку в браузере обновил, сказывается.
Так что мне нужно именно быстро фильтровать события (дата, участники и т.п.) и потом считать по выборке аналитику на сервере базы данных, не загружая выборку локально, так как в ней могут быть миллионы записей.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, wraithik, Вы писали:
W>>А можно пример? W>>Как правило всем нужны итоги кратные месяцу/недели/декаде. И схема Буравчика работает очень хорошо.
KP>Да, можно, если упрощенно, то есть куча (десятки миллионов) событий, к которым относятся разные атрибуты, например сотни тысяч участников событий (1 или больше участник на событие). Пользователь может фильтровать выборку по атрибутам событий в произвольные моменты времени без привязки к каким-то конкретным периодам. Поэтому закешировать вообще без шансов, так как пользователь может задать совершенно любую выборку. Вернее как, мы сейчас кэшируем, но это разве что на скорости повторной отдачи данных, если пользователь страничку в браузере обновил, сказывается. KP>Так что мне нужно именно быстро фильтровать события (дата, участники и т.п.) и потом считать по выборке аналитику на сервере базы данных, не загружая выборку локально, так как в ней могут быть миллионы записей.
Есть участники, события и т.д. — это поля по которым могут быть отборы и реже агрегирование — назовем это измерениями.
Есть еще набор показателей — цифры — которые мы суммируем, делим и т.д.
Верно?
Как правило юзверь будет делать какой то отбор по измерениям и агрегирование по показателям. Как правило анализ будет по периодам.
Т.е. можно построить таблицу с итогами, куда войдут все измерения, и допустим, все суммы показателей с записями кратными месяцу.
Здравствуйте, wraithik, Вы писали:
W>Есть участники, события и т.д. — это поля по которым могут быть отборы и реже агрегирование — назовем это измерениями. W>Есть еще набор показателей — цифры — которые мы суммируем, делим и т.д.
W>Верно?
W>Как правило юзверь будет делать какой то отбор по измерениям и агрегирование по показателям. Как правило анализ будет по периодам. W>Т.е. можно построить таблицу с итогами, куда войдут все измерения, и допустим, все суммы показателей с записями кратными месяцу.
Измерений много (часть полей — массивы), пользователь активно использует данные с кратностью 24 часа (именно последнии 24 часа начиная с текущего момента в разных часовых поясах, а не 1 день начиная, к примеру, с GMT). Ну и еще куча вариантов подсчета одной и той же записи в зависимости от запрошенной выдачи. Да и я уже прикидывал подобный вариант, но построенная таким образом итоговая таблица по размерам будет сильно (в разы) больше исходных данных и задача сведется к тому, как эту кучу данных посчитать за разумное время
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, wraithik, Вы писали:
W>>Есть участники, события и т.д. — это поля по которым могут быть отборы и реже агрегирование — назовем это измерениями. W>>Есть еще набор показателей — цифры — которые мы суммируем, делим и т.д.
W>>Верно?
W>>Как правило юзверь будет делать какой то отбор по измерениям и агрегирование по показателям. Как правило анализ будет по периодам. W>>Т.е. можно построить таблицу с итогами, куда войдут все измерения, и допустим, все суммы показателей с записями кратными месяцу.
KP>Измерений много (часть полей — массивы), пользователь активно использует данные с кратностью 24 часа (именно последнии 24 часа начиная с текущего момента в разных часовых поясах, а не 1 день начиная, к примеру, с GMT). Ну и еще куча вариантов подсчета одной и той же записи в зависимости от запрошенной выдачи. Да и я уже прикидывал подобный вариант, но построенная таким образом итоговая таблица по размерам будет сильно (в разы) больше исходных данных и задача сведется к тому, как эту кучу данных посчитать за разумное время
Больше там быть не может, если учитывать только обороты, т.е. суммы.
Делай учет итогов кратный часу.
Старые данные редактируются или это крайне редкий процесс?
Здравствуйте, kaa.python, Вы писали:
W>>Т.е. можно построить таблицу с итогами, куда войдут все измерения, и допустим, все суммы показателей с записями кратными месяцу.
KP>Измерений много (часть полей — массивы), пользователь активно использует данные с кратностью 24 часа (именно последнии 24 часа начиная с текущего момента в разных часовых поясах, а не 1 день начиная, к примеру, с GMT). Ну и еще куча вариантов подсчета одной и той же записи в зависимости от запрошенной выдачи. Да и я уже прикидывал подобный вариант, но построенная таким образом итоговая таблица по размерам будет сильно (в разы) больше исходных данных и задача сведется к тому, как эту кучу данных посчитать за разумное время
1)
Можно сделать такую обработку запроса, чтобы большая её часть использовала заранее подсчитанное, с разбивкой в 24 часа, затем оставшиеся часы добивались бы отдельным запросом.
2)
Если пользователю нужна база, которая умеет всё, то пусть идёт к гадалке и смотрит в её хрустальный шар. Там тоже есть всё. А любая реальная система является набором компромиссов и ограничений.
3)
Недавно в одном телеграм-чате человек рассказывал, как он сумел использовать Intel Optane в качестве оперативной памяти. Там несложно и недорого получить 1.5 терабайта такой оперативки, которая хоть и не столь быстрая, как DRAM, зато переживает отключение питания. Нужно это было ему для анализа преогромных графов на redis graph. В ходе последующего обсуждения, с моей подачи про дешёвый сервер б/у, участники подсчитали что сервер с 1 ТБ DRAM будет стоить около 300 т.р., где 100 за сам сервер, и 200 т.р. за 1 ТБ б/у плашками DDR3 ECC 32 ГБ.
Здравствуйте, wraithik, Вы писали:
W>Больше там быть не может, если учитывать только обороты, т.е. суммы. W>Делай учет итогов кратный часу.
Больше однозначно будет (я уже проверял разные гипотизы с предварительным подсчетом данных), так как ряд полей — это массивы и к ним так же применяется фильтрация (вхождение/пересечение множеств). Т.е. для того что бы предварительно посчитать всё, придется перевести каждый из массивов в набор записей, что разрастается до безобразия.
W>Старые данные редактируются или это крайне редкий процесс?
Относительно объема данных процесс редкий, но вообще изменения новых данных довольно активные первые несколько дней.
Так что я бы к моему изначальному вопросу хотел вернулся, как бы считать на лету побыстрее. Я даже готов часть на которой мы подсчеты делаем в другое хранилище перенести и обеспечить синхронизацию, было бы понятно в какое. Задача пусть и не стандартная, но как-то же аналитику обсчитывают
Здравствуйте, kaa.python, Вы писали:
KP>Так что я бы к моему изначальному вопросу хотел вернулся, как бы считать на лету побыстрее. Я даже готов часть на которой мы подсчеты делаем в другое хранилище перенести и обеспечить синхронизацию, было бы понятно в какое. Задача пусть и не стандартная, но как-то же аналитику обсчитывают
А что мешает считать не все данные а случайные выборки? Зачем нужна абсолютная точность особенно если "пользователь крутилки крутит"
Здравствуйте, kaa.python, Вы писали:
Б>>Надо подсчитывать промежуточные данные (по группам, периодам и т.п.). При запросах статистики агрегировать эти промежуточные (уже агрегированные) данные.
KP>Не выйдет к сожалению из за специфики данных. Сейчас всё что можно уже подсчитывается, но слишком много вариативности в запросах пользователя.
"Слишком много" это объективные данные или пользователь так говорит? Обычно правило 80/20 таки работает.
Здравствуйте, kaa.python, Вы писали:
KP>Так вот, что сейчас рекомендовано использовать для подсчетов на лету если у тебя есть пара сотен гигабайт данных? Если у кого-либо есть практика с секционированием из PG12 тоже было бы интересно узнать впечатления.
Возможно, пришло время проекту перейти на другую БД — ClickHouse
Здравствуйте, wildwind, Вы писали:
W>"Слишком много" это объективные данные или пользователь так говорит? Обычно правило 80/20 таки работает.
Объективные варианты использования говорят. А может есть что по делу сказать? Я не хочу быть грубым, но немного устал от того, что все мне говорят о том, что мне надо вместо ответа на вопрос.
Здравствуйте, kaa.python, Вы писали:
KP>Так вот, что сейчас рекомендовано использовать для подсчетов на лету если у тебя есть пара сотен гигабайт данных? Если у кого-либо есть практика с секционированием из PG12 тоже было бы интересно узнать впечатления. KP>Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.
На паре эвентов Frank McSherry (довольно известный товарищ в области пересечения БД и data streams) убеждал нас что materialize.io решит кучу подобных проблем. Идея в том, что между твоей транзакционной БД и их движком вставляется что-то вроде Debezium, которое посылает им апдейты, а дальше они очень хитрым образом обновляют вьюхи на лету, не пересчитывая запросы. От клиентов она ожидает стандартный SQL 92, емнип.
Вот тут он демонстрирует это дело. Кстати, исходники dataflow по-моему на Rust'e, тебе должно быть близко.
Здравствуйте, Sharov, Вы писали:
KP>>А то Я — это не та компания к которой есть безусловное доверие... S>Да ладно, почему? Уж с технологической тз ребята уважать себя заставили.
Они себя зарекомендовали как полные профаны в вопросе обеспечения надежности и качества. Так как мы маленький стартап, то позволить себе ПО которое разработано подобной компанией просто не можем
Здравствуйте, kl, Вы писали:
kl>На паре эвентов Frank McSherry (довольно известный товарищ в области пересечения БД и data streams) убеждал нас что materialize.io решит кучу подобных проблем. Идея в том, что между твоей транзакционной БД и их движком вставляется что-то вроде Debezium, которое посылает им апдейты, а дальше они очень хитрым образом обновляют вьюхи на лету, не пересчитывая запросы. От клиентов она ожидает стандартный SQL 92, емнип.
Интересно, спасибо! Да мне, в принципе, пофигу будет там SQL ли нет. У нас сквозные индексы (GUID) и если я смогу посчитать как угодно, выводы будут корректными.
kl>Вот тут он демонстрирует это дело. Кстати, исходники dataflow по-моему на Rust'e, тебе должно быть близко.
А вот это неожиданно. Я как-то довольно давно в Rust разочаровался. Я за Go, Elixir да C++17
