Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе 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
Здравствуйте, kaa.python, Вы писали:
KP>Интересно, спасибо! Да мне, в принципе, пофигу будет там SQL ли нет. У нас сквозные индексы (GUID) и если я смогу посчитать как угодно, выводы будут корректными.
Ну я это просто к тому, что не надо учить какой-то эзотерический язык запросов чтобы опрашивать их вьюхи. Для клиентов оно должно выглядить как обычная SQL БД.
Здравствуйте, kaa.python, Вы писали:
KP>Они себя зарекомендовали как полные профаны в вопросе обеспечения надежности и качества. Так как мы маленький стартап, то позволить себе ПО которое разработано подобной компанией просто не можем
Ой ладно, а у aws подобного в свое время не было? Как это оносится к ClickHouse?
Здравствуйте, Sharov, Вы писали:
S>Ой ладно, а у aws подобного в свое время не было? Как это оносится к ClickHouse?
Относится самым непосредственным образом. Если компания не может обеспечить адекватного уровня контроля качества даже для коммерческих продуктов (рекомендую внимательно посмотреть на тот инцидент что я привел, это просто детский сад), то пользоваться их открытыми продуктами не обеспеченными серьезной поддержкой сообщества в коммерческой разработке тем более опасно.
Здравствуйте, kaa.python, Вы писали:
KP>Относится самым непосредственным образом. Если компания не может обеспечить адекватного уровня контроля качества даже для коммерческих продуктов (рекомендую внимательно посмотреть на тот инцидент что я привел, это просто детский сад), то пользоваться их открытыми продуктами не обеспеченными серьезной поддержкой сообщества в коммерческой разработке тем более опасно.
Первый же комментарий по ссылке:
Ну случается. У маленьких случается, у больших случается. В облаках случается, на земле случается.
Если у чувака потерялись критичные данные, значит он неправильно оценил риски и пролюбил стратегию резервного копирования.
Яндексу минус. Чуваку минус.
В остальном ситуация вполне рядовая. Яндекс чуваку шоколадку должен адекватную — явно не с небоскреб размером.
И опять же, по каждому продукту надо смотреть индивидуально -- своя специфика, своя история, совершенно разные люди могут заниматься этими продуктами. К тому же CH в самом Яндексе используется, соотв. протестирован вдоль и поперек.
Здравствуйте, wildwind, Вы писали:
W>Пока только присоединюсь к уже озвученным советам посмотреть на другие СУБД, более заточенные под вашу нагрузку. W>Вот из свежего: https://umbra-db.com/
Это уж слишком свежо, чуть ли не вчера (буквально) анонсировано. Насколько я знаю, Нойманн создал Амбру после того, как продал свое предыдущее детище (HyPer), позаимствовав оттуда идеи.
Вообще, мужик обладает какой-то нечеловеческой продуктивностью, учитывая, что он декан магистратуры-аспирантуры в универе, читает несколько курсов, публикует 2-3 статьи в год на всяких SIGMOD и еще у него что-то типа 3-х детей. При этом в одиночку создает СУБД, которые затем покупают серьезные конторы типа Tableau и еще доплачивают ему как консалтеру потом. Я общался с парой его аспирантов, он реально кодит сам.
Здравствуйте, Sharov, Вы писали:
S>К тому же CH в самом Яндексе используется, соотв. протестирован вдоль и поперек.
Имел счастье радость испытать это "протестирован вдоль и поперек". Их слоган "КХ не тормозит" — истинная правда: при сбое в синхронизации узлов кластера 200000 записей он удалил буквально на глазах за какие-то секунды, только рот от удивления открыть успел.
Справедливости ради, сейчас это действительно продукт, которым можно пользоваться. Статистику считает вполне бодро, и тут он действительно хорош. Но обновлять его надо только при большой нужде. И копию данных лучше все-таки иметь.
Здравствуйте, kaa.python, Вы писали:
KP>Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе Postgres и занимает около 200Гб, из которых в активном подсчете участвуют около 100Гб почти сплошь являясь индексами. Растет объем довольно бодро и к концу года по моим прикидкам должно быть около 400-500Гб. KP>Система начинала было затыкаться, …
То есть, проблема, которую требуется сейчас решить — поскорее "считать разную статистику", правильно?
Вы разбирались с тем, откуда появляются "затыки"?
Просто ли это объём обрабатываемых данных или "помноженный" (грубо говоря) на частоту записей?
То есть, при тех же объёмах, но в режиме "рид онли" на сколько всё лучше? На сколько резво нужно в расчётах учитывать недавно добавленные данные?
Анализировали планы запросов, нельзя ли как-то оптимизировать индексы?
KP>Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.
Все перечисленные метрики отлично поддаются пред-агрегации (другое дело медиана, например).
Выбираете нужные вам измерения (поля, по которым необходима группировка и фильтрация; в том числе время — дни/часы/минуты, смотря какая точность вам нужна) и подсчитываете метрики ("различные суммы, минимум/среднее/максимум"; для среднего нужен будет ещё и вес) по этим самым группам. С некой периодичностью пересчитываете их и добавляете новые строки. При построении отчёта досчитывыете эти пред-агрегаты.
Я немного не в курсе Postgres и не понял про массивы в данных. Можно пример?
Help will always be given at Hogwarts to those who ask for it.
я бы съехал с постгре,
если денег нет или религия не позволяет на greenplum (постгре перепиленый на колоночное хранение и аналитику)
если деньги есть на mssql columnstore
Здравствуйте, rm822, Вы писали:
R>я бы съехал с постгре,
Полностью съезжать не рационально, основная масса данных, кроме аналитики, отлично ложится на Postgre и на его особенности куча кода завязана.
R>если денег нет или религия не позволяет на greenplum (постгре перепиленый на колоночное хранение и аналитику) R>если деньги есть на mssql columnstore
Есть оба фактора не позволяющие использовать решения МС
За GreenPlum спасибо, как руки дойдут погляжу и на него и на ClickHouse, надо была наших данных тесты погонять.
Звучит как задача для time series database, постгрес для этого подходит плохо.
Хорошо полходят специализированные вещи вроде prometheus — но неочевидно, подойдут ли они вам
Здравствуйте, blp, Вы писали:
blp>Звучит как задача для time series database, постгрес для этого подходит плохо. blp>Хорошо полходят специализированные вещи вроде prometheus — но неочевидно, подойдут ли они вам
Я смотрю в сторону column-oriented (как по-русски это принято переводить?) баз данных, как одно из решений. Просто была надежда что кто-либо опытом поделится, про подводные камни расскажет. Пока что тесты показывают очень хороший прирост производительности при использовании секционирования
KP>А есть опыт с этой штукой? А то Я — это не та компания к которой есть безусловное доверие...
Есть опыт. Крутая штука. Для Ваших целей нужна именно колоночная аналитическая DB, и ни в коем случае не релляционная. Что касается CH-то это на текущий момент одна из лучших колоночных аналитических СУБД. У нас в CH сейчас имеется база порядка 800 TB данных. Подсчёт агреагатов на лету с применением фильтров, проходит в пределах десяти секунд если затрагиваются все данные. Доли секунды если отфильтровываются отдельные партиции. На диске всё это отлично жмётся, опять таки специфика колоночных DB. Вот только это не релляционная DB и тем, кто привык работать именно с релляционками, поначалу будет очень непривычно.
Здравствуйте, smeeld, Вы писали:
S> Вот только это не релляционная DB и тем, кто привык работать именно с релляционками, поначалу будет очень непривычно.
А можно пару примеров этой разницы? Насколько я понял, там почти стандартный SQL, да и база данных реляционная. Или речь не о ClickHouse, а о чем-то другом?
UPD. да, почитал обзор, вроде ограничения меня полностью устраивают.
KP>А можно пару примеров этой разницы? Насколько я понял, там почти стандартный SQL, да и база данных реляционная. Или речь не о ClickHouse, а о чем-то другом?
Там SQL-like, а не SQL. Исключительно чтоб привыкшим к SQL удобнее работать было, включая авторов. Но различий много, например совсем другие JOIN-ы. Собственно, вся релляционность CH именно этим и ограничивается, SQL-ем и и таблицами в которые данные вносятся строками и извлекаются строками. Но внутри это именно колоночная база, где каждая колонка в таблице-это как отдельная таблица DB. Значения в разных колонках и одинаковой позиции в строке таблицы связываются через метданные. Отсюда и подходы к организации данных. Желательно создавать широкие таблицы содержащие все нужные колонки и данные закидывать в таблицу как в лог, непрерывным потоком.
ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение, просто после копирования данных в экспериментальную базу еще и под Docker (2 Gb, 4 CPU). Теперь надо придумать как все это соединить в кучу с основной базой
Здравствуйте, kaa.python, Вы писали:
KP>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение
и всего-то? а сколько хайпу было
Здравствуйте, rm822, Вы писали:
R>Здравствуйте, kaa.python, Вы писали:
KP>>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение R>и всего-то? а сколько хайпу было
Насколько это "всего-то" пока сказать сложно. Ещё гора открытых вопросов, но данная опция, на первый взгляд выглядит как потенциальное решение.
Здравствуйте, kaa.python, Вы писали:
KP>>>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение
чо тогда ClickHouse а не Prometheus?
Здравствуйте, blp,
KP>>>>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение blp>чо тогда ClickHouse а не Prometheus?
А почему стоит предпочесть Prometheus? Расскажи, пожалуйста о своём опыте его использования для подсчёта статистики, буду очень благодарен.
Здравствуйте, kaa.python, Вы писали:
KP>А почему стоит предпочесть Prometheus?
Не могу сказать, почему его надо предпочитать ClickHouse — я ничего не знаю про именно ClickHouse
>Расскажи, пожалуйста о своём опыте его использования для подсчёта статистики, буду очень благодарен.
Не вполне понятно, что именно рассказывать — сценарии у всех весьма специфические, описанный ваш на наш вообще не похож. То, что у нас сильно непубличное и NDA, но очень похоже на то, что было у Убера, их видео можете посмотреть/поискать.
