У нас настроен кластер кликхауса из двух шардов с репликацией на каждом. Сегодня перестал работать одна из реплик на одном из шардов и весь кластер перестал обрабатывать запросы. Неужели репликация в кликхаусе не защищает от подобных сбоев?

У нас настроен кластер кликхауса из двух шардов с репликацией на каждом. Сегодня перестал работать одна из реплик на одном из шардов и весь кластер перестал обрабатывать запросы. Неужели репликация в кликхаусе не защищает от подобных сбоев?

Вообще странная история. У меня тоже кластер, но из 4-х шардов и тоже с репликацией. Были случаи, когда реплики отваливались то там, то сям, но кластер в целом не сбоил и выдавал актуальные данные. А ZK ничего не плюет в логи ошибок? Может быть есть какая то информация из error лога CH?

что такое шаред

Коллеги, подскажите пожалуйста в запросе вида select ... from table ORDER BY date результат будет ортсортирован стабильной сортировкой или нет? И если нет, то есть ли способ отсортировать стабильно?

Таблица на ENGINE = ReplicatedMergeTree

?

День добрый. Столкнулись со "странной" проблемой. Имеем 3 шарда по 2 реплики в каждом. ZK настроен и ошибок никаких не выдаёт. Проблема: Переливаем данные из одной таблицы в другую. INSERT INTO <DESTINATION> (... перечисление столбцов ...) SELECT ... перечисление столбцов ... FROM <SOURE>; При internal_replication == false на шардах получаем "лишние" строки. В целевой таблице получаем больше строк чем в источнике. В логах на 1 из нод <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 235, e.displayText() = DB::Exception: Part 20150817_70_70_0 (state Committed) already exists При internal_replication == true на шардах строки теряются. В целевой таблице строк меньше чем в источнике. И ругань can't find part from own log Данных - 8 миллиардов строк. Скорость вставки около 800 тысяч строк в секунду Вставляем в Distributed таблицу В ZK ошибок нет

Коллеги, подскажите пожалуйста в запросе вида select ... from table ORDER BY date результат будет ортсортирован стабильной сортировкой или нет? И если нет, то есть ли способ отсортировать стабильно?

Попробовал сейчас симулировать недетерменированную подачу данных перед сортировкой с набором одинаковых ключей сортировки и результат нифига неустойчивый

Т.е. при наличии одинаковых ключей сортировки, результат сортировки внутри ключа всегда разный

Т.е. я сначала беру данные из исходной таблицы и делаю order by rand() поверх делаю order by orderKey зная, что у меня несколько записей на один orderKey имеются

И каждый раз результат сортировки по orderKey разный

Коллеги, всем привет! а как можно потюнить скорость реплики? на уровне квот пользователя, увеличение памяти jvm? я переключил движки mergetree -> replicatedmergetree и 4 шарда, в каждом из которых по 30 млрд строк как-то медленно разливаются...

Я думаю, что бы добиться устойчивости есть смысл добавить дополнительные колонки для сортировки

Я думаю, что бы добиться устойчивости есть смысл добавить дополнительные колонки для сортировки

да, будем думать, что еще такого бы добавить, спасибо :)

недетерминированный запрос (отсутствие полного порядка) + недетерминированное исполнение (несколько машин/несколько потоков) = разные ответы.

недетерминированный запрос (отсутствие полного порядка) + недетерминированное исполнение (несколько машин/несколько потоков) = разные ответы.

Просто сортировка в любом случае ожидает пока все данные не приедут и тут вопрос о устойчивой сортировке, а не порядке в котором данные поступают :) Просто если делать обычный селект из таблицы в том порядке в котором данные идут и сортировать по ключу для которого несколько строк имеются, то покажется, что сортировка устойчива, а если предварительно данные перемешать и потом отсортировать по ключу на который несколько строк, то видно, что сортировка нифига не устойчива

Просто сортировка в любом случае ожидает пока все данные не приедут и тут вопрос о устойчивой сортировке, а не порядке в котором данные поступают :) Просто если делать обычный селект из таблицы в том порядке в котором данные идут и сортировать по ключу для которого несколько строк имеются, то покажется, что сортировка устойчива, а если предварительно данные перемешать и потом отсортировать по ключу на который несколько строк, то видно, что сортировка нифига не устойчива

А как по другому ?

Просто сортировка в любом случае ожидает пока все данные не приедут и тут вопрос о устойчивой сортировке, а не порядке в котором данные поступают :) Просто если делать обычный селект из таблицы в том порядке в котором данные идут и сортировать по ключу для которого несколько строк имеются, то покажется, что сортировка устойчива, а если предварительно данные перемешать и потом отсортировать по ключу на который несколько строк, то видно, что сортировка нифига не устойчива

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

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

Особенно в распределенных многопоточных системах. Решения два - считать на дном сервере в одно ядро, либо явно указать ORDER BY

Коллеги, а напомните - нет ли функции округления даты_времени до 15 минутки? А то до 5 минут есть а хотелось бы до 15 :)

нет, но можно подправить FunctionsDateTime и https://github.com/yandex/ClickHouse/blob/master/libs/libcommon/include/common/DateLUTImpl.h#L281

Коллеги, а напомните - нет ли функции округления даты_времени до 15 минутки? А то до 5 минут есть а хотелось бы до 15 :)

можно так сделать toDateTime(intDiv(toUnixTimestamp(time), 60*15)*60*15)

можно так сделать toDateTime(intDiv(toUnixTimestamp(time), 60*15)*60*15)

Менее красиво чем нативной функцией но спасибо!

зато так можно до каких душа пожелает интервалов округлять)

Доброго дня, кто-то сталкивался с проблемой вставки Array(String) в Nested типах? Движок MergeTree

<Error> void DB::BackgroundProcessingPool::threadFunction(): Code: 246, e.displayText() = DB::Exception: bad size of marks file `/data/clickhouse//data/db_1/table_1/20171214_20171214_353026_353090_1/column_1.size1.mrk':0, must be: 16: (while reading column column_1.field_1): (while reading from part /data/clickhouse//data/db_1/table_1/20171214_20171214_353026_353090_1/ from mark 0 with max_rows_to_read = 8192), e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x3221296] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0x144a02f] 2. clickhouse-server() [0x36cfed0] 3. clickhouse-server(DB::MergeTreeReader::Stream::loadMarks()+0x9ab) [0x36d0abb] 4. clickhouse-server(DB::MergeTreeReader::Stream::seekToMark(unsigned long)+0x75) [0x36d28f5] 5. clickhouse-server(DB::MergeTreeReader::readData(std::string const&, DB::IDataType const&, DB::IColumn&, unsigned long, bool, unsigned long, unsigned long, bool)+0x73f) [0x36d338f] 6. clickhouse-server(DB::MergeTreeReader::readData(std::string const&, DB::IDataType const&, DB::IColumn&, unsigned long, bool, unsigned long, unsigned long, bool)+0x3cb) [0x36d301b] 7. clickhouse-server(DB::MergeTreeReader::readRows(unsigned long, bool, unsigned long, DB::Block&)+0x32e) [0x36d3ade] 8. clickhouse-server(DB::MergeTreeRangeReader::read(DB::Block&, unsigned long)+0x48) [0x36ce368] 9. clickhouse-server(DB::MergeTreeBaseBlockInputStream::readFromPart()+0x2870) [0x36c5

column_1 Nested( field_1 Array(String), ... )

Это получается Array(Array(String)). Кажется были проблемы с хранением многомерных массивов.

да, так. Это будет исправлено?

Кажется, это by design пока что

нам очень нужно)

да, так. Это будет исправлено?

Алексей на конференации говорил, что вроде как скоро станет возможным хранение даже вложенных nested структур ну и многомерных массивов тоже

А кто подскажет, чем отличается поведение КХ при internal_replication вкл и выкл для шарда?

нам очень нужно)

Ну вот Вы пишите на плюсах? Или может кто-то из знакомых пишет? Ну вот и сделайте. ©Миловидов

А кто подскажет, чем отличается поведение КХ при internal_replication вкл и выкл для шарда?

Цитирую доку. У каждого шарда в конфигурационном файле может быть указан параметр internal_replication. Если он выставлен в true, то для записи будет выбираться первая живая реплика и данные будут писаться на неё. Этот вариант следует использовать, если Distributed таблица «смотрит» на реплицируемые таблицы. То есть, если таблица, в которую будут записаны данные, будет сама заниматься их репликацией. Если он выставлен в false (по умолчанию), то данные будут записываться на все реплики. По сути, это означает, что Distributed таблица занимается репликацией данных самостоятельно. Это хуже, чем использование реплицируемых таблиц, так как не контролируется консистентность реплик, и они со временем будут содержать немного разные данные.

Цитирую доку. У каждого шарда в конфигурационном файле может быть указан параметр internal_replication. Если он выставлен в true, то для записи будет выбираться первая живая реплика и данные будут писаться на неё. Этот вариант следует использовать, если Distributed таблица «смотрит» на реплицируемые таблицы. То есть, если таблица, в которую будут записаны данные, будет сама заниматься их репликацией. Если он выставлен в false (по умолчанию), то данные будут записываться на все реплики. По сути, это означает, что Distributed таблица занимается репликацией данных самостоятельно. Это хуже, чем использование реплицируемых таблиц, так как не контролируется консистентность реплик, и они со временем будут содержать немного разные данные.

Благодарю. Просмотрел этот момент в доке

Ну вот Вы пишите на плюсах? Или может кто-то из знакомых пишет? Ну вот и сделайте. ©Миловидов

спасибо)

А при инсерте, чтобы сконвертировать значение в числовой код из внешнего словаря, надо руками до запроса это делать самому?

да, так. Это будет исправлено?

Кажется исправление уже есть: https://github.com/yandex/ClickHouse/pull/1314#issuecomment-336252673 Можете собрать тестовый релиз и протестировать (такая помощь - тоже помощь, не все обязаны быть С++ программистами).

Тут тесты, можно на них ориентироваться: https://github.com/yandex/ClickHouse/pull/1314/files#diff-cbdf97a12d698329a65ec0f2bf8c2ed0

А при инсерте, чтобы сконвертировать значение в числовой код из внешнего словаря, надо руками до запроса это делать самому?

Ну как вариант - можно ещё сделать обратный словарь из строки в инт, получится ещё более причудливый синтакс типа id UInt64 DEFAULT dictGetUInt64('dict','id',tuple(toString(dicted_column)));

ну и словарь со строковым ключом - layout обязательно должен должен быть complex_key_hashed или complex_key_cache (с одним строковым элементом в качестве ключа).

Кажется исправление уже есть: https://github.com/yandex/ClickHouse/pull/1314#issuecomment-336252673 Можете собрать тестовый релиз и протестировать (такая помощь - тоже помощь, не все обязаны быть С++ программистами).

Сейчас это на уровне "должно работать", но не факт, что не будет проблем. Можете быть первым, кто протестирует это у себя :)

как победить? делаю простой select c группировкой DB::Exception: Allocator: Cannot mremap memory chunk from 2.00 GiB to 4.00 GiB., errno: 14, strerror: Bad address.

как победить? делаю простой select c группировкой DB::Exception: Allocator: Cannot mremap memory chunk from 2.00 GiB to 4.00 GiB., errno: 14, strerror: Bad address.

Это на Ubuntu c офф. билдом?

нет, centos клиент и сервер 1.1.54318.

Самостоятельно собирали или с Altinity?

altinity

Сейчас это на уровне "должно работать", но не факт, что не будет проблем. Можете быть первым, кто протестирует это у себя :)

а это разве не вошло в версию 1.1.54318? у нас на этой версии не воспроизводится оригинальная бага из https://github.com/yandex/ClickHouse/issues/1282

Да, вошло. Но тогда я поправил запись nullable массивов, а многомерные почти что сами заработали.

Dct

Всем привет, никак не могу проинициализировать конфиг clickhouse_remote_servers.xml

В корне /etc/clickhouse-server CH его не видит: Include not found: clickhouse_remote_servers

Как ткнуть CH в этот конфиг?

Всем привет. Подскажите плиз люди с опытом: Я правильно понимаю что вставля 10 строк каждые 2 секунды в таблицу MergeTree - для clickhouse все ОК или же для сохранения производительности надо вставлять 1000 строк за один раз?

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

Всем привет, никак не могу проинициализировать конфиг clickhouse_remote_servers.xml

Как работают подстановки, написано здесь: https://clickhouse.yandex/docs/ru/single/index.html#document-operations/configuration_files если кратко, параметр include_from - имя файла с подстановками. там должен быть <clickhouse_remote_servers>

Всем привет. Подскажите плиз люди с опытом: Я правильно понимаю что вставля 10 строк каждые 2 секунды в таблицу MergeTree - для clickhouse все ОК или же для сохранения производительности надо вставлять 1000 строк за один раз?

Да, нормально.

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

навскидку, должно сработать. MatView пишутся данные при вставке, и пересоздание колонки не должно влиять.

но я бы проверил сначала на тестовых табличках :)

ахах блин))

как победить? делаю простой select c группировкой DB::Exception: Allocator: Cannot mremap memory chunk from 2.00 GiB to 4.00 GiB., errno: 14, strerror: Bad address.

Если в остальном система работает, память есть и т.п. - то вроде как не должно такого происходить. Попробуйте создать небольшой пример с таблицой и данными и селект на котором проблема воспроизводится и создать issue на гитхабе.

Если в остальном система работает, память есть и т.п. - то вроде как не должно такого происходить. Попробуйте создать небольшой пример с таблицой и данными и селект на котором проблема воспроизводится и создать issue на гитхабе.

врятли воспроизведется на маленьком семпле, там была просто большая выборка за 2 года, пришлось поделить на 2 запроса

врятли воспроизведется на маленьком семпле, там была просто большая выборка за 2 года, пришлось поделить на 2 запроса

Забыл важнейший вопрос: а вы пробовали выключить и включить? :)

но я бы проверил сначала на тестовых табличках :)

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

добрый день подскажите пожалуйста с чем может быть связана такая ошибка? <Error> report.Distributed.DirectoryMonitor: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (ip:9000), e.what() = DB::NetException

врятли воспроизведется на маленьком семпле, там была просто большая выборка за 2 года, пришлось поделить на 2 запроса

Если серьезнее - то по идее ошибка вроде как не должна такая появляться. Так как бы неправильный указатель для ремапа передали. Не исключено что какой-то баг. Если на маленьких данных никак - то можно просто стектрейс (должен быть в логах), селект на котором посыпалось и структура таблицы.

Если серьезнее - то по идее ошибка вроде как не должна такая появляться. Так как бы неправильный указатель для ремапа передали. Не исключено что какой-то баг. Если на маленьких данных никак - то можно просто стектрейс (должен быть в логах), селект на котором посыпалось и структура таблицы.

Постраюсь сегодня выложить

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

А может просто почистить один столбец в отдельно взятой партиции? ALTER TABLE x CLEAR COLUMN y IN PARTITION '201710'

CLEAR COLUMN ?

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

в следующий раз буду знать

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

Не должна.

Разве что будете чистить партицию в которую прямо сейчас идет запись, тогда не уверен что случится раньше - матвьюха прочитает данные или CLEAR COLUMN их удалит.

нет, такого счастья не надо, лучше запись останавливать на таких операциях =)

добрый день подскажите пожалуйста с чем может быть связана такая ошибка? <Error> report.Distributed.DirectoryMonitor: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (ip:9000), e.what() = DB::NetException

Может быть связана с тем, что нельзя подключиться к ip:9000. Получается ли запустить клиент как clickhouse client —host=ip ?

Может быть связана с тем, что нельзя подключиться к ip:9000. Получается ли запустить клиент как clickhouse client —host=ip ?

да получалось подключится обновили КХ на ноде на которой происходила ошибка - пока вроде исчезла

в логах на другой машине есть какие-нибудь ошибки?

DirectoryMonitor - поток, который посылает данные на другие ноды при записи в Distributed. Если имеем Broken pipe, то исключение могло случиться на противоположенном конце.

Подскажите, может ли словарь иметь один из аттрибутов типа Array или Set?

На данный момент не реализовано. Разве что хранить сторкой.

На данный момент не реализовано. Разве что хранить сторкой.

Ага, спасибо. Я тут попытался методом тыка, при указании в настройках аттрибута Array, сервер сегфолтится. Нужно ли на это завести баг на гитхабе?

да. сегфолты не должны случаться

да. сегфолты не должны случаться

ок, заведу тогда, спасибо.

?

Привет. Подскажите, пожалуйста, по вьюшкам: хочу изменить запрос для MAT VIEW, без изменения типов или количества полей (просто чуть поменяется запрос). Можно ли сделать это вручную, отредактировав sql в /metadata/ ? А если вьюшка - реплицируемая - нужно отключать и редактировать одновременно на всех репликах шарда?

привет! подскажите такое - какой минимальный промежуток времени можно хранить в CH если хочется в базу непрерывно писать. Я так понимаю что минимум получается пару месяцев, так как удалять из базы можно только месяцами. Так ведь?

привет! подскажите такое - какой минимальный промежуток времени можно хранить в CH если хочется в базу непрерывно писать. Я так понимаю что минимум получается пару месяцев, так как удалять из базы можно только месяцами. Так ведь?

С извращениями можно партиционировать по дням вместо месяцев, хоть по секундам. Но это извращения, с ними сложно жить.

Мда, не хотелось бы извращений

почему извращения?

Нормальная фича

Используйте партиционирование как вам будет угодно