не палите =)

а если уменьшить объемы строк в одной итерации мерджа - память будет меньше жратся?

да нет, при инсерте на каждую колонку выделяется 2 буфера по мегабайту, 1000 колонок = 2ГБ буферов

Спасибо. И объем буфера не параметризован?

то есть kafka engine и MV находятся только в одной базе и если капут этой базе, то надо идти на другой сервер и создавать kafka engine и MV, верно?

Тут логика должна быть следующая: нормальный кластер должен состоять из шардов и реплик. На один шард один Kafka engine + mv.
Если у тебя кластер из 4-х машин где сетап 2+2 (2 шарда и у каждого есть реплика), то ke+mv надо 2 штуки, по одной на шард.
Главное в рамках одного шарда не делать больше 1 ke+mv, тк реплики друг в друга не должны реплицировать данные. В одну пишешь, и она реплицируется

ну пока охота сделать все проще и обойтись без Distributed MergeTree, то есть один шард с тремя репликами, так как проект еще не запустили, и нагрузка не будет космической, главное сделать более надежной

<yandex>
    <remote_servers>
        <replcluster>
            <shard>
                <replica>
                    <host>chi-clickhouse-production-replcluster-0-0</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>chi-clickhouse-production-replcluster-0-1</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>chi-clickhouse-production-replcluster-0-2</host>
                    <port>9000</port>
                </replica>
            </shard>
        </replcluster>
    </remote_servers>
</yandex>

## ТОЖЕ самое но через Distributed t2d 
set distributed_product_mode = 'local'
select t1d.*, t2d.* from t1d t1d left join t2d as t2d using A

Это будет работать если две t2d. и t1d. Distributed таблицы которые смотрят на 2 MergeTree таблицы на двух серверах?

global join как работает и что это?

Подскажите : имеется nginx+django+chproxy+clickhouse. Джанго отправляется запрос в кликхаус через chproxy. В кликхаусе дистрибьютед таблица, которая обращается к нескольким серверам . В последнее время , при выполнении запроса больше 5 мин стало выдавать ошибку 499 (client closed request). Очень напрягает 300 секунд- похоже на какое-то дефаулт значение . Параметры receive_timeout и send_timeout, tcp_keep_alive в users.xmp поставил значительно больше , в system.settings эти значения вижу . В chproxy параметры явно больше 300с отвечающие за таймаут. Причем запрос напрямую, через кхклиент - отрабатывает как надо . Что я ещё мог забыть в конфиге кликхауса?

https://t.me/clickhouse_ru/168095 вот же.

не понял вопроса

он ошибку выкидывает ищет distributed таблицу на одном из его шардов

Кеши используете?

в схеме default у меня 2 distributed таблицы каждая из которых смотрит на 2 сервера. При выполнении join двух distributed таблиц он выкидывает ошибку что не может найти distributed таблицу на одном из его серверов

Добрый день. У кого нибудь есть опыт переноса данных из Influxdb в CH?
Какая структура данный на стороне CH наиболее подходящая? Главный вопрос как лучше хранить набор тегов (key:value набор тегов у метрик зарание неизвестен).
Сейчас мы выбираем из нескольких вариантов
1. Использовать одну таблицу и динамически добавлять новые колонки на каждый новый тег. Как CH себя ведет при частом обновлении таблиц? Бедет ли такой вариант работат? Есть риск что получиться таблица с очень большим набором колонок.
2. Использовать две таблицы одну для метрик и одно для тегов как предложено здесь (https://groups.google.com/forum/#!searchin/clickhouse//clickhouse/pyy0OW12JKM/hlfvz-CVAQAJ)
     1 table have 3 columns
       key Int32,
       timestamp DateTime
       value Float64) order by (key,  timestamp)
     2 table have 2 columns: key - tag
     
 Не очень понятно как заполнять вторую таблицу: key - tag
       Видимо придется создавать отдельный кеш поверх это палицы на запись

 3. Просто поесть все теги в Array или Json

Всем привет. подскажите есть ли механизмы или инструменты для создания инкрементальных бекапов?

Коллеги, напомните, какая схема распределения узлов Zookeeper применяется для решений растянутых на 2 ЦОД.
С учетом кворума и возможного Disaster

вроде про Ya проскакивала подобная информация

Да , в chproxy