11016
Обсуждаем ClickHouse
ну у меня там и так уже есть стейджовая таблица для левой таблицы. А для правой CTE в которой как раз и ошибка. Возможно между надо какую-то временную таблицу сделать и для правой.
Читать полностью…
Из подводных камней - если у вас в IN значений на 2 Мб, то, скорее всего, запросы будут еле ползать. А так увеличивайте, почему нет то.
Читать полностью…
Если вы про max_threads, то я с зафиксированным количеством в 16 тредов проверял
Читать полностью…
написать issue кликам, если вы правы - это "общая" проблема и ее бы поправить
Читать полностью…
Доброго времени суток , смотрите какой вопрос , мне необходимо скопировать из MySQL в ClickHouse около 1 миллиарда записей , для этого я залинковал таблицу и с помощью скрипта копировал по определенному количеству записей
INSERT INTO dbo.table1
SELECT
created_at,
data_hash,
CAST(id AS UUID) AS id,
receipt_hash,
source_table,
updated_at
FROM dbo.table2
WHERE created_at >= '2024-03-31 14:56:46'
AND created_at < '2024-04-15 14:56:46';
Но у меня начала появляется вот такая ошибка
SQL Error [1000] [08000]: Poco::Exception. Code: 1000, e.code() = 2013, mysqlxx::Exception: Lost connection to MySQL server during query (10.107.81.4:3306) (version 24.5.1.1763 (official build))
Кто знает в чем проблема и как можно ее решить , заранее спасибо!
Это уже лирика и эмпирика. Главное, что есть решение ,)
Читать полностью…
Final проще в запросе написать, но argMax по ресурсам выигрывает
Читать полностью…
у нас главный поинт - одна плоская таблица
Читать полностью…
Мы триллионы строк хранили на одном хосте, и было норм :)
Читать полностью…
вооот.... тут мы и поняли что надо что-то с этим делать )
Читать полностью…
а Файнал как я понял будет очень дорогой, если в базе уже будут миллионы строк.
Читать полностью…
Не удаляются. Надо использовать FINAL - https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-final-clause-speed/
Читать полностью…
1. Вместо FINAL можно использовать GROUP BY + функции вроде argMax(), но естественно тогда это вручную нужно прописывать
Читать полностью…
взял дэфолт конфигурацию на 3 реплики в clickhouse cloud
как энджин автоматом у всех таблиц SharedMergeTree
я такой момент обошел за счет создания временных таблиц или подзапросов (смотря что нужно в каких случаях)
Читать полностью…
Всем привет. Какие есть подводные камни увелечения max_query_size до например 2mb? История в чем - надо поджойнить две таблицы (писал уже выше) и для таблицы с права (это таблица users) подготавливаю dataset с условием WHERE id in (...). Запросы стали пролезли по памяти, но там где слева кардинальность поля высокая, запросы падают с ошибкой по этому параметру.
попробуй задать количество потоков в settings для обоих кликов, возможно там дефолтное кол-во поменялось
Читать полностью…
Всем привет. У меня проблема с обновлением кх с 24.3 до 25.3.
Сильно проседает скорость вставок из jsoneachrow файлов в MergeTree таблицы.
Становится примерно в 1.5-2 раза медленнее. Это заметно только когда нагрузка на кх высокая — старый кх использует больше цпу, а новый отдыхает.
В кх 12TiB данных, 2.3к баз данных и 165к таблиц.
я потестил на разных версиях кх, и выяснил что деградация в перформансе происходит при переходе с v24.5 на v24.6.
Подскажите, в какую сторону можно поисследовать
в доке сказано что работает только с select_sequential_consistancy=1 insert_quorum_parallel=0 insert_quorum>=2 ....
значит с остальным тупо вообще не работает
engine=distributed вообще ничего не знает про состояние целевой таблицы не реплике в SELECT, только replication_delay
можно попробовать конечно max_replica_delay_for_distributed_queries=1 выставить...
но тогда вообще непонятно как вы собираетесь конкурентные insert делать которые тупо ничего друг о друге не знают на разных репликах и всегда будут давать replica_delay > 1
может вам проще на клиенте умную балансировку организовать
чтобы и INSERT и SELECT на одну реплику приходил?
или у вас там куча конкурентных INSERT?
если еще и маленькие батчи, то вы клик тупо убиваете и не надо так...
Ну за свежие версии не скажу точно. Раньше так было
Читать полностью…
С чего бы это так категорично? Версия, колонки в запросе, партиционирование, order by таблицы, включенные оптимизации - все влияет. Прошло то время когда можно было уверенно говорить что argMax выигрывает.
Читать полностью…
final очень оптимизированный. При правильном партиционировании, при наличии 1 парта в партиции FINAL автоматически пропускается. Запускайте OPTIMIZE FINAL на старые партиции и будет вам счастье
Читать полностью…
Не нужно использовать GROUP BY вместо FINAL в свежих версиях если колонки группировки такиеже как ORDER BY таблицы. Это не быстрее, а скорее - медленнее
Читать полностью…
Это осуществляется фоновыми мержами, нет никакой гарантии, когда они запустятся
Читать полностью…
удаляются, проверяли, там на фоне видимо дефолтная политика бежит (мы сделали дефолтную инсталляцию) и через 4-5 минут старая строка удаляется из базы
Читать полностью…
вручную в смысле в самом квери по таблице? потом что там старые строки как показывает практика удаляется только в течени 4-10 минут
Читать полностью…
пересоздал инстансы, прогнал миграции снова и вроде бы починилось... не менял ничего абсолютно
Читать полностью…
Всем привет, я новичок с ClickHouse, есть вопрос:
У нас одна большая таблица в ClickHouse (ожидаются сотни миллионов строк), хотим избежать join'ов. Для реализации обновлений используем ReplacingMergeTree с колонкой version.
1. Как правильно забирать только последнюю версию строки по ключу (без использования FINAL в проде)? На самом деле задачи не вообще строку забрать а построить квери по всей таблице так, чтобы старые дубли были проигнорированы
2. Какие подводные камни у такого подхода на больших таблицах? Как избежать merge-затор, как поддерживать производительность?
3. Есть ли best practices по управлению размерами и скоростью фоновыми merge-ов?
Интересует опыт реального продакшна.