Например есть два шарда. На первом результат селекта

adformat,clicks,revenue_on_clicks
display,5,0.05

На втором будет

adformat,clicks,revenue_on_clicks
display,2,0.02

Если выполнить схожий запрос на агрегатах, будет не

adformat,clicks,revenue_on_clicks
display,7,0.07

А будет

adformat,clicks,revenue_on_clicks
display,5,0.05
display,2,0.02

Но там же

GROUP BY adformat

. Как там может быть "display" 2 раза?

Собственно... В этом и вопрос как такое может быть. В понедельник планирую обновить кх в надежде что этот казус поправится. На стейджевом кластере из двух нод такой аномалии не заметил, хотя версия там такая же, таблицы идентичные и данные такие же

либо это мегабаг на стороне кликхауса, либо, что более вероятно у вас в группировке есть ещё какое-то поле, которое на первый взгляд ни на что не влияет и не должно приводить к дублированию строк, но на самом деле оно-то и влияет :) ну и ещё вариант, что в селекте используется arrayJoin или типо того, что может наплодить раздвоение. ну или join какой-то, который вроде словарь и не должен раздваивать, но раздваивает.
либо вы в админке смотрите и видите второй раз туже строку на другой странице или ещё какая хрень :)

Друзья у меня есть вопросик  такого плана. Мне надо перегнать json данные из mongodb в  clickhouse.  И если с большей частью полей я я разобрался nj вот с одним нет. У меня есть  ключ meta с вложенным словарем и туда пихаются куча всяких разных данных и  они по большей части рандомные.  Какбы мне правильно хранить это поле ?  Превращать в строку ?  Или есть какото способ который я не могу найти ))

Мы пока закрыли это вопрос через добавления FINAL. Пока работает и всё сходится как надо. Смотрю всегда через clickhouse-client в консоли, ибо ну его эти табиксы и прочие админки от юродивых) Самое странное, что раньше всё работало как надо, проблема началась месяц назад, и, конечно, никто ничего не делал ¯\_(ツ)_/¯

типо что то вроде этого

"meta" : {
        "file_id" : ObjectId("60df02518a2e6020b738dc9b"),
        "folder_id" : ObjectId("5bae265d007791646ee1f836"),
        "file_name" : "Test",
        "common_id" : "nGQZPhNfHeen2jy0xLVzJyxGnJxiq7"
    },

"meta" : {
        "user_id" : "nGQZPhNfHeen2jy0xLVzJyxGnJxiq7",
        "car_name": "mazda"
    },

И прям оч все по разному , я хотел каакието общие штуки сделать но их оч мало

а так это просто  нагрузочная инфа, для менеджера чтобы понять что  в этом конкретном json  происходило

а есть create table этого AggregatingMergeTree?

я б хранил на вашем месте json как строку в кх

если данная информация не несет ничего нагруженного. А вот со стороны app layer,  емнип, занимался бы десериализацией при необходимости

емнип  а это что ?

если мне не изменяет память (оперативная)

Напрашивается исользовать json, тем более, что в кликхаусе куча функций для работы с ним. Будет проблема только если понадобится в этом json проапдейтить какое-нибудь поле.

я ненашел там типо данных json?  или я вас не понял))

Всем привет!
Как понять, к какому timezone относится timestamp?
В бд timestamp, например,  в таком виде «1,579,100,244»

не будет проблем, все в зависимости от того, каким образом будут спроектированы и какие требования выдвигаются бизнесом. Если нужна будет версионность, - да тут надо будет думать, но если менеджер не особо требует, то значит и изменения будут не столь постоянны

притом, что само поле по себе хранит только метаданные :)

Такого типа и нет. Сохраняйте как строку. В доке пощите json найдёте все нужные функции.

типо можно схохронятькак строку а потом  выковыривать из этой строки  json и кaкто им  баловаться. Кажись понял . Буду эксперементировать.