в ReplicatedMergeTree.
Есть 2MergeTree таблицы 4.32B записей 34 поля, и 8.85B записей 38 полей записей.
Создали 2 таблицы НО:
1. поменяли Order by
2. Добавили одно поле, которое вычисляется из уже существующих.
Запустили insert select на той что меньше, выполнялась больше 12 часов, потом упало вот так:
↑ Progress: 4.07 billion rows, 957.16 GB (95.72 thousand rows/s., 22.51 MB/s.) █████████████████████████████████████████▋ 93%
Received exception from server (version 19.15.3):
Code: 252. DB::Exception: Received from XXX.XXX.XXX.XXX:YYYY. DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts..
0 rows in set. Elapsed: 42527.668 sec. Processed 4.07 billion rows, 957.16 GB (95.72 thousand rows/s., 22.51 MB/s.)
1. Почему так медленно может копировать?
2. Можно ли как-то продолжить оттуда, где упало?
3. Может, можно это провернуть как-то элегантнее?
а вы прямо колонка в колонку переливаете и меняли только движок? или структуру тоже меняли?
струкутуру меняли. Добавили одно вычисляемое поле + поменяли ORDER BY ключ
а это в рамках одного сервера?
да, сервер тот же
Много партиций наверное, в одном инсерте
1. потому что надо отсортировать вставляемый парт. 100тыс. строк в сек. это отличная скорость. Есть параллелизация max_insert_threads = 5 но вам это только хуже сделает. 2. продолжить нельзя. 3. делаем кусочками, по одному дню. День скопировали, ждем пока помержится, дальше еще один день.
ну у вас при вставке блоки по миллиону записей в отдельный part вставляются попробуйте поиграться с block_size константами https://clickhouse.tech/docs/en/operations/settings/settings/ и https://clickhouse.tech/docs/en/operations/settings/settings/#settings-max-insert-threads
Спасибо, изучу. По совету Дена перенёс частями. Отлично вышло
Обсуждают сегодня