а если мне нужен ReplicatedSummingMergeTree ?

а только для одной таблицы можно сделать? или подскажите вариант какой имеющийся id сопоставить с текущей таблицей

Добрый день, коллеги!
Есть 2 проблемы с engine kafka & materialized view
По порядку.
В топик kafka пишется массив json объектов, eg
[{"TS":288676,"VF":23.34,"VS":null},{"TS":288236,"VF":23.31,"VS":null}]
Делаем
CREATE TABLE queue
(
   TS Int64
  , VF Nullable(Float64)
  , VS Nullable(String)
)
ENGINE = Kafka
SETTINGS kafka_broker_list = '192.168.XX.XX:9092',
kafka_topic_list = 'topicQueueTest',
kafka_group_name = 'group1',
kafka_format = 'JSONEachRow';

В результате получаем ошибку вида "db::exception: cannot parse input: expected ']' before:" при попытке вычитки из очереди.

Делаем
CREATE TABLE queue
(
   value String
)
ENGINE = Kafka
SETTINGS kafka_broker_list = '192.168.XX.XX:9092',
kafka_topic_list = 'topicQueueTest',
kafka_group_name = 'group1',
kafka_format = 'LineAsString';

При вычитке из очереди видим в value (из примера сверху)
[{"TS":288676,"VF":23.34,"VS":null},{"TS":288236,"VF":23.31,"VS":null}
То есть последний символ обрезается. Это как то неприятно. Видимо engine ожидает в конце значения "\n" и превентивно его обрезает?

я не уверен, что проблема в этом, но в если схема определяет объект, а в кафку пишется массив, то нужно сделать так, чтобы в кафку писались объекты.

Схемы нет в кафке, просто пишется строка - массив json объектов

а если

BETWEEN 24*3600 PRECEDING

Привет!
Есть ли какие-то приемы которые позволят поддерживать базу в которой исторические данные часто меняются. Или кх совсем не для этого?

CollapsingMergeTree

Всем привет. Подскажите пожалуйста. Есть словарь с внешним источником (вьюха в постгресе).
Во вьюхе есть столбец строковый с таким видом данных:

PPVD HA Собака Аллергия 2х3кг / Royal Canin Diets д/собак HA пачка 2 кг

Настроил словарь, тип поля String, на выходе в КХ дает:

PPVD HA Собака Аллергия 2х3кг / Royal Canin Diets д/собак HA пачка 2 к�

Кодировку не трогал. Как пофиксить последний символ?

Привет! Столкнулся с очень странным поведением кликхауса на версии 20.8.2.3, в какой-то момент по неизвестным причинам кликхаус постоянно начал занимать в фоне половину ресурсов CPU. Оказалось дело в непрекращающихся фоновых мержах для материальной вьюхи. Пробовал делать копию базы и запускал ее вообще без нагрузки (вообще без вставок в БД), также обновил до 21.2.3.15 - ничего не помогло. Постоянные мержи выглядят очень странно, даже в отсутствии вставок в таблицы, мерж происходит будто бы по кругу, одни и те же части мержатся снова и снова, при этом проверка целостности таблицы говорит, что все ок.
Подскажите, пожалуйста, что может в принципе триггерить мерж в кликхаусе? Что может триггерить мерж именно для вьюх в отсутствии вставок в БД вовсе?
Если нужно, параметры материальной вьюхи:

ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(date)
SETTINGS index_granularity = 8192

возможно collations разные внутри clickhouse и внутри postgres
дума что это повод для issue на github
не могли бы вы сделать минимально воспроизводимый пример?

Тимлид разобрался, дело в баге в ODBC драйвере, решение сменить тип поля во вьюхе с varchar на text.

о как =) а что за баг в ODBC ? есть ссылка?

недавно кстати выкатили native postgresql словари

вьюха это такая же таблица
system.merges
system.part_log
system.mutations
смотрите