Всем привет Парочка вопросов по дискам, i/o. Заранее спасибо за любую

инфу

(Этот абзац можно скипнуть, если лень вдумываться в контекст) Исходная проблема. Есть растущая 40тб база, две реплики без шардов, диски 10x10тб raid10, хецнер. Достаточно часто гоняются плохоиндексируемые достаточно произвольные селекты по довольно большой части данных, диски утилизируются этим более-менее наполную (~1G/s), люди желают скорости в сколько-то раз больше. Растут и усложняются требования. Мне кажется разумным вариант пока (до стабилизации общей картины) закидать это всё nvme ssd. Предположим, бюджета пока можно выделить только на 3 шарда по 6 дисков (чтоб хоть хватало места) (а реплику оставить на одной машине с hdd и для селектов не использовать, т.к. производительности ssd-машин должно хватить на всё, по идее).
Из этого следует, что ssd будут "без рейда", т.е. варианты: 1) raid0 2) jbod storage policy 3) внутри машин по контейнеру-шарду на диск

Теперь основной вопрос №1. Контекст - опять же, топорный сценарий "по primary key фильтруется много терабайт, неск произвольных where + count-distinct". Я никак не могу понять, как именно в CH устроена параллелизация чтения с диска(ов), у меня не получилось найти информацию на эту тему. Какие и как особенности данных на это влияют (кол-во партиций, колонок, или нет, или что ещё)? Настройки - max_threads?
Т.е. для большей уверенности хочется понимаить, как CH сможет эффективно утилизировать nvme ssd - тредами и-или поддерживанием большой queue depth, и можно ли на это влиять. (Ну и правильнее настраивать fio для бенча)

Вопрос №2
Из вышеупомянутых трёх multi-disk вариантов (raid0 | jbod storage policy | контейнеры-шарды) существенна ли разница по параллелизуемости/предсказуемости между ними? Если нет, я бы склонялся к jbod, т.к. jbod, по идее, проще настроить и починить (просто заменить диск, и кх перескачает данные с реплики, правильно?), а raid0 ломается целиком, а контейнеры-шарды это головняк. Разумно?

Вопрос №3
По проверке целостности. Во время селекта CH проверяет целостность читаемого? Можно ли отдельно специально триггернуть проверку целостости партов, например? Или разумно ли использовать zfs(linux) и просто периодически гонять scrubbing?

1. только шардирование позволяет масштабировать кратно, но важный момент что только если выключить/избежать группировки на инициаторе. 2. один cpu core может распаковать поток 500МБ/c, если вы сможете читать 4 ГБайта/c вам надо 8 коров на распаковку, дальше это возможно превратится в 40ГБ/c и вы упретесь в скорости шин памяти и cpu. 3. NVME ни разу не серебряная пуля, и зачастую никакого прироста производительности не дает. 4. в хецнере сеть бесплатная только 1Гбит 5. зачастую дешевле взять много более дешевых серверов чем мало толстых 6. чем больше данных на сервере, тем сложнее наливать реплику при сбое. 7. JBOD, мультидиски самого КХ, не дают никакого прироста производительности, только mdraid / raid10 / raid0 дают кратный прирост. 8. ускорение запросов, уменьшение обрабатываемых данных, предагрегация, дают прирост в 10 - 100 раз. 9. КХ адово обложен чексуммами, при чтении данных чексуммы файлов проверяются, при репликации тоже. Ничего не надо триггерить, все уже встроено. 10. Все практически параллельно выполняется. Данные читаются через первичный индекс всегда (типа index-organized-table), по гранулам, гранулы делятся между тредами, если надо прочитать 8 гранул и есть 8 потоков, то каждый поток будет обрабатывать одну гранулу, читать с диска, декомпрессить, фильтровать, и т.д.

>7. JBOD, мультидиски самого КХ, не дают никакого прироста производительности я эту идею взял отсюда https://altinity.com/blog/2019/11/29/amplifying-clickhouse-capacity-with-multi-volume-storage-part-2 >Read/write speed gains in certain conditions, such as when multiple threads use different disks in parallel. но там без пруфов.. а вот тут https://www.slideshare.net/Altinity/webinar-slides-more-secrets-of-clickhouse-query-performance-by-robert-hodges-altinity-ceo слайд 39-41 - судя по графику на 41, человек проверял. вы уверены, что не дают? :) Я бы протестил, но, к сожалению, сейчас сроки жмут..

Если парты находятся на разных дисках, то ускорение есть, пропорциональное числу дисков в JBOD. Но допустим точечный запрос читающий один парт никак не ускориться

вот эти пункты 3. NVME ни разу не серебряная пуля, и зачастую никакого прироста производительности не дает. 7. JBOD, мультидиски самого КХ, не дают никакого прироста производительности, только mdraid / raid10 / raid0 дают кратный прирост. выглядят противоречием. NVME в несколько раз увеличивает линейную скорость, raid0 -удваивает её плюс удваивает IOPS. но iops для КХ вроде не нужен?

>4. в хецнере сеть бесплатная только 1Гбит 10Г внутри хецнера - трафик тоже бесплатно (но за "размещение" и карту - €39, да). Но агрегируются между шардами ведь только результаты их выборок? - т.е. итоговый результат запроса сейчас - маленькая табличка, т.е. диск читается только для обсчёта, в клиент исходные данные не идут. Если я правильно понял посыл ответа. Или, в смысле, что тяжело будет реплицировать по 1Г при проблемах? Это да.. (но допустем терпимо, на салфетке, но ещё подумаю)

тут нет противоречия. Во первых там слово зачастую, во вторых объяснено почему при 4 ГБ/c начинаются другие проблемы, особенно в хецнере, там у серверов очень слабые CPU. И я сравниваю 10HDD в raid10 VS 1 NVME, а не 10HDD vs 10 NVME

если запрос более менее сложный с подзапросами, довольно часто нужно немного "попотеть" чтобы написать его правильно. были тикеты по этому поводу...

1ГБ будет проблемой при передаче огромного объема с шардов на инициатор, надо думать как шардировать данные, заранее

так это не проблема. он просто упрётся в скорость cpu раньше, т.е. не получит 6-кратного выигрыша как можно ожидать из сравнения скоростей самих ssd

внутри хетцнера - 10гбит

ну и какой смысл было покупать NVME если мы упираемся в CPU?

они по цене всего раза в два дороже, так что смысл есть даже если скорсость хотя бы на 30% вырастет

чем HDD? нет конечно

чем sata ssd

Если вам хватает денег чтобы хранить всю дату на ссд, какие у вас вообще могут быть проблемы?

да пофиг на sata ssd. Они вообще потеряли смысл. Ну и в хецнере выбор такой либо 10 HDD * 10TB , либо 2 NMVE по 2TB (или 4TB), и перфоманс КМК будет сравнимый

да, 2 nvme уже упираются в скорость pcie i/o на десктопах, дальше нужен hedt/server cpu. но у автора вопроса видимо объём данных позволяет хрнаить всё на ssd

https://tanelpoder.com/posts/11m-iops-with-10-ssds-on-amd-threadripper-pro-workstation/ :)

это hedt. вы какой вообще сервер брать собираетесь? если ещё не, почитайте про различные процы - сколько там ядер, на какой частоте, что там с pci-e и связью между сокетами