привет, друзья, подскажите моменты по реализации ишроких таблиц. Делаем в ch широкие таблицы для аналитических данных с кучи разных источников. Проблема только в том что некоторые источники имеют несколько баз со связями один ко многим. Допустим, есть таблицы: Транзации, Бонусы. Одна транзакция может иметь несколько бонусов. Таблицы крупные (сотни гб). Мы сливаем их в одну длинную. Так вот, у нас с коллегой возникли разногласия о том как правильно будет хранить эти данные. Варианта 2 (на скрине). Условие - есть одна запись с транзакцией, к ней 2 записи по бонусу.
То есть, в первом случае получается некий аналог JOIN. Мы при выгрузке данных объеденяем 2 таблицы, при втором случае мы делаем 2 независимых селекта. Какой из вариантов ближе к паттерну? Если делали что-то подобное, что можете посоветовать?

а что в system.mutations для этой мутации?

надо в таблице транзакций добавить поля для бонусов и писать массивы с бонусами

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

в mutations присутствует запись. parts_to_do постепенно уменьшается.
но я ожидал что команда ALTER TABLE вернет управление только когда все партиции перезапишутся. возможно есть разница в выполнении из clickhouse-client и по jdbc? Я выполняю из client, но это исключительно для тестирования. по факту на prod нужно будет выполнять по jdbc и было бы удобно написать в коде что-то типа

client.execute("ALTER TABLE DELETE ....)
client.execute("INSERT ...")

т.е. я хочу записывать новые данные только после того, как удалены старые

Какие отличия? И что лучше использовать?

никаких, что удобнее

странно, таблица replicated?

да

CREATE TABLE IF NOT EXISTS mytable ON CLUSTER mycluster
(
    `device_id` UInt64 NOT NULL,
    `data_item_id` UInt64 NOT NULL,
    `data_time` DateTime64(3, 'UTC') NOT NULL CODEC(DoubleDelta),
    `data_value` Float64 NOT NULL CODEC(Delta, LZ4)
)
ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{shard}/ts_data_double11', '{replica}')
PARTITION BY toYYYYMM(data_time)
ORDER BY (device_id, data_item_id, data_time)
SETTINGS index_granularity = 8192;

вы хотите совсем разные сущности хранить в одной широкой таблице?

Добрый день. Прошу помочь.
Подключил dictionary (geoip в формате csv) к серверу. И почему-то простой селект на сервере в продакшене, как-то странно форматируется строку с ipv4 в 16-ричный формат. При том что на тестовом сервере всё нормально.
Тестовый сервер -
https://gyazo.com/f66da528a9ca6ffe05b3df6cd3786fe7?token=f32ab0f7d91e347721b38514b13d2d2f
Продакшен -
https://gyazo.com/5cf2ec410e759b61a82cf81d2e00271f

видимо еще один баг

совсем разные, но связанные по одному полю

да без разницы как они связаны,  смысл какой их пихать  в одну таблицу?

что лучше использовать в качестве workaround? можно ли по jdbc получить query id и связать его в записями из system.mutations?

select version() на обоих?

на тестовом сервере 21.6.6.51 , на проде 20.6.4.44

вообще вы понимаете зачем мутации? Они не предполагались к использованию как часть бизнес-процессов, поэтому я не хочу обсуждать это, потому что вы упомянули JDBC.

это poc по переезду timeseries с кассандры на clickhouse. процесс уже таков и менять его не хочется, если есть хоть какие-то варианты его сохранить. такие delete выпролняются всего 10-20 раз в день, что мне кажется допустимым

я понял, это select из словаря. Это не интересно. Это undefined behaviour