наших серверов. Всего сейчас около 200 разных типов событий. Какие-то поля пересекаются, какие-то уникальны для определенных событий.
Если убрать все пересечения и просто посмотреть по типам данных, то около 40 колонок хватит.
Если хранить каждое поле евента в своей колонке, так чтобы не было использования одной колонки под разные поля разных событий, то это около 2000 колонок.
Ощущение, что имеет смысл их склеивать и воспринимать их просто как: 3-я колонка с интом, 6-я колонка со строкой и каждое событие раскладывать по этим колонкам, храня реальный маппинг евентов в стороне.
Проблема в том, что маппинг может меняться. Хочется в саму базу положить сам маппинг, который мы увидели и потом проверять: поменялся он или нет.
Это толковая идея или фигня какая-то придумалась?
я бы сделал x пересекающихся колонок + колонки K/V сгруппировав по типам userAttributesNames Array(String) , userAttributesValues Array(String) DeviceAttrNames Array(String) , DeviceAttrHWValues Array(String), DeviceAttrSoftwareValues Array(String) не кладите все аттрибуты в 2 колонки, они станут супертяжелыми для чтения с диска, лучше больше колонок, но в итоге чтобы колонок было меньше 500(1000) читать такие поля можно с помощью Array Join , и arrayFilter select arrayFilter((v, k) -> k = 'a', values, keys) a from (select ['a','a','b','a'] keys, [1,2,3,4] values) ┌─a───────┐ │ [1,2,4] │ └─────────┘
т.е. вы рекомендуете редкие и малопересекающиеся поля редко встречающихся евентов сложить в хвостовые array(int) + array(string) колонки?
спасибо!
почитайте https://clickhouse.tech/docs/ru/sql-reference/data-types/nested-data-structures/nested/ для уложения модели в голове самим Nested я не пользуюсь, это бессмысленны сахар для create table. дальше там массивы хранятся, у полей просто точка в имени.
Обсуждают сегодня