Наверное, лучше просто не буду использовать replacing merge tree.

Если в replacingmergetree сделать optimize во время вставки большой порции данных, то, кажется, всё ломается. Кто-нибудь сталкивался с таким?

Сталкивался. Пришлось отказаться в пользу MergeTree с партиционированием по дням

Скажите, пожалуйста, какую версию ZooKeeper вы рекомендуете к использованию в продакшне? В русской документации написано "как минимум 3.4.9" В английской - 3.5 or later. И если 3.5, то какую именно? Их есть аж 3 штуки 3.5.1 от 31.08.2015 3.5.2 от 20.07.2016 3.5.3 от 17.04.2017 В документации описан пример из боевого окружения Яндекс.Метрики на 20.05.2017, и там речь о версии 3.5.1. Вы до сих пор используете 3.5.1?

Привет Подскажите, где найти коннектор для PowerBI? Написано что он есть

Привет Подскажите, где найти коннектор для PowerBI? Написано что он есть

Попробуйте вот так: https://www.etlforeveryone.ru/single-post/CHPBIConnector

Да, но это надо для каждого запроса настраивать новое подключение. Не практично. Кастомный коннектор никто не писал?

Он так и должен делать, по мере того как поступают данные он пишет, если для того чтоб отдать данные нужно что-то большое посчитать может упасть, либо тут баг какой-то

https://github.com/yandex/ClickHouse/issues/1817 Завёл тикет на эту проблему

Привет. Не нашел в документации и поэтому подозреваю, что такого функционала нет. Но может есть какой-то более простой способ решить мою проблему? Задача: добавить несколько столбцов к движку SummingMergeTree, конечно они должны войти в первичный ключ. ALTER позволяет добавить, тут проблем нет, но вот переконфигурировать ENGINE - такого функционала я не вижу. Поэтому мои данные будут постоянно перетираться движком. Есть идеи как решить проблему с минимальными затратами по времени?

Я бы создавал рядом таблицу аналогичную, но с нужными полями + ключом. Плавно перелил все данные из старой таблицы кроме текущего дня в новую. В новом дне остановил запись в старую таблицу. Перелил бы последний день. Запустил запись в новую таблицу.

Похоже, так и придется делать. Только потом переименовать новую табличку с именем старой.

ну и добавляются детали если у вас реплика есть или что-то еще)

Подскажите, пожалуйста, в чём может быть проблема? КликХауз сегфолтится под интенсивной записью. Последние строки в логе от потока, от которого прилетел сегфолт, всё время выглядят так: <Warning> dbName.tableName (StorageReplicatedMergeTree): There was a problem with deleting 18 nodes from ZooKeeper: marshalling error <Debug> dbName.tableName (StorageReplicatedMergeTree): Removed 18 old parts from ZooKeeper. Removing them from filesystem. И всё. Потом другой поток пишет, что от этого потока прилетел Segmentation fault Версия ClickHouse: 1.1.54327 Версия ZooKeeper: 3.4.10

а если создать рядом аналогичную, в старой detach partition, перекинуть данные в новую, и в новой attach partition?

ну по идее структура та же вроде, просто меняется ключ? после attach partition данные схлопнутся по идее с новым ключом, но конечно, это тестировать надо

а нет, добавление столбцов, сорян, такой способ не прокатит

Добрый день. подскажите, пожалуйста, обновились до 54342 и посыпались ошибки

2018.01.24 13:33:03.327459 [ 17 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:

CH тут не уиновен. http://paste.org.ru/?3lhxnq

Подскажите, пожалуйста, в чём может быть проблема? КликХауз сегфолтится под интенсивной записью. Последние строки в логе от потока, от которого прилетел сегфолт, всё время выглядят так: <Warning> dbName.tableName (StorageReplicatedMergeTree): There was a problem with deleting 18 nodes from ZooKeeper: marshalling error <Debug> dbName.tableName (StorageReplicatedMergeTree): Removed 18 old parts from ZooKeeper. Removing them from filesystem. И всё. Потом другой поток пишет, что от этого потока прилетел Segmentation fault Версия ClickHouse: 1.1.54327 Версия ZooKeeper: 3.4.10

а stacktrace можно посмотреть? обычно в логе <Error> BaseDaemon: ########################################

pastebin plz

https://pastebin.com/QgKxsREw

https://github.com/yandex/ClickHouse/issues/1817 Завёл тикет на эту проблему

dictionaries.content_app_version_mapi - это таблица на основе внешнего словаря?

Да

а stacktrace можно посмотреть? обычно в логе <Error> BaseDaemon: ########################################

https://pastebin.com/WHVjyxwx

Да

А обычный select * format Null из нее работает?

https://pastebin.com/WHVjyxwx

память не кончалась в этот момент ?

память не кончалась в этот момент ?

да, близко к нулю подбиралась, поминутный график показывает в 15:02 всего 2.1G Хотя не уверен, что это нужная метрика. Это MemFree из /proc/meminfo Много было в кэше. Процессами использовалось только 60G из 240.

dictGetT('dict_name', 'attr_name', id) получить из словаря dict_name значение атрибута attr_name по ключу id. dict_name и attr_name - константные строки. id должен иметь тип UInt64. Если ключа id нет в словаре - вернуть значение по умолчанию, заданное в описании словаря.

2018.01.24 13:33:03.327459 [ 17 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:

было ровно то же самое при обновлении на 54337, сначала Cannot read all data, потом посыпалось Part ... from own log doesn't exist. пришлось откатываться

я не понимаю что тут написанно.

было ровно то же самое при обновлении на 54337, сначала Cannot read all data, потом посыпалось Part ... from own log doesn't exist. пришлось откатываться

да, тоже решили откатом

кто-то может подсказать подробнее?

почему тип Т и почему при этом "id должен иметь тип UInt64"

посмотрел сейчас в логах - stack trace идентичный по Cannot read all data

почему тип Т и почему при этом "id должен иметь тип UInt64"

словарь - это отображение: ключ -> значение. у обычных словарей ключ типа UInt64, а значение может быть произвольного типа T

а у не обычных? и как из необычных доставать данные?

бывают еще complex key словари и range словари. в первых надо указывать tuple вместо UInt64, во вторых - дополнительный параметр даты

в документации подробнее написано про разнве типы словарей: https://clickhouse.yandex/docs/ru/dicts/external_dicts_dict_layout.html#sposoby-razmesheniya-slovarei-v-pamyati

ну и как указывать tuple?

https://clickhouse.yandex/docs/ru/data_types/tuple.html

что из этой отписки я должен понять?

например, dictGetUInt32('dict', 'value', tuple(1, 'a'))

охренеть. почему 1, 'a' ?

1 — это количесво столбцов или что?

если у вас составной уникальный ключ в источнике, int и string например

ну это зависит от типа ключа

tuple(1, 'a') - tuple из 2-х элементов: число и строка

что зависит от типа ключа? 1 или 'a'?

tuple - это просто массив фиксированного размера кладите туда что хотите

1 и 'a' - это рандомный пример

А мне вот интересно ) Кортеж в кортеже поддерживается? )

да

а почему в заголовке статьи tuple с большой буквы, а тут в примерах — с маленькой? как правильно?

что зависит от типа ключа? 1 или 'a'?

для complex key словарей в структуре указывается, какого типа должен быть составной ключ. например, это может быть число и строка.

если кто удивлен вопросом — то всякие String — регистрозависимые

а почему в заголовке статьи tuple с большой буквы, а тут в примерах — с маленькой? как правильно?

Tuple - название типа , tuple - название функции, которая создает tuple

SELECT toTypeName((1, 'a')) ┌─toTypeName(tuple(1, \'a\'))─┐ │ Tuple(UInt8, String) │ └─────────────────────────────┘

2018.01.24 13:33:03.327459 [ 17 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:

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

нет, проверяли только на 1

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

Всех приветствую! Скажите, пожалуйста, справедливо ли утверждение, что кворумная вставка работает однопоточно в пределах replicated таблицы на шарде?

т.е. что попытка сделать две конкуретные вставки может всё разорвать

Привет Смотрю вариант подключить Табло поверх КХ. Нашел в интеренете следующую информацию, но так как презентация довольно старая, хотел узнать как сейчас обстоятдела с этими пунктами. Кто использует Табло, подскажите, пожалуйста.

т.е. что попытка сделать две конкуретные вставки может всё разорвать

кажется, что такого не должно случаться

кажется, что такого не должно случаться

В смысле, не должно ломать?

аа, речь о другом, не увидел

В смысле, не должно ломать?

да

Подскажите, пожалуйста, если способ вывести одну из Clickhouse нод на техническое обслуживание и потом вернуть через несколько часов, чтобы догнало репликацию, при этом так чтобы это не влияло на стабильность кластера? Под стабильностью в данном случае подразумеваю малое количество или полное отстуствие ошибок на SELECT запросы во время проведения обслуживания и догонки реплики. Вот к этому issue косвенно относится - https://github.com/yandex/ClickHouse/issues/520 Если сравнивать с проведением подобных операций на большом Elasticsearch кластере, то там всё стабильно и безпроблемно проходит.

Подскажите, пожалуйста, если способ вывести одну из Clickhouse нод на техническое обслуживание и потом вернуть через несколько часов, чтобы догнало репликацию, при этом так чтобы это не влияло на стабильность кластера? Под стабильностью в данном случае подразумеваю малое количество или полное отстуствие ошибок на SELECT запросы во время проведения обслуживания и догонки реплики. Вот к этому issue косвенно относится - https://github.com/yandex/ClickHouse/issues/520 Если сравнивать с проведением подобных операций на большом Elasticsearch кластере, то там всё стабильно и безпроблемно проходит.

если используете replicated таблицы то все само должно работать

а не надо ли перед началом работ сделать так, чтобы на нее не приходили запросы? если например, селектить из Distributed-таблицы, а load_balancing настроена на random, то запросы будут попадать на нее, пока она будет догоняться, и будут разные результаты

наверное, в этом случае поможет max_replica_delay_for_distributed_queries: Отключает отстающие реплики при распределенных запросах.

спс за вопрос =)

если используете replicated таблицы то все само должно работать

да, конечно же используем replicated таблицы, но видимо кластер близок к максимуму утилизации.

Добрый день коллеги. Подскажите пожалуйста, есть таблица pages в ней записей 2кк Содержит колонки url | redirect_to_url | url_hash | redirect_to_url_hash Как можно узнать цепочку из 4 а лучше всех редиректов? Делал вот так SELECT url, redirect_to_url FROM pages ALL INNER JOIN ( SELECT redirect_to_url_hash AS url_hash FROM pages ALL INNER JOIN ( SELECT redirect_to_url_hash AS url_hash FROM pages ) USING (url_hash) ) USING (url_hash) LIMIT 10 Запрос висит... приходится убивать.

а не надо ли перед началом работ сделать так, чтобы на нее не приходили запросы? если например, селектить из Distributed-таблицы, а load_balancing настроена на random, то запросы будут попадать на нее, пока она будет догоняться, и будут разные результаты

да, LB настроен на работу с весами, более мощные ноды получают больше запросов, а так в целом рандом. Спасибо за опцию max_replica_delay_for_distrubuted_queries - попробуем.

Скажите, есть ли какие-то подводные камни в MODIFY COLUMN столбца Enum8 в UInt8 ?

@kochetovnicolai подскажите, а при распредленном запросе - если одна из нод выдает таймаут, то и весь распределенный запрос выдает таймаут?

Привет, а никто не скажет, нет ли в КХ каких нибудь механизмов плагинов? Конкретно, что нужно мне - по различным признакам классифицировать эвенты, логика достаточно сложная. Чтобы было что-то вроде INSERT INTO блаблабла url, referrer, classify_external(url,referrer)

300 секунд дефолтное значение для max_replica_delay_for_distributed_queries выглядит разумно, но что-то все равно не сходится.

@kochetovnicolai подскажите, а при распредленном запросе - если одна из нод выдает таймаут, то и весь распределенный запрос выдает таймаут?

должно быть так, но точно не помню, что происходит, если есть другие активные реплики

Скажите, есть ли какие-то подводные камни в MODIFY COLUMN столбца Enum8 в UInt8 ?

По-логике, все должно быть нормально, так как данные (вроде) не поменяются, а только тип.

коллеги, использующие tabbix, подскажите, пожалуйста. можно ли как-нибудь подкрутить в tabix таймауты ответа КХ? вылетает ошибка Timeout exceeded: elapsed 5.009918569 seconds, maximum: 5

Привет, а никто не скажет, нет ли в КХ каких нибудь механизмов плагинов? Конкретно, что нужно мне - по различным признакам классифицировать эвенты, логика достаточно сложная. Чтобы было что-то вроде INSERT INTO блаблабла url, referrer, classify_external(url,referrer)

В данный момент плагинов нет. Разве что добавить свою реализацию в код ClickHouse.

В данный момент плагинов нет. Разве что добавить свою реализацию в код ClickHouse.

или делать это перед инсертом

Подскажите, а можно ли удалить данные из таблицы не удаляя структуру самой таблицы какой-нибудь командой?

Подскажите, а можно ли удалить данные из таблицы не удаляя структуру самой таблицы какой-нибудь командой?

alter table drop partition?

подскажите, возможно ли отменить тяжелый мерж, спровоцированный OPTIMIZE TABLE? Судя по всему, можно удалить запись в очереди в Zookeeper, типа такого /clickhouse/{CLUSTER}/tables/6/{TABLE}/replicas/{NODE}/queue/queue-0002370007