thevar1able/ClickHouse
1
0
Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2024-09-21 09:10:48 +00:00
Code Issues Packages Projects Releases Wiki Activity
64ca3e140a
ClickHouse/docs/ru/faq/use-cases/key-value.md
olgarev 134eaa55e5
DOCSUP-6258: FAQ edit and translate (#21109) 
Co-authored-by: ana-uvarova <ana-uvarova@yandex-team.ru>
Co-authored-by: AnaUvarova <64017504+AnaUvarova@users.noreply.github.com>
Co-authored-by: vdimir <vdimir@yandex-team.ru>
Co-authored-by: Olga Revyakina <revolg@yandex-team.ru>
Co-authored-by: Anna <42538400+adevyatova@users.noreply.github.com>
2021-03-04 10:50:14 +03:00

4.8 KiB
Raw Blame History

title toc_hidden toc_priority
Можно ли использовать ClickHouse для хранения данных вида "ключ-значение"? true 101

Можно ли использовать ClickHouse для хранения данных вида "ключ-значение"?

Если отвечать коротко, то "нет". Операции над данными вида "ключ-значение" занимают одну из верхних позиций в списке ситуаций, когда категорически не стоит{.text-danger} использовать ClickHouse. Это OLAP СУБД, в то время как есть много специализированных СУБД для данных вида "ключ-значение".

Тем не менее, в некоторых ситуациях имеет смысл использовать ClickHouse для запросов над данными вида "ключ-значение". Чаще всего это относится к системам с относительно невысокой нагрузкой, в которых основной объем операций относится к аналитической обработке данных и отлично подходит для ClickHouse. Однако в них есть некий второстепенный процесс, в котором нужно обрабатывать данные вида "ключ-значение", при этом процесс не требует слишком высокой производительности и не имеет строгих ограничений по задержкам выполнения запросов. Если у вас нет ограничений по бюджету, вы можете использовать для таких операций вспомогательную базу данных "ключ-значение", но это увеличит расходы на обслуживание еще одной СУБД (мониторинг, бэкапы и т.д.).

Если вы все же решите не следовать рекомендациям и использовать ClickHouse для работы с данными вида "ключ-значение", вот несколько советов:

  • Главная причина, по которой точечный запрос в ClickHouse становится ресурсозатратным — это разреженный индекс для первичного ключа в таблице семейства MergeTree. Этот индекс не может обращаться напрямую к каждой строке данных, вместо этого он обращается к каждой N-ой строке, а затем сканирует соседние строки вплоть до указанной, обрабатывая по пути лишние данные. При обработке данных вида "ключ-значение" может быть полезно уменьшить значение N при помощи настройки index_granularity.

  • ClickHouse хранит столбцы в отдельных файлах, поэтому чтобы собрать одну полную строку, ему приходится обрабатывать все эти файлы. Их количество растет линейно в зависимости от количества столбцов, поэтому при обработке данных вида "ключ-значение" стоит избегать использования множества столбцов и поместить все нужные данные в один столбец с типом String в формате JSON, Protobuf или другом подходящем формате.

  • Подумайте об использовании табличного движка Join вместо обычных таблиц MergeTree и функции joinGet для получения данных. В этом случае производительность выполнения запросов может быть выше, но могут появиться проблемы с надежностью и удобством. Пример такого использования описан здесь.