Сегодня процессоры на сотни ядер перестали быть фантастикой: линейки Intel Granite Rapids и Sierra Forest уже предлагают от 128 до 288 ядер на сокет. В двухсокетных системах это 400+ потоков. Для аналитических СУБД это одновременно шанс и кошмар. Теоретически мы получаем чудовищную параллельность, но на практике всё упирается в старые добрые законы компьютерной архитектуры: блокировки, NUMA, пропускная способность памяти и кэш-когерентность.
Недавно инженеры Intel совместно с ClickHouse показали, что даже на 240–288 потоках база может масштабироваться почти линейно, если грамотно убрать узкие места. Результаты впечатляют: ускорение отдельных запросов до 🔟×, средний прирост по ClickBench — 2–10 %.
🔑 Главные узкие места при сотнях ядер
- 🧵 Конкуренция за блокировки — Amdahl’s Law становится беспощадным: даже 1 % сериализации убивает масштабируемость.
- 🧮 Кэш-когерентность — «скачущие» cache line между ядрами отнимают сотни миллионов тактов.
- 💾 Пропускная способность памяти — каждое ядро получает всё меньшую долю полосы.
- ⏱️ Синхронизация потоков — затраты растут сверхлинейно.
- 🗺️ NUMA — задержка доступа к «чужой» памяти ломает равномерность нагрузки.
🛠️ Что оптимизировали
- 🔓 Lock contention: кэш условий запросов перевели с эксклюзивных мьютексов на комбинацию атомиков и shared/exclusive блокировок (PR #80247). CPU-время на spin_lock упало с 76 % до 1 %.
- ⏲️ Thread-local timers: глобальный timer_id вынесли в thread_local, убрав глобальные синхронизации (PR #48778).
- 🧠 Память и jemalloc: настройка lg_extent_max_active_fit с 6 → 8 позволила эффективнее переиспользовать память в двухуровневых hash-таблицах, сократив page fault’ы на 71 % (PR #80245).
- 🧩 Алгебра переписывания AST: SUM(x+1) заменили на SUM(x)+COUNT(x), избавившись от 90 временных колонок в одном запросе. Ускорение — до 11.5× (PR #57853).
- 🔄 Параллельные слияния hash-таблиц: убрали сериализацию при конвертации single→two level, добившись 264 % ускорения в Q5 (PR #50748).
- 💡 SIMD-оптимизация строк: поиск LIKE '%google%' теперь использует фильтрацию по первым двум символам, снижая false positives и ускоряя Q20 на 35 % (PR #46289).
- 📏 False sharing: счётчики ProfileEvents разнесли по cache line, устранив «ложное разделение». В Q3 это дало +27 % (PR #82697).
📈 Почему это важно
Для меня ключевой вывод здесь — масштабируемость больше не достигается простым добавлением потоков. При сотнях ядер решают детали: от выбора структуры памяти до расположения атомика в кэше.
Intel и ClickHouse показали:
- 🏗️ правильная архитектура блокировок важнее, чем «ещё тредов»;
- 🧮 простые алгебраические переписывания запросов дают больше, чем micro-оптимизации;
- 🔬 без тонкой настройки аллокаторов и выравнивания структур железо уровня 288 ядер превращается в «тормозной многопроцессорник».
🤔 Моё мнение
То, что мы видим — это предвестие новой эпохи баз данных. Когда-то оптимизация делалась под «1 ядро, максимум 2». Потом — под десятки. Сегодня — под сотни. Завтра — под тысячи.
ClickHouse здесь фактически становится полигонами для будущего HPC и Big Data, где узкие места — не в SQL-синтаксисе, а в механике процессора и памяти.
И самое интересное: многие паттерны (атомики вместо мьютексов, выравнивание структур, AST-переписывания) применимы и за пределами ClickHouse. Это урок для всех, кто пишет высоконагруженные системы.
🔗 Источник: Optimizing ClickHouse for Intel's ultra-high core count processors