ClickHouse/docs/ru/faq/general/why-clickhouse-is-so-fast.md

---
slug: /ru/faq/general/why-clickhouse-is-so-fast
title: Почему ClickHouse так быстро работает?
sidebar_position: 8
---

#  Почему ClickHouse так быстро работает? {#why-clickhouse-is-so-fast}

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

Сначала ClickHouse создавался как прототип, который должен был отлично справляться с одной единственной задачей — отбирать и агрегировать данные с максимальной скоростью. Это необходимо, чтобы создать обычный аналитический отчет, и именно это делает стандартный запрос [GROUP BY](../../sql-reference/statements/select/group-by.md). Для решения такой задачи команда разработки ClickHouse приняла несколько архитектурных решений:

Столбцовое хранение данных
:   Исходные данные часто содержат сотни или даже тысячи столбцов, в то время как для конкретного отчета нужны только несколько из них. Система не должна читать ненужные столбцы, поскольку операции чтения данных с диска — самые дорогостоящие.

Индексы
:   ClickHouse хранит структуры данных в оперативной памяти, что позволяет считывать не только нужные столбцы, но и нужные диапазоны строк для этих столбцов.

Сжатие данных
:   Различные способы хранения смежных значений в столбце позволяют достигать более высокой степени сжатия данных (по сравнению с обычными строковыми СУБД), т.к. в смежных строках значения часто бывают одинаковыми или близкими. В дополнение к универсальному сжатию ClickHouse поддерживает [специализированные кодеки](../../sql-reference/statements/create/table.md#create-query-specialized-codecs), которые позволяют еще больше уменьшить объемы хранимых данных.

Векторные запросы
:   ClickHouse не только хранит, но и обрабатывает данные в столбцах. Это приводит к лучшей утилизации кеша процессора и позволяет использовать инструкции [SIMD](https://en.wikipedia.org/wiki/SIMD).

Масштабируемость
:   ClickHouse может задействовать все доступные мощности процессоров и объемы дисков, чтобы выполнить даже одиночный запрос. Не только на отдельном сервере, но и в целом кластере.

Похожие техники используют и многие другие СУБД. **Внимание к мельчайшим деталям** — вот что на самом деле выделяет ClickHouse. Большинство языков программирования поддерживают большинство распространенных алгоритмов и структур данных, но как правило, они бывают слишком универсальными, чтобы быть по-настоящему эффективными. Мы рассматриваем каждую задачу как тонкий инструмент со множеством настроек, вместо того чтобы просто взять какую-то случайную реализацию. Например, если вам нужна хеш-таблица, вот несколько ключевых вопросов, которые нужно продумать:

-   Какую хеш-функцию выбрать?
-   Каким способом разрешать коллизии: [открытая адресация](https://en.wikipedia.org/wiki/Open_addressing) или [метод цепочек](https://en.wikipedia.org/wiki/Hash_table#Separate_chaining)?
-   Как хранить данные в памяти: ключи и значения в одном массиве или в отдельных? Будут ли там храниться маленькие или большие значения?
-   Фактор заполнения: когда и как менять размер таблицы? Как перемещать значения при изменении размера?
-   Будут ли значения удаляться и если да, то какой алгоритм сработает лучше?
-   Понадобится ли быстрое зондирование с использованием битовых масок, встроенное хранение строковых ключей, поддержка неперемещаемых значений, предварительная выборка и пакетная обработка?

Хеш-таблица — ключевая структура данных для реализации `GROUP BY`, и ClickHouse автоматически выбирает одну из [более 30 вариаций](https://github.com/ClickHouse/ClickHouse/blob/master/src/Interpreters/Aggregator.h) для каждого специфического запроса.

Для алгоритмов сортировки, например, следует продумать следующие вопросы:

-   Что будет сортироваться: массив чисел, кортежей, строк или структур?
-   Доступны ли все данные в оперативной памяти?
-   Нужна ли стабильная сортировка?
-   Нужна ли полная сортировка? Может быть, будет достаточно частичной или выборочной сортировки?
-   Как сравнивать данные?
-   Не являются ли данные частично отсортированными?

Алгоритмы, основанные на характеристиках рабочих данных, обычно дают лучшие результаты, чем их более универсальные аналоги. Если заранее неизвестно, с какими данными придется работать, ClickHouse будет в процессе выполнения пробовать различные реализации и в итоге выберет оптимальный вариант. Например, рекомендуем прочитать [статью о том, как в ClickHouse реализуется распаковка LZ4](https://habr.com/en/company/yandex/blog/457612/).

Ну и последнее, но тем не менее важное условие: команда ClickHouse постоянно отслеживает в интернете сообщения пользователей о найденных ими удачных реализациях, алгоритмах или структурах данных, анализирует и пробует новые идеи. Иногда в этом потоке сообщений попадаются действительно ценные предложения.

:::info "Советы о том, как создать собственную высокопроизводительную систему"


    -   При проектировании системы обращайте внимание на мельчайшие детали реализации.
    -   Учитывайте возможности аппаратного обеспечения.
    -   Выбирайте структуры и представления данных исходя из требований конкретной задачи.
    -   Для особых случаев разрабатывайте специализированные решения.
    -   Пробуйте новые алгоритмы, о которых вы вчера прочитали в интернете. Ищите возможности для совершенствования.
    -   Выбирайте алгоритмы динамически, в процессе выполнения, на основе статистики.
    -   Ориентируйтесь на показатели, собранные при работе с реальными данными.
    -   Проверяйте производительность в процессе CI.
    -   Измеряйте и анализируйте всё, что только возможно.
:::