ClickHouse не создан для этого варианта использования, и он намеренно говорит об этом на домашней странице своего документа.

Когда НЕ использовать ClickHouse

1. Транзакционные рабочие нагрузки (OLTP)
2. Доступ по принципу «ключ-значение» с высокой частотой запросов
3. Хранилище BLOB-объектов или документов
4. Чрезмерно нормализованные данные

Однако, если количество запросов в секунду низкое, вы все равно можете получить хорошие показатели задержки для точечных запросов. ClickHouse также предоставляет несколько видов словарей, которые лучше использовать в качестве внешнего хранилища ключей и значений. Существует также механизм StorageJoin, который поддерживает функцию joinGet, аналогичную операции HGET в Redis. После этого PR вы можете перезаписать существующие ключи в StorageJoin.

Обновить

PR объединен. Вот отдельный пример.

Сначала заполните таблицу StorageJoin следующим образом:

CREATE TABLE my_fancy_kv_store (s String, x Array(UInt8), k UInt64)
ENGINE = Join(ANY, LEFT, s);

INSERT INTO my_fancy_kv_store VALUES ('abc', [0], 1), ('def', [1, 2], 2);

Затем вы можете использовать его как словарь (ключ-значение):

SELECT joinGet('my_fancy_kv_store', 'x', 'abc');
SELECT joinGet('my_fancy_kv_store', 'k', 'def');

Недавно был добавлен механизм таблиц EmbeddedRocksDB, который может помочь .

Дополнительную информацию можно найти здесь: https://kb.altinity.com/engines/altinity-kb-embeddedrocksdb-and-dictionary

В моих тестах, по сравнению с MergeTree, я вижу, что EmbeddedRocksDB обрабатывает в 10-20 раз больше QPS, что в 10-100 раз выше скорость отклика.

Это может варьироваться в зависимости от варианта использования, но мне этого достаточно, чтобы не искать отдельные установки Redis / RocksDB / DynamoDB (поскольку наличие хранилищ KV внутри CH помогает объединяться между MT и EmbeddedRocksDB, и мне действительно не нужно масштабироваться до пределов Redis / ДДБ)