11016
Обсуждаем ClickHouse
кстати background_distributed_schedule_pool_size влияет только если таблиц много, а так там однопоточный процесс пер таблица
Читать полностью…
ну и вообще можно
clickhouse-client --receive_timeout=86400 -q "SYSTEM DISTRIBUTED FLUSH"Читать полностью…
кто-то пытается s3 one-zone - оно типа дешевле.
можно еще s3_plain_rewritable starting from 25.4. Но там несимметрично - писать можно только на одну ноду.
А вобще все побежали в сторону Iceberg. Счастье будет где-то там. Но это не точно.
ну и в довесок, с "пуллом" задержки будут больше, что не есть хорошо
Читать полностью…
Все используют x3 размеры в S3 для реплицированных данных? Это затратно по деньгам
Читать полностью…
ну поймал ))
что делать-то? pull не вариант для event-driven задач
с AWS не ловил проблем на мутациях. zero replication даже в 24.8+ остается экспериментальным?
Читать полностью…
У вас еще и zero replication наверное.
теоритически эту проблему должен был решить coalescingmergetree
Читать полностью…
а если через MV в target table c Engine=URL?
Читать полностью…
Потеряно несколько партов данных на диске S3 в AliCloud. Мутации апдейт данных падают с ошибкой ниже.
Явная несовместимость КХ с аликлаудом. Есть список не рекомендованных s3 движков?
Как восстановить данные? Много партов в detached/broken
Code: 499. DB::Exception: The specified key does not exist.: while reading key: clickhouse3/sgf/zyshclfirpinnjvvnpqdewkdovvzu, from bucket: my-bucket: Cache info: Buffer path: clickhouse3/sgf/zyshclfirpinnjvvnpqdewkdovvzu, hash key: e9c56fb57399082aabebb180c39cc91c, file_offset_of_buffer_end: 224395264, read_until_position: 228891447, internal buffer end: 224395264, read_type: REMOTE_FS_READ_AND_PUT_IN_CACHE, last caller: 9e8c0da4-1fa6-405c-b577-a07c4ca7c9d2::202410_0_185_3_270:2101396, file segment info: File segment: [224395264, 226492415], key: e9c56fb57399082aabebb180c39cc91c, state: DOWNLOADING, downloaded size: 0, reserved size: 0, downloader id: 9e8c0da4-1fa6-405c-b577-a07c4ca7c9d2::202410_0_185_3_270:2101396, current write offset: 224395264, caller id: 9e8c0da4-1fa6-405c-b577-a07c4ca7c9d2::202410_0_185_3_270:2101396, kind: Regular, unbound: 0: (while reading column platform_time): (while reading from part /var/lib/clickhouse/disks/s3_disk/store/9e8/9e8c0da4-1fa6-405c-b577-a07c4ca7c9d2/202410_0_185_3/ in table my_db.my_table (9e8c0da4-1fa6-405c-b577-a07c4ca7c9d2) located on disk s3_cache_encrypted of type s3, from mark 7545 with max_rows_to_read = 65409): While executing MergeTreeThread. (S3_ERROR) (version 23.8.8.20 (official build))Читать полностью…
`ENGINE = ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}/{uuid}', '{replica}')
PARTITION BY data_chunk_date
ORDER BY (country_id, client, action, component, screen, section, server_timestamp, timestamp, cityHash64(user_hash))
SAMPLE BY cityHash64(user_hash)
TTL
data_chunk_date TO VOLUME 'fast',
data_chunk_date + INTERVAL 3 MONTH TO VOLUME 'default'
SETTINGS
storage_policy = 'tiered_storage',
index_granularity = 8192,
replicated_deduplication_window = 1000;
параллельно? во время тестов не было вставок
Читать полностью…
Универсальный формат данных в S3 хранить удобно, однако апдейтить в КХ нельзя пока
Читать полностью…
это не репликация это вставка в distributed таблицу...
не надо ничего перемещать
увеличьте
background_distributed_schedule_pool_size
включите
distributed_background_insert_batch
если выключено
https://clickhouse.com/docs/engines/table-engines/special/distributed#distributed-writing-data
Всем привет. Подскажите, пожалуйста:
Два шарда, по две реплики. Некоторое время не работала корректно репликация между двумя серверами (из-за проблем на них) из-за чего скопилось много bin-файлов в data/database/table/shard2_replica1 (порядка 70 ГБ мелких файлов) и процесс синхронизации сильно тормозит.
Есть ли возможность переместить эти файлы из указанной директории и потом порциями подкладывать? чтобы внутренним механизмом они самостоятельно записались или только перезаливать?
парты качают ноды друг у друга напрямую
а о том, что скачать и у кого - узнают из кипера.
на пулл мне надо держать все 24\7, с пуш я могу условный эндпоинт триггерить только когда есть сообщение, за эндпоинтом может висеть лямбда, которая будет съедать мне 0 денег, пока ничего не делает
Читать полностью…
имхо zero replication не поддерживается и не развивается
вангую никогда не будет не экспериментальным, скорее удалят вообще эту фичу
это не из-за АлиКлауд
это из-за zero replication + мутации. Это известная проблема.
Надо вам апгрейдится в 24.8+
И обязательно выключить zero replication. Иначе вы гарантировано будете терять данные при мутациях.
23.8.8.20 ???? в той версии КХ S3 был не продакшин рейди
У вас еще и zero replication наверное.
Удалять вам надо партиции drop partition - данные потеряны
Привет.
Может будут идеи по моей проблеме.
Есть таблица с движком ReplacingMergeTree, в ней 500млн строк и под сотню полей, версионное поле - дата.
Данные в нее идут из двух топиков Kafka через матвьюхи.
Из первого топика инсерты, с ними проблем нет.
Из второго требуется делать апсерты: обновить пришедшие поля, сохранить текущие.
Я сделал апсерты в матвью с джойном на целевую таблицу, т.е. на каждое сообщение идет джойн по ключу одной строки из большой таблицы.
Проблема в том что таблица на 500млн с правой стороны джойна и клик пытается создать в памяти хеш для джойна.
Вытащить строку в WITH не получится, зависимые подзапросы не работают.
SETTINGS join_algorithm = 'full_sorting_merge' на матвью тоже не помог, клик все равно пытается создать хеш в памяти на 500 млн строк.
>всем привет. а какие варианты нотификации в КХ есть?
нету, никаких.
>Engine=URL() и Engine=Kafka()
неприменимо в реальной жизни, работает только в тестовых примерах helloworld
у меня рядом есть таблица куда я точно так же копирую и там партиция 20гб и шард ключ рандомный - и здесь у меня нет проблем, только с этим кейсом
после того как я сменил шард ключ на хеш - стало лучше, но не окончательно