Так, уже чуть более понятно.
Непонятна логика - вот если у меня один сторадж - мне его куда класть? И туда и сюда? Или только в одну из опций - path или storage_configuration?

тогда не делайте storage_configuration совсем и используйте path, просто проще...

То есть получается что они в каких-то случаях взаимозаменяемые?
Это не совсем понятно из документации

но mdraid порвет storage_configuration по скорости раз 5 - есть ли какие-то тесты на это? чтобы сослаться. Заранее спасибо

если не определен policy - используется path

Аллилуйя, спасибо, теперь до меня дошло.

Спасибо ребзи

вас чем не устраивает /var/lib/clickhouse ?

Екатеринбург?

это про 6 volume / disks в storage_configuration VS 6 дисков в mdraid

Устраивает, непонятно было как вместе использовать path и storage_configuration, подсказали что если нет policy тогда будет path использоваться

инфа сотка? Спасибо, буду много думать
А какой рейд имеется ввиду?

в 80х в Череповце вполне так говорили

Захотел пересмотреть Boston Legal

10й

я чего-то непонимаю, то у вас один диск то много

Пишем ансибл роль, будет поддерживать и то и другое

О, что индекс всегда в памяти не знал. Спасибо.

Я как раз на выходных пробовал подобрать оптимальный index_granularity для таблицы BigTable (id UUID, ts DateTime, ...) engine=MergeTree() order by (toDate(ts), id), которая используется в запросах вида select * from BigTable where id in (select id from SmallTableWithRandomIDs) and ts>=today()-7.

И результат получился странный: с уменьшением index_granularity (пробовал варианты от 1024 до 8) у меня уменьшался объём используемой памяти, уменьшалось количество прочитанных строк, но увеличивалось время выполнения запроса.

С прочитанными строками и памятью понятно, этого и добивался. Можете объяснить почему увеличилось время запроса (ведь дорогих чтений с диска столько же, размер обрабатываемых в памяти блоков тоже меньше)?

>с уменьшением index_granularity меня уменьшался объём используемой памяти
чего? что? памяти используемой запросом? или сервером?

возможно ваш запрос поднимает засечки в кэш
кэш засечек это отдельная боль https://github.com/ClickHouse/ClickHouse/issues/18692#issuecomment-754334323
КХ совершенно не подходит для запросов select * from BigTable и для маленьких index_granularity

используйте mdraid с far2 layout

Это получается двойной redundancy - будет и реплика внутри replicated merge tree, и в raid10 будет дубликат данных, слишком жирно