11016
Обсуждаем ClickHouse
а может есть возможность доставать эти ид уже из таблицы куда этот батч вставлен ?
если нет
тогда сделайте временную таблицу в памяти и оттуда
where id in (select id from temp_table)
возможно вам CTE не нужно
у вас, как я понял, where in (list_of_ids) и этот list_of_ids генерируется скриптом ?
я такой момент обошел за счет создания временных таблиц или подзапросов (смотря что нужно в каких случаях)
Читать полностью…
Всем привет. Какие есть подводные камни увелечения 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 минут
Читать полностью…
да, я из бачта достаю уникальные ids и генерю запрос
Читать полностью…
ну у меня там и так уже есть стейджовая таблица для левой таблицы. А для правой 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(), но естественно тогда это вручную нужно прописывать
Читать полностью…