ceph?
1. Насколько он нормально/быстро работает?
2. Нормально ли работает ttl (слышал, что из бакета клик не умеет удалять данные и бакет пухнет)
3. По какому принципу клик выбирает данные для переноса на другой volume, которые контролируются move_factor?
1. в проде сам не юзал, но общая рекомендация оно работает, но включайте локальный кеш и добавьте send_metadata, и ceph все равно придется уметь готовить... может вам лучше kubernetes + https://github.com/kubernetes-csi/csi-driver-iscsi или LINSTOR + drbd через https://github.com/piraeusdatastore/piraeus-operator ? раз уж у вас дисковая полка уже есть 2. клик данные из бакета удаляет, но только когда когда считает что на них нет ссылок с локальных дисков из /var/lib/clickhouse/disks/disk_name, там кажется есть баг с DROP DATABASE, ttl пофигу на то где данные лежат, если prefer_do_not_merge в storage_policy не включать, то должен работать 3. данные выбираются в момент background merge и в момент вставки... и кажется с учетом reserved space под мержи... (тут не помню точно)
1. Понял. погляжу. 2. Понял. спс. 3. Ок. А переносятся данные по принципу, сначала старые, а потом новые? Что произойдет, если диск заполнен больше чем move_factor и прилетает новый батч для записи? Новые данные вытеснят старые или новые данные будут записаны на след. volume сразу?
3. тут сложно, боюсь наврать. вроде бы при вставке все таки на первый по порядку volume и рандомный из него диск запишется см. perform_ttl_move_on_insert , если move factor есть... То TTL тред, будет сначала большие потом меньшие парты переносить, там еще есть всякие keep_free_space_bytes, главное не вздумайте медленный и быстрый диск в один volume загнать советую еще раз перечитать внимательно https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-multiple-volumes_configure
Обсуждают сегодня