11016
Обсуждаем ClickHouse
вооот.... тут мы и поняли что надо что-то с этим делать )
Читать полностью…
а Файнал как я понял будет очень дорогой, если в базе уже будут миллионы строк.
Читать полностью…
Не удаляются. Надо использовать FINAL - https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-final-clause-speed/
Читать полностью…
1. Вместо FINAL можно использовать GROUP BY + функции вроде argMax(), но естественно тогда это вручную нужно прописывать
Читать полностью…
взял дэфолт конфигурацию на 3 реплики в clickhouse cloud
как энджин автоматом у всех таблиц SharedMergeTree
что показывает select * from system.clusters
Всем привет, вожусь с проблемой уже достаточно долго, но думаю, что решение элементарное
До этого всегда юзал оупенсурсный клик, сейчас решил попробовать Clickhouse Cloud + SharedMergeTree
Сделал сетап на 3 реплики, но проблема в том, что поехали все старые запросы.
Условно даже count(*) просто не тот, так как возвещает только кол-во строк на одном шарде (условно в таблице 170к, возвращается 2300)
Где можно почитать, что с этим делать? Заранее благодарен за ответ
Лимиты в целом штука очень нетривиальная для SQL баз почему-то
Читать полностью…
кликхаус не пробрасывает limit 10 на сторону MySQL - те он вычитывает все 6м записей. Пробрасывается только where. попробуйте where id = ? написать - должно моментально отработать как и в MySQL
Читать полностью…
ну тогда insert_quorum=число_реплик можно поставить и посмотреть не сильно ли начал лагать топик
Читать полностью…
а insert_quorum=N в связке KAFKA ENGINE -> MV не решит проблему реплиции на корню? Или в MV пихать не дает эту настройку?
Читать полностью…
Нет. При обновлении версии (если обновлять плавно, без даунтайма) блоки могут застревать из-за новой версии формата данных, и они не будут реплицироваться, пока не обновятся все узлы. Также при любом скачке нагрузки, сбое сети и т.д. задержка может увеличиваться непредсказуемо
Читать полностью…
Нет гарантии, когда блоки доедут, схема нерабочая
Читать полностью…
Репликация асинхронная, так что инкремент точно работать надежно не будет
Читать полностью…
🤖 Я позвал админов, а больше ничем не могу помочь.
Мне не выдали прав на удаление сообщений, поэтому у меня лапки.
Это осуществляется фоновыми мержами, нет никакой гарантии, когда они запустятся
Читать полностью…
удаляются, проверяли, там на фоне видимо дефолтная политика бежит (мы сделали дефолтную инсталляцию) и через 4-5 минут старая строка удаляется из базы
Читать полностью…
вручную в смысле в самом квери по таблице? потом что там старые строки как показывает практика удаляется только в течени 4-10 минут
Читать полностью…
пересоздал инстансы, прогнал миграции снова и вроде бы починилось... не менял ничего абсолютно
Читать полностью…
Всем привет, я новичок с ClickHouse, есть вопрос:
У нас одна большая таблица в ClickHouse (ожидаются сотни миллионов строк), хотим избежать join'ов. Для реализации обновлений используем ReplacingMergeTree с колонкой version.
1. Как правильно забирать только последнюю версию строки по ключу (без использования FINAL в проде)? На самом деле задачи не вообще строку забрать а построить квери по всей таблице так, чтобы старые дубли были проигнорированы
2. Какие подводные камни у такого подхода на больших таблицах? Как избежать merge-затор, как поддерживать производительность?
3. Есть ли best practices по управлению размерами и скоростью фоновыми merge-ов?
Интересует опыт реального продакшна.
вы точно реплики сделали а не шарды?
вообще sharedmergetree никаких реплик не надо насколько я помню
Вот тут в pr написано почему все непросто https://github.com/ClickHouse/ClickHouse/pull/80070
Читать полностью…
ещё раз спасибо, нащел в документации
надо более внимательней читать
“The rest of the conditions and the LIMIT sampling constraint are executed in ClickHouse only after the query to MySQL finishes.”
Всем привет.
Создал таблицу используя ENGINE = MySQL
Таблица в 6M записей, проблема в том что если я делаю запрос на mysql стороне всё летает
select * from some_table limit 10;
а вот на стороне clickhouse всё как виснет, хотя есть другие таблицы в 2M записей читает быстро.
Может кто то сталкивался?
Спасибо
если в шард вставляете, то решит по идее, если не в шард, то есть insert_distributed_sync настройка, но наверное оно может затормозить вставку прилично
Читать полностью…
есть настройка max_replica_delay_for_distributed_queries (по умолчанию 300 сек)
If set, distributed queries of Replicated tables will choose servers with replication delay in seconds less than the specified value (not inclusive). Zero means do not take delay into account.
она говорит выбирать реплики у которых < max_replica_delay_for_distributed_queries delay на селект из дистрибьютед таблицы, так что можно ее выкрутить на минимум по идее, чтобы не было отставания при селекте
Нет гарантии, но как будто по вероятности 5-10 минут достаточно здоровому кластеру реплицироваться нормально в большинстве случаев?
Читать полностью…
Благодарю, видимо нужно лаг делать по временному окну, чтобы дать данным "растечся"
Читать полностью…
Всем привет, пытаясь со случайно реплики вычитать инкремент из распределенной таблицы в которую на каждый шард пишет MV из Kafka engine, может ли репликация на какой то реплике не успеть доставить строчки на другую (если вот вот во время чтения была запись из Kafka) с которой мы пытаемся вычитать?
Читать полностью…
ClickHouse uses one of previous versions of CityHash from Google.
CityHash у гугла менялся раза 3, кх понятно не может себе такое позволить, он же персистентный.
ну и да разница есть, например clickhouse cityHash64 for integers falls back to intHash64
т.е. проще всего использовать другую хешфункцию