Всем привет. Наблюдаю, как в некоторых проектах начинают использовать ClickHouse не только для аналитики, а как основное хранилище для операционных данных. Сначала это были просто логи и метрики, но сейчас уже видны попытки запихнуть туда заказы и пользовательские сессии. Вопрос к тем, кто реально пробовал: насколько это больно на дистанции?
Я понимаю, что для точечных чтений по ключу CH не создан, но с учётом MERGE-движков и нормальных партиций, может, это рабочий вариант для проектов, где аналитика важнее транзакций? Лично я пока остаюсь на постгресе с отдельной аналитической выгрузкой, но тенденция напрягает: слишком много коллег пытаются сделать из молотка отвёртку.
Кто-нибудь гонял ClickHouse под OLTP-нагрузкой? Интересно мнение про реальные latency, деградацию при апдейтах и то, как вы решаете проблему уникальности данных. Или я зря скептичен, и это новый тренд, который я проспал?
💡 1
Слушай, я как раз из тех, кто любит экспериментировать, но тут я с тобой солидарен — это чистой воды попытка забить микроскопом гвозди! 🔧 Я понимаю, почему народ тащится от CH: скорость вставки и агрегации на объёмах просто зверская, а партиции позволяют удобно резать данные по времени. Но когда начинаются точечные апдейты или хотя бы попытки сделать `UPDATE` по ключу — начинается ад. Уникальность приходится выдумывать через `ReplacingMergeTree` с версионированием, а это, по сути, костыль, который прилетает тебе в лицо на дистанции: чтение по одному ключу превращается в сканирование партиции с последующим мержем, и вся молниеносность CH испаряется.
Но знаешь, я не сказал бы, что это совсем ересь. Если проект — это, например, IoT-платформа, где каждое устройство шлёт телеметрию раз в секунду, а «операционные данные» — это просто свежие сенсоры, которые редко обновляются, то CH может быть оправдан. Тут главное — честно ответить себе на вопрос: твои «заказы» — это immutable-события или живые сущности, которые меняются по сто раз? Если первое — то добро пожаловать, CH справится с логом заказов, а аналитика будет встроена. Если второе — то ты прав, лучше остаться на постгресе, а CH использовать как зеркало для выгрузок. Я бы сказал, что тренд не про «CH вместо OLTP», а про «CH как слой для событийного ядра», и вот это уже выглядит осмысленно. Главное — не пытаться делать из молотка отвёртку, а брать его для забивания гвоздей! ⚡
«ReplacingMergeTree с версионированием» — это не костыль, это попытка спрятать голову в песок. Ты прав насчёт immutable-событий, но даже тут CH подводит: точечное чтение по ключу из партиции — это не «сканирование», это гарантированный full-scan по гранулам, и на дистанции с ростом объёма ты получишь latency, который убьёт любой OLTP-сценарий. Я пробовал гонять его под «операционкой» с телеметрией — вставка огонь, но как только понадобилось вытащить состояние конкретного устройства за последний час, CH начал курить бамбук, а постгрес с индексом по (device_id, ts) сделал это за миллисекунды.
Тренд, который ты описал, — это не «CH как слой для событийного ядра», это просто лень: люди не хотят держать две базы и синхронизировать их, поэтому пытаются впихнуть невпихуемое. Да, для чисто append-only логов с редкими чтениями он сгодится, но называть это OLTP — самообман. Пока у тебя нет жёстких требований к консистентности и апдейтам, CH — это аналитический молоток, и не надо делать из него отвёртку, потому что отвёртка из него получится кривая и тупая.
