Не помню чтобы рассматривали TimeScaleDB и так как не погружался в его работу сейчас не готов утверждать подошел бы он нам или нет. На первый взгляд не очень подходит, но возможно ошибаюсь. Спасибо за вопрос.
По поводу limit by. Когда экспериментировал с ReplacingMergeTree, честно говоря, limit 1 by в голову не пришел, но все равно есть сомнения что это поможет.
При этой конструкции как я понимаю агрегация все равно выполняется, только неявно. Думаю это может значительно повлиять на производительность, но это конечно бы надо проверять.
Не уверен, что гарантируется необходимая сортировка внутри группы. Скорее всего нужно добавлять order by, чтобы мы не отсекли нужную запись.
Представим, что мы просто хотим посчитать количество сообщений. В случае с ReplacingMergeTree мы не сможем написать просто select count(*) from message, нам придется написать что-то типа select count(distinct message_id) from message, что значительно медленнее первого варианта.
Этот кейс можно протестировать на https://play.clickhouse.com/ с их тестовой таблицей. Запрос select count(*) from hits_100m_obfuscated выполняется несколько миллисекунд. select count(distinct WatchID) from hits_100m_obfuscated почти 10 секунд
По поводу словарей. С ними много не работал и, возможно, не до конца разобрался, но мне показалось что они не совсем подходят для нашей задачи.
смутило, что хранятся в памяти
кажется не совсем предназначены для частого обновления
усложняется логика и поддержка с добавлением отдельной бд для словаря
Возможно, в итоге этот вариант оказался бы проще и быстрее.
делать селекты из кликхауса в какой-то промежуточный сторадж, программно имитировать локи для этих записей и потом делать массовую вставку записей в кликхаус обратно
Сравнение производилось с обычным PostgreSQL, так как целью статьи было показать как мы переходили с текущей реализации на колоночную, а не сравнить аналитические бд.
Перед реализацией рассматривали разные инструменты, в том числе Citus Data. В конечном итоге решили, что ClickHouse нас полностью устраивает и скорее всего в конечном счете окажется проще по сравнению с другими вариантами, например, за счет таких вещей, как партиционирование из коробки.
Аналитика была частью достаточно большой схемы, вынесли только ее. Почему изначально выбрали PG сказать не могу, было до меня. Думаю на ранних этапах продукта пошли по пути наименьшего сопротивления и добавили функционал в существующую схему.
По поводу загрузки данных в ClickHouse. Данные аналитики у нас отправляют несколько сервисов в небольшой сервис очередь (самописная kafka на минималках). Новый сервис для аналитики периодически вытягивает эти данные батчами и записывает в ClickHouse.
С чего же вы взяли, что мы не пробовали другие методы постгреса. Я вскользь упомянул это во введении. Они либо нам не помогали, либо помогали недостаточно или не для всех кейсов.
К сожалению нет. Основная проблема не в том, что в pg множество таблиц, а в том, что долгое чтение всех данных. Например, в секции "Простые аналитические запросы" замеряется время на одной таблице без всяких join'ов, на этом примере схема не важна.
Ваш запрос решает немного другую задачу. У вас сортируется и ограничивается для каждого CouterId (session_id в моем случае) отдельно, а у меня на все сессии. Т.е.в результате мой запрос вернет всего 10 записей, а ваш по 10 записей для каждой сессии (CounerId)
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Как мы переносили аналитику из PostgreSQL в ClickHouse
Не помню чтобы рассматривали TimeScaleDB и так как не погружался в его работу сейчас не готов утверждать подошел бы он нам или нет. На первый взгляд не очень подходит, но возможно ошибаюсь. Спасибо за вопрос.
Обновление данных в ClickHouse
По поводу limit by. Когда экспериментировал с ReplacingMergeTree, честно говоря,
limit 1 byв голову не пришел, но все равно есть сомнения что это поможет.При этой конструкции как я понимаю агрегация все равно выполняется, только неявно. Думаю это может значительно повлиять на производительность, но это конечно бы надо проверять.
Не уверен, что гарантируется необходимая сортировка внутри группы. Скорее всего нужно добавлять order by, чтобы мы не отсекли нужную запись.
Представим, что мы просто хотим посчитать количество сообщений. В случае с ReplacingMergeTree мы не сможем написать просто
select count(*) from message, нам придется написать что-то типаselect count(distinct message_id) from message, что значительно медленнее первого варианта.Этот кейс можно протестировать на https://play.clickhouse.com/ с их тестовой таблицей. Запрос
select count(*) from hits_100m_obfuscatedвыполняется несколько миллисекунд.select count(distinct WatchID) from hits_100m_obfuscatedпочти 10 секундПо поводу словарей. С ними много не работал и, возможно, не до конца разобрался, но мне показалось что они не совсем подходят для нашей задачи.
смутило, что хранятся в памяти
кажется не совсем предназначены для частого обновления
усложняется логика и поддержка с добавлением отдельной бд для словаря
Возможно, в итоге этот вариант оказался бы проще и быстрее.
Вот это не до конца понял:)
Как мы переносили аналитику из PostgreSQL в ClickHouse
Сравнение производилось с обычным PostgreSQL, так как целью статьи было показать как мы переходили с текущей реализации на колоночную, а не сравнить аналитические бд.
Перед реализацией рассматривали разные инструменты, в том числе Citus Data. В конечном итоге решили, что ClickHouse нас полностью устраивает и скорее всего в конечном счете окажется проще по сравнению с другими вариантами, например, за счет таких вещей, как партиционирование из коробки.
Как мы переносили аналитику из PostgreSQL в ClickHouse
Аналитика была частью достаточно большой схемы, вынесли только ее. Почему изначально выбрали PG сказать не могу, было до меня. Думаю на ранних этапах продукта пошли по пути наименьшего сопротивления и добавили функционал в существующую схему.
По поводу загрузки данных в ClickHouse. Данные аналитики у нас отправляют несколько сервисов в небольшой сервис очередь (самописная kafka на минималках). Новый сервис для аналитики периодически вытягивает эти данные батчами и записывает в ClickHouse.
Как мы переносили аналитику из PostgreSQL в ClickHouse
С чего же вы взяли, что мы не пробовали другие методы постгреса. Я вскользь упомянул это во введении. Они либо нам не помогали, либо помогали недостаточно или не для всех кейсов.
Как мы переносили аналитику из PostgreSQL в ClickHouse
К сожалению нет. Основная проблема не в том, что в pg множество таблиц, а в том, что долгое чтение всех данных. Например, в секции "Простые аналитические запросы" замеряется время на одной таблице без всяких join'ов, на этом примере схема не важна.
Как мы переносили аналитику из PostgreSQL в ClickHouse
Ваш запрос решает немного другую задачу. У вас сортируется и ограничивается для каждого CouterId (session_id в моем случае) отдельно, а у меня на все сессии. Т.е.в результате мой запрос вернет всего 10 записей, а ваш по 10 записей для каждой сессии (CounerId)