а хотя в доке написано что там просто карусель

Внутри тома выбирается следующий диск после того, на который была предыдущая запись и на котором свободного места больше чем размер куска (unreserved_space - keep_free_space_bytes > current_part_size)

где то различаются между собой диски в 10 раз, где-то в 1.5, где то в 2. Но в  основном преобладает первый заданный диск, только в одном сервере из 12 второй диск больше первого в 10 раз, свободное пространство на диске +/- одникаово, конфиги везде одинаковы тоже

как вы смотрите? select count() .... system.parts where active ?
как полиси написана?

я смотрю по занимаемому месту на диске, и сравниваюсь.

<yandex>
 <storage_configuration>
   <disks>
     <disk_home>
         <path>/home/clickhouse/data/</path>
     </disk_home>
     <disk_data>
         <path>/data/clickhouse-data/</path>
     </disk_data>
   </disks>
   <policies>
     <data_policy> <!-- name for new storage policy -->
       <volumes>
         <clickhouse_data_volume> <!-- name of volume -->
           <disk>disk_home</disk>
           <disk>disk_data</disk>
         </clickhouse_data_volume>
       </volumes>
     </data_policy>
   </policies>
 </storage_configuration>
<!-- Path to data directory, with trailing slash. -->
<path>/home/clickhouse/default/</path>
</yandex>

Cannot update user ananth in [users.xml] because this storage is readonly:
<!-- User can create other users and grant rights to them. -->
            <access_management>1</access_management>
i added this tag in user.xml file
need to add any other tags

блин, тогда эт не так уж хорошо если рейда нет и объёмы записи неудачно распределены...

АПД. Другие базы обычно управляют экстентами на дисках которыми сами управляют и балансируют пропорционально доступному объему. Тут бы по идее тоже weighted-Round-Robin или Deficit Round-Robin применять...

Кстати, а какая бест практис относительно рейдов из механических дисков? Я же правильно понимаю, что если для запроса надо выполнить 20 чтений, то если они распределятся по 20 дискам по 1 чтению на диск, то это идеально.
А если будет 20 обращений к рейду, который создаст 20 чтений на каждый диск, то хуже некуда?

увы, нет

рейд сам по себе достаточно хорошо умеет умножать скорость чтения/записи на дисках.

если у вас сас и контроллер хороший, проблем нет в принципе. это норма, в этом суть рейда (увеличивать производительность параллельными обращениями)

Но, по сути, iops для мелких чтений останется константным при увеличении количества дисков?

Ну смотря, что за рейд 10 допустим делает их больше, а так вообще кликхаус старается экономно иопсы расходовать и читать крупными кусками.

нет, если мы о raid0/10. увеличивается линейно
вы в рейд отправили 10 запросов по 4к. они идут по 5 на один и другой диски в рейде. страйп сайз в рейде обычно больше чем один ИО size (минимум 64к).

Всем привет!
А кто-то имеет опыт эксплуатации клика поверх cephfs?

Смысла нет.

Я такого же мнения, но коллеги из отдела эксплуатации хотят пилот сделать

Единственный бенефит, который я сам смог выдумать - можно отказаться от репликации через zoo. Но с точки зрения монтрирования блочных устройств кажется что это будет ад.

если есть 100+ OSD, и сеть 100G - то наверно будет выигрыш.