mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-15 19:02:04 +00:00
63 lines
9.7 KiB
Markdown
63 lines
9.7 KiB
Markdown
---
|
||
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.
|
||
- Измеряйте и анализируйте всё, что только возможно.
|
||
:::
|