И вообще, что может означать пустой ответ на echo 'mntr' | nc 192.168.110.103 2181 ?

При этом с точки зрения кликхауса зукипер в порядке.

Господа, кто как мониторит живость zookeeper? Ну, кроме доступности порта по сети?

https://blog.serverdensity.com/how-to-monitor-zookeeper/ вот примерно так, снимаем метрики, мониторим ошибки в репликации (селект есть в доке). Если с зк беда, то со всех сторон начинают сыпаться ошибки, что таблицы в read-only

Благодарю... А то после переезда на железный сервер, скрипт на базе echo mntr как-то странно стал себя вести...

Пролистал. Проблема в том, что метрики немного не снимаются в половине запусков. И непонятно, где именно сломалось...

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

Спасибо большое за объяснение. Стольько тонкостей, мое упущение

Благодарю... А то после переезда на железный сервер, скрипт на базе echo mntr как-то странно стал себя вести...

проверьте сетевые настройки у нас было что-то похожее, ответ зукипера по размеру не пролезал

mtu?

вроде да, я детали не помню

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

Проверил настройки, да стоит по умолчанию │ │ max_insert_block_size │ 1048576 │ 0 │ The maximum block size for insertion, if we control the creation of blocks for insertion. Вставки идут пачками по 2018-07-26 06:21:36,165 Inserted 38679 items into store because last flush time was 10002ms ago. This is more than flush interval 10000 2018-07-26 06:21:38,817 Inserted 38660 items into store because last flush time was 10003ms ago. This is more than flush interval 10000 2018-07-26 06:21:39,491 Inserted 38234 items into store because last flush time was 10005ms ago. This is more than flush interval 10000 2018-07-26 06:21:40,428 Inserted 55010 items into store because last flush time was 10001ms ago. This is more than flush interval 10000 Проблема с мержами была только на 1 шарде на одной реплике (там сервер отвалился и потом дого догонял)

Получается размер пачки сильно меньше max_insert_block_size и Вы говорите вставка должна быть атомарная?

Судя по тому что я виду в данных в нашем случае это не так Может еще что-то атомарность могло нарушить и после многих попыток вставки появились дупликаты?

Судя по тому что я виду в данных в нашем случае это не так Может еще что-то атомарность могло нарушить и после многих попыток вставки появились дупликаты?

После многих попыток, если блоки не полностью идентичны или таблица не Replicated*, у вас появятся дубликаты

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

После многих попыток, если блоки не полностью идентичны или таблица не Replicated*, у вас появятся дубликаты

Таблица Replicated. Блоки идентичны. Есть массив А Создается createPreparedStatement потом много раз addBatch (бегаем по массиву А) а затем executeBatch Если упало исключение то все сначала. Новый createPreparedStatement и заново бегаем по тому же А

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

У нас 8 таблиц реплицируемых локальных (4 шарды 2 реплики) 8 распределенных таблиц (поверх 8 локальных на каждой ноде) Впереди балансер который рандомно отправляет на один из 8 серверов батч Может в топологии что-то не так?

Мы в некоторых таблицах нашли уникальный набор полей, добавили их в индекс, и сделали ReplacingMergeeTree, как раз против дубликатов

Т.е. ы обычной ситуации, потоке данных, их нет, но вот против таких случаев помогает :)

Или например что-то наоборот недолили, просто заново сверху льёшь данные, хлопаешь принудительно, и тоже красота

Если честно пол дня думал сегодня о таком решении Придется правда искусственный этот ключ слияния добавлять, естественного нет Это приведет к росту использования диска (у нас это критично ТК в среднем запись занимает 7.5 байт и лишнее поле увеличит размер значительно)

Другая причина против что слияния неконтролируемые, но правда с этим можно жить наверное

Тут люди говорят что атомарно должно быть если батч меньше блока Вот думаю все таки в эту сторону добить если подскажут есть ли шанс

у нас заливалка,если получает exception от кх, будет пытаться этот батч вставлять, пока не получится, проблем с дуликатами вроде нет

Нет проблем при использавании ReplacingMergeeTree? Просто с MergeeTree были?

не, нету

с MergeTree не было, просто иногда запуливались дубли, редко

Понял спсб. Странно тогдч что у меня наделало столько дублей

коллеги, я сильно странного хочу? CREATE TABLE stat_2( .... start_ts UInt64, ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(toDate(start_ts/1000000)) ORDER BY (toDate(start_ts, sensor_id) SETTINGS index_granularity = 8192; я про partiion by выражение, говорит invalid token

в ордер бай 2 скобки открылись, одна закрылась

в ордер бай 2 скобки открылись, одна закрылась

не оно :( сам уже заметил и поправил, все равно ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(toDate(start_ts/1000000)) ORDER BY (toDate(start_ts, sensor_id)) SETTINGS index_granularity = 8192; Unrecognized token

наверное так нельзя, и это логично, в принципе

запятая после start_ts UInt64, лишняя?

не оно :( сам уже заметил и поправил, все равно ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(toDate(start_ts/1000000)) ORDER BY (toDate(start_ts, sensor_id)) SETTINGS index_granularity = 8192; Unrecognized token

так не там же скобка

запятая после start_ts UInt64, лишняя?

не, там миллион полей.

toDate с одним аргументом

так не там же скобка

ой я ллошидзе

все тлен :) спасибо ребята, пойду rtfm-ить

Господа, всем добрейший вечерочек

Если sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data не помогает - как быть?

При запуске сервера ругается на зоокипер

и выдает такое

Cannot create table from metadata file /var/lib/clickhouse/metadata/default//logs.sql, error: DB::Exception: Cannot read all data, stack trace:

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

изучал содержимое папки metadata в файлах сервера и заметил, что некоторые DateTime столбцы объявлены как DateTime, а некоторые - как DateTime('W-SU'). подскажите плиз, в чем разница, и как такое могло вообще случиться, ведь вроде-бы все таблицы создавали указывая типы просто как DateTime?

Добрый вечер Помогите подобрать оптимальный варинт движка Есть таблица1 (допустим на 1 млрд записей), но нет колонки с датой Есть таблица2 (допустим на 300 млн записей), но нет колонки с датой Они между собой джойнятся и получаем таблицу3 С какими движками лучше создавать таблицы?

Опубликован русскоязычный changelog к версии 18.1.0: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#clickhouse-release-1810-2018-07-23

"Изменена схема версионирования релизов. Теперь первый компонент содержит год релиза (A.D.; по московскому времени; из номера вычитается 2000), второй - номер крупных изменений (увеличивается для большинства релизов), третий - патч-версия. Релизы по-прежнему обратно совместимы, если другое не указано в changelog." а почему не классический https://semver.org/ ?

@milovidov_an , планируете ли участие в http://www.highload.ru/moscow/2018 ?

@milovidov_an , планируете ли участие в http://www.highload.ru/moscow/2018 ?

Да, планирую. Только ещё не выбрал тему.

?

"Изменена схема версионирования релизов. Теперь первый компонент содержит год релиза (A.D.; по московскому времени; из номера вычитается 2000), второй - номер крупных изменений (увеличивается для большинства релизов), третий - патч-версия. Релизы по-прежнему обратно совместимы, если другое не указано в changelog." а почему не классический https://semver.org/ ?

Это было предметом обсуждений. Semver рассматривали, но неудобно, что первый компонент будет всегда единицей. А вообще вся мотивация изменения только в том, чтобы отличать патч-релизы (в которых есть только исправления) от обычных. Для обычных инкрементируется второй номер, а для патч - третий.

Было бы довольно интересно послушать о кликхаусе и опыте работы с ним больше, после работы с mysql на уровне обывателя: КХ = вынос мозга

Было бы довольно интересно послушать о кликхаусе и опыте работы с ним больше, после работы с mysql на уровне обывателя: КХ = вынос мозга

Просто mysql не нужна, простите. :) После оракла и хадупа КХ нормально заходит

Просто mysql не нужна, простите. :) После оракла и хадупа КХ нормально заходит

дорога ложка к обеду.

а вилка - к спагетти. КХ и мускул для разных задач же.

а вилка - к спагетти. КХ и мускул для разных задач же.

золотые слова!

Всем привет! Пытаюсь подключить CSV (https://github.com/datasets/currency-codes/blob/master/data/codes-all.csv) напрямую, как словарь. Можно ли сделать так чтобы ключ брался не из первого столбца?

Добрый день. если команда INSERT INTO SELECT вернула 200 код ответа , то она гарантированно вставит данные в таблицу?

такое ощущение что количество записей остановилось

Добрый день Существует ли какой-то православный способ в запросе установить один раз переменную, которую можно использовать во всех подзапросах? Пример - есть данные по приложениям/вебу, диапазон дат динамический: where Date in (select.....) Подзапрос с датой достаточно громоздкий, не хочется выполнять его отдельно для каждой части джоинов

Добрый день Существует ли какой-то православный способ в запросе установить один раз переменную, которую можно использовать во всех подзапросах? Пример - есть данные по приложениям/вебу, диапазон дат динамический: where Date in (select.....) Подзапрос с датой достаточно громоздкий, не хочется выполнять его отдельно для каждой части джоинов

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

Всем, привет. Когда планируется появление numeric/decimal? Видел предложение хранить в int64 и делить/умножать на 1000000, но есть ли более приятные пути?

Хранить отдельно целую и дробную части?

Испрльзовать float

Испрльзовать float

а если деньги?

а если деньги?

Не использовать float

Всем, привет. Когда планируется появление numeric/decimal? Видел предложение хранить в int64 и делить/умножать на 1000000, но есть ли более приятные пути?

Decimal сейчас в активной разработке, в Q3 можно ожидать.

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

про временную таблицу чет и не подумала. спасибо!

Decimal сейчас в активной разработке, в Q3 можно ожидать.

спасибо

Подскажите, а есть сопособ “перевернуть” результат? Что бы строки превратить в колонки?

Подскажите, а есть сопособ “перевернуть” результат? Что бы строки превратить в колонки?

Столбцы формировать через if, группировать с функцией any

поковыряю, спасибо

а, или вы имеете ввиду с помощью if на уровне приложения? я в графану запросы ковыряю, так что if-не вариант Но я видимо уже придумал как график заменить таблицей и вопрос вроде решается. Спасибо ?

Добрый день Помогите подобрать оптимальный варинт движка Есть таблица1 (допустим на 1 млрд записей), но нет колонки с датой Есть таблица2 (допустим на 300 млн записей), но нет колонки с датой Они между собой джойнятся и получаем таблицу3 С какими движками лучше создавать таблицы?

Добрый день. Есть таблица распределенная поверх вреплицируемых таблиц (4*2 4 шарда по 2 реплики) В целях стресс тестирования на одной машинке остановили КХ (node14). Через 20 мин началось на спаренной реплике 2018.07.27 10:26:01.949040 [ 638 ] <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (1502). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 10.1.2.5:47558) (in query: INSERT INTO MetricsDistributed FORMAT TabSeparated), Stack trace: 2018.07.27 10:26:02.010363 [ 638 ] <Error> HTTPHandler: Code: 252, e.displayText() = DB::Exception: Too many parts (1502). Merges are processing significantly slower than inserts., e.what() = DB::Exception, Stack trace: В это время сделали запрос такой ко всем нодам SELECT count(*) FROM system.parts WHERE active; node11 448 node12 442 node13 428 node14 N/А node21 448 node22 430 node23 426 node24 1511 1. Как видно на спаренной реплике (node24) кол-во партиции достигло лимита и она перестала принимать данные на запись. 2. В это время клиент который вставляет пачками начал получать исключение и пытаться повторно вставлять - как итог появление повторов хотя размер батча меньше во много раз чем настройка размера максималььного блока. 3. Запросы на чтение начали отдавать неконсистентные данные, такое ощущение что 24 вылетела из работы вслед за остановленной 14 из-за этих мержей и частей. Как только вернили 14 то 24 тоже ожил и запросы на чтение начали возвращать корректные данные По поводу 1, это нормаьное поведение? Почему node24 не маржит части без node14? Если мержить невозможно то есть ли смысл parts_to_throw_insert выставить не в 1500 а скажем в 20000? Чем это грозит? По поводу 2, дубликаты в таком случае это норма или все таки баг? Переходить на другой движок для схлопывания дубликатов или если баг то как обойти? Поведение 3 это норма? Как сделать чтобы исключение бросало вместо возвращения некорректных данных? Извините за много вопросов и длинный теекст, но надо рахобраться что делать по пунктам.

Добрый день Помогите подобрать оптимальный варинт движка Есть таблица1 (допустим на 1 млрд записей), но нет колонки с датой Есть таблица2 (допустим на 300 млн записей), но нет колонки с датой Они между собой джойнятся и получаем таблицу3 С какими движками лучше создавать таблицы?

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

Всем привет! Пытаюсь подключить CSV (https://github.com/datasets/currency-codes/blob/master/data/codes-all.csv) напрямую, как словарь. Можно ли сделать так чтобы ключ брался не из первого столбца?

Просто перегенерите CSV как вам нужно - это достаточно просто.

Добрый день. Есть таблица распределенная поверх вреплицируемых таблиц (4*2 4 шарда по 2 реплики) В целях стресс тестирования на одной машинке остановили КХ (node14). Через 20 мин началось на спаренной реплике 2018.07.27 10:26:01.949040 [ 638 ] <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (1502). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 10.1.2.5:47558) (in query: INSERT INTO MetricsDistributed FORMAT TabSeparated), Stack trace: 2018.07.27 10:26:02.010363 [ 638 ] <Error> HTTPHandler: Code: 252, e.displayText() = DB::Exception: Too many parts (1502). Merges are processing significantly slower than inserts., e.what() = DB::Exception, Stack trace: В это время сделали запрос такой ко всем нодам SELECT count(*) FROM system.parts WHERE active; node11 448 node12 442 node13 428 node14 N/А node21 448 node22 430 node23 426 node24 1511 1. Как видно на спаренной реплике (node24) кол-во партиции достигло лимита и она перестала принимать данные на запись. 2. В это время клиент который вставляет пачками начал получать исключение и пытаться повторно вставлять - как итог появление повторов хотя размер батча меньше во много раз чем настройка размера максималььного блока. 3. Запросы на чтение начали отдавать неконсистентные данные, такое ощущение что 24 вылетела из работы вслед за остановленной 14 из-за этих мержей и частей. Как только вернили 14 то 24 тоже ожил и запросы на чтение начали возвращать корректные данные По поводу 1, это нормаьное поведение? Почему node24 не маржит части без node14? Если мержить невозможно то есть ли смысл parts_to_throw_insert выставить не в 1500 а скажем в 20000? Чем это грозит? По поводу 2, дубликаты в таком случае это норма или все таки баг? Переходить на другой движок для схлопывания дубликатов или если баг то как обойти? Поведение 3 это норма? Как сделать чтобы исключение бросало вместо возвращения некорректных данных? Извините за много вопросов и длинный теекст, но надо рахобраться что делать по пунктам.

Надо смотреть почему ReplicatedMergeTree не смог назначить мержи при 1-й живой реплике, по идее это не должно ему мешать, ну отпала реплика и фиг с ней, поднимится скачает нужные куски и довыполнит нужные мержи. Для дубликатов по дефолту используются хеш-суммы последних 100 вставок, можно легко на это влететь учитывая что у вас 1,5к кусков, а значит и вставок было сильно больше 100. 3 тоже нужно смотреть что и как

Я готов на все вопросы отвечать и делать эксперименты. Куда и как смотреть почему мержи не шли? Как можно эти 100 хеш сумм увеличить чтобы избежать дубликатов? По 3 тоже согласен смотреть или показывать (в личку?)

Нет, если INSERT, вернул ошибку про много кусков, то данные вставиться не должны были. Дедупликация тут ни при чём. А расскажите подробнее про вашу вставлялку, что она делает, как ретраит?

parts_to_throw_insert сильно увеличивать не надо - если мержи сломаются, то вы этого не заметите, просто будет деградировать производительность SELECT-ов

Вот вчера расписал тут Есть массив А Создается createPreparedStatement потом много раз addBatch (бегаем по массиву А) а затем executeBatch Если упало исключение то все сначала. Новый createPreparedStatement и заново бегаем по тому же А Или что-то другое интересует?

это jdbc?

да

parts_to_throw_insert сильно увеличивать не надо - если мержи сломаются, то вы этого не заметите, просто будет деградировать производительность SELECT-ов

в нашем случае дубликаты и возвращение некорректных данных еще хуже

деградировать будет сильно

изучал содержимое папки metadata в файлах сервера и заметил, что некоторые DateTime столбцы объявлены как DateTime, а некоторые - как DateTime('W-SU'). подскажите плиз, в чем разница, и как такое могло вообще случиться, ведь вроде-бы все таблицы создавали указывая типы просто как DateTime?

нашел в changelog про версию 2018-01-18: Улучшена поддержка часовых поясов. В типе DateTime может быть указана таймзона, которая используется для парсинга и отображения данных в текстовом виде. Пример: DateTime('Europe/Moscow'). При указании таймзоны в функциях работы с DateTime, тип возвращаемого значения будет запоминать таймзону, для того, чтобы значение отображалось ожидаемым образом.

Я готов на все вопросы отвечать и делать эксперименты. Куда и как смотреть почему мержи не шли? Как можно эти 100 хеш сумм увеличить чтобы избежать дубликатов? По 3 тоже согласен смотреть или показывать (в личку?)

Вы же в distributed пишите, там по умолчанию распределение рандом, т.е. выши ретраи вполне себе могут писать в другой шард. Как уже сказали выше 1,5к для parts_to_throw_insert - это сильно много, нужно смотреть во что вы упираетесь при вставке, ну и понять почему Replicated* не мержат при смерти 1-й из 2-х реплик тоже, тут @ztlpn может рассказать почему так и почему так быть не должно. Вообще тут можно глянуть в логи и system.replication_queue + system.merges, возможно там что-то интересное будет.

merges и replication_queue тоже мониторил в мержах в основном пусто было, иногда ловил по 1-2

в очереди на репликацию обычно 0 или 4-6

как стопанул ноду так выросло до 50 и где-то около этоц цифры плясало на всех нодах

Вы же в distributed пишите, там по умолчанию распределение рандом, т.е. выши ретраи вполне себе могут писать в другой шард. наверное

простите но это неочевидно что оно так работает. Чтобы не было повторов получается не ранд использовать, верно?

Какой-то стабильный ключ или хеш?