ок, допустим. а разворачивать и обновлять как? шефом или ручками?

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

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

Это как раз несколько ограничивает такое совсем "облачное" использование КХ, где масштабирование вверх/вниз должно происходить без переконфигурирования и конфигурация кластера / "облака" сильно динамична. В настоящее время КХ требует много "ручного" / "полуручного" конфигурирования, и конфигурацяи должна быть относительно статична. Поэтому всякие там кубернетисы мало что дают. В идеале конфигурация кластера наверное должна поддерживаться чем-то типа discovery service куда регистрируется каждый новый хост, и тогда автоматически начинает получает получать данные и запросы и подхватывая от соседей данные. В случае если какой-то хост падает / пропадет то куски которые на нём были должны скопироваться на какие-то другие хосты в кластере, чтобы обеспечить нужный replication factor. Но чтобы это нормально работало это должна "нативно" поддерживать сама база.

зукипер не может это сделать?

@milovidov_an вы не планируете что-то типа этого? ^^ КХ реально крут в процессинге данных, но вот с распределенностью у него не всё гладно. Идеально - это что-то типа кликхаус поверх торрнетов :) Когда части размазываются между участиниками сети в соответствии с представлением сети о том как должны быть "размазаны" данные :)

но это только для замены. а увеличить количество нод так не получится...

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

зукипер не может это сделать?

да вроде как service discovery на зукипере не сложно сделать.

if (name == "FILEDSN" || name == "SAVEFILE" || name == "DRIVER") throw Exception("ODBC connection string has forbidden parameter", ErrorCodes::BAD_ODBC_CONNECTION_STRING);

С DSN у меня другая траба: Я делаю вот так select * from odbc('DSN=production', 'jobs') limit 100 но эти 100 строк кликхаус достаёт больше минуты. При том с той же тачки через isql production всё работает мгновенно. Куда компать?

И как теперь быть?

https://clickhouse.yandex/docs/en/query_language/dicts/external_dicts_dict_sources/#example-of-connecting-postgresql

С DSN у меня другая траба: Я делаю вот так select * from odbc('DSN=production', 'jobs') limit 100 но эти 100 строк кликхаус достаёт больше минуты. При том с той же тачки через isql production всё работает мгновенно. Куда компать?

К сожалению, я не настоящий сварщик и odbc не использовал - просто копнул в место исключения, вдруг поможет :)

https://clickhouse.yandex/docs/en/query_language/dicts/external_dicts_dict_sources/#example-of-connecting-postgresql

и где там ответ на мой вопрос?

И как теперь быть?

В смысле - попробуйте сконфигурировать DSN в системе, вместо указания драйвера в запросе.

Так я это уже сделал. Всё работает, но очень медленно. Кликхаус достаёт 100 строчек больше минуты, а через системный isql всё мгновенно

С DSN у меня другая траба: Я делаю вот так select * from odbc('DSN=production', 'jobs') limit 100 но эти 100 строк кликхаус достаёт больше минуты. При том с той же тачки через isql production всё работает мгновенно. Куда компать?

Могу только предположить, что он сначала все данные вытягиваает из постгреса, а лимит выполняет уже на стороне КХ.

С DSN у меня другая траба: Я делаю вот так select * from odbc('DSN=production', 'jobs') limit 100 но эти 100 строк кликхаус достаёт больше минуты. При том с той же тачки через isql production всё работает мгновенно. Куда компать?

Так и есть (как выше ответили). LIMIT выполняется из Clickhouse, так что вытягивается вся таблица.

хм..

ок, спс!

но почему? постгря же умеет лимит обрабатывать

но почему? постгря же умеет лимит обрабатывать

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

Семантика запроса такая. odbc - табличная функция, которая возвращает поток данных. Чтобы запрос пробрасывался в нижележащий движок, нужна функция, в которую будет пробрасываться целиком запрос

Хм. Интересная штуковина - кликхаус позволяет создавать/хранить состояния аггрегатных функций с -If. Только я не понимаю 1) зачем 2) как это потом использовать? :) Контекст: как оказалось между groupArrayStateIf и groupArrayIfState есть большая разница. Второе создает тип данных AggregateFunction(groupArrayIf, String, UInt8), на которым не понятно как сделать Merge. :)

на центосе сборка 18.12.14 от альтинити - в клиенте стрелки на клавиатуре не работают, печатаются символы: clickhouse-client ClickHouse client version 18.12.14. Connecting to localhost:9000. Connected to ClickHouse server version 18.12.14 revision 54407. 1clickhouse0004.ad.rambler.tech :) ^[[A^[[B^[[C^[[D

кто что может подсказать?

на центосе сборка 18.12.14 от альтинити - в клиенте стрелки на клавиатуре не работают, печатаются символы: clickhouse-client ClickHouse client version 18.12.14. Connecting to localhost:9000. Connected to ClickHouse server version 18.12.14 revision 54407. 1clickhouse0004.ad.rambler.tech :) ^[[A^[[B^[[C^[[D

Что-то у них с readline поломалось. Им уже сообщили.

Что-то у них с readline поломалось. Им уже сообщили.

Спс

the newest version 18.12.14 from Altinity seems has some problem, the auto complete function seems not work on clickhouse-client

Thank you for alert, we will investigate what's happened with the build (every time building clickhouse is a quest) and fix ASAP

https://blog.jetbrains.com/datagrip/2018/08/15/datagrip-2018-2-2-clickhouse-support-and-bugfixes/

у меня базы показывает как схемы, а таблицы вообще не показывает. У всех так?

у меня базы показывает как схемы, а таблицы вообще не показывает. У всех так?

У меня всё ок

@milovidov_an вы не планируете что-то типа этого? ^^ КХ реально крут в процессинге данных, но вот с распределенностью у него не всё гладно. Идеально - это что-то типа кликхаус поверх торрнетов :) Когда части размазываются между участиниками сети в соответствии с представлением сети о том как должны быть "размазаны" данные :)

Мы что-то типа такого делаем, только без торентов, но с автодискавери и кучей автоматизации, но времени сильно нехватает, надеюсь к новому году что-то на попробовать выкатим )

Кстати, в новых версиях КХ должна быть ручка чтоб он сам старые хосты переставал видеть как живые в ZK и не копил лог репликации и прочего после некого порога, что уже сильно проще для динамического развертывания типа в к8

Мы что-то типа такого делаем, только без торентов, но с автодискавери и кучей автоматизации, но времени сильно нехватает, надеюсь к новому году что-то на попробовать выкатим )

В код кликхаус или поверх КХ?

В код кликхаус или поверх КХ?

Поверх КХ, сейчас форкать КХ и что-то делать отдельно весьма сомнительное решение.

Поверх КХ, сейчас форкать КХ и что-то делать отдельно весьма сомнительное решение.

Ну я не в смысле форкать, а в смысле какое-нибудь allow_experimental_service_discovery = 1 и в основном бранче. Хотя вряд ли это легко воплотимо без очень серьезного раскапывания кода.

Кто-то использует JDBC драйвер? почему может возникать ошибка "ClickHouse response without column names" версия драйвера 0.1.41 версия сервера 18.10.3 (54405)

Ну я не в смысле форкать, а в смысле какое-нибудь allow_experimental_service_discovery = 1 и в основном бранче. Хотя вряд ли это легко воплотимо без очень серьезного раскапывания кода.

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

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

Поддержка такой магии "внутри" была бы сильно здоровее чем наружняя "обертка". Если представить себе что около КХ ещё нужно поставить какого-то демона который будет как-то следить дополнительно за тем что происходит в кластере и править конфигурацию кластера "на лету" - как-то страшновато становится :) Хотя наверное реально всё - нужно только интенсивно взаимодествовать с зукипером и в конфигах повсеместно использовать from_zk=...

Поддержка такой магии "внутри" была бы сильно здоровее чем наружняя "обертка". Если представить себе что около КХ ещё нужно поставить какого-то демона который будет как-то следить дополнительно за тем что происходит в кластере и править конфигурацию кластера "на лету" - как-то страшновато становится :) Хотя наверное реально всё - нужно только интенсивно взаимодествовать с зукипером и в конфигах повсеместно использовать from_zk=...

Мы сами конфиги генерим, а данные храним в ZK

Вернее один большой конфиг, так как его не человек смотрит )

Ну сгенерить - полбеды, а как подменять? При том что некоторые изменения могут и рестарта требовать?

Ну сгенерить - полбеды, а как подменять? При том что некоторые изменения могут и рестарта требовать?

С рестартом как раз самое интересное, нужно расчитать что можно рестартить (учесть какие есть шарды и реплики) и каскадно запускать рестарт.

18.12.17 - есть changelog? Какая версия click на текущий момент является достаточно стабильной?

Ну и кроме того если это не виртуалка, а железный сервер, то варианты типа "а давайте дадим этому демону права писать куда-то в /etc/ " звучат так себе. Наши ОПсы сильно возмущались уже тем что кликхаус пишет свои -processed.xml в /etc/.

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

Добрый день. Таблица с партиционированием по дню (PARTITION BY date). При создани бэкапа командой FREEZE за год появляется такая ошибка: user@ip-10-0-0-1:~# clickhouse-client --query="ALTER TABLE test.myTable FREEZE PARTITION '2018';" Received exception from server (version 1.1.54342): Code: 33. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Cannot read all data. Аналогичный запрос для таблицы с партиционированием по умолчанию работает корректно. Подскажите, как можно решить проблему годового бэкапа? Возможно, как-то задать имени партиции в числовом формате (20180101) вместо строкового ('2018-01-01')

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

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

Если "очень старый" то весьма вероятны. В changelog есть информация про обратной совместимости.

спасибо. Я хотел убедится. При реэкспорте в формате native проблем быть не должно?

спасибо. Я хотел убедится. При реэкспорте в формате native проблем быть не должно?

Могут не поддерживаться новые типы, если их не использовать то - ОК

мне надо из старого в новый вытащить)

Из старого в новый должно работать

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

супер, спасибо

у вас time_ все время разный, назовите по другому CREATE MATERIALIZED VIEW mtrades ENGINE = AggregatingMergeTree(EventDate, (isin_, time__), 8192) POPULATE AS select toDate(time_) as EventDate, isin_, toInt64(intDiv(toUInt32(time_), 60) * 60) AS time__ argMinState(price_, time__) as open_, argMaxState(price_, time__) as close_, sumState(abs(amount_)) as amount_, from trades GROUP BY EventDate, isin_, time__ select isin_, argMinMerge(open_) as open_, argMaxMerge(close_) as close_, sumMerge(volume_) as volume_, time__ from mtrades group by isin_, time__ https://clickhouse.yandex/docs/en/query_language/functions/date_time_functions/#tostartofminute

Подскажите пожалуйста, кто как организовывал обновление данных в КХ? Понятно, что для обновления данных можно использовать CollapsingMergeTree. Но как быть с удалением строк?

Подскажите пожалуйста, кто как организовывал обновление данных в КХ? Понятно, что для обновления данных можно использовать CollapsingMergeTree. Но как быть с удалением строк?

а что вы хотите удалять?

Подскажите пожалуйста, кто как организовывал обновление данных в КХ? Понятно, что для обновления данных можно использовать CollapsingMergeTree. Но как быть с удалением строк?

если к вам приходят более новые данные по тем же id, то ReplacingMergeTree будет хорошим решением

Подскажите пожалуйста, кто как организовывал обновление данных в КХ? Понятно, что для обновления данных можно использовать CollapsingMergeTree. Но как быть с удалением строк?

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

С ReplacingMergeTree вы будете получать фантомные записи

не будет возможности принудительно схлопнуть записи, у CollapsingMergeTree можно указать FINAL

а что вы хотите удалять?

Записи из источника данных

не будет возможности принудительно схлопнуть записи, у CollapsingMergeTree можно указать FINAL

в ReplacingMergeTree вы тоже можете сделать FINAL вместе с OPTIMIZE TABLE и будет хорошо

Записи из источника данных

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

ERROR: S client not available

по ключу будет происходит схлопывание данных, после схлопывания останется последняя пришедшяя строка по ключу

supplier | amount 1 | 100 1 | 50

если записи пришли в таком порядке, от останется только последняя после схловывания, это сильно упрощенный пример, но тем не менее

Подскажите пожалуйста, кто как организовывал обновление данных в КХ? Понятно, что для обновления данных можно использовать CollapsingMergeTree. Но как быть с удалением строк?

ALTER TABLE DELETE?

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

По ключам перетирать можно, но что делать с записями, которые удаляются из таблицы-источника. Для update-insert есть вариант использовать триггеры и COPY TO PROGRAM, а вот насчет удалений не придумал

мы для себя используем в подобном кейсе

ALTER TABLE DELETE?

не вариант, данных террабайты будут

По ключам перетирать можно, но что делать с записями, которые удаляются из таблицы-источника. Для update-insert есть вариант использовать триггеры и COPY TO PROGRAM, а вот насчет удалений не придумал

наверное здесь как раз подойдет CollapsingMergeTree с досыланием -1 на нужные записи

наверное здесь как раз подойдет CollapsingMergeTree с досыланием -1 на нужные записи

Спасибо, тоже к этому прихожу.

наверное здесь как раз подойдет CollapsingMergeTree с досыланием -1 на нужные записи

Это не сильно лучше чем ALTER TABLE DELETE и очень сильно не гарантирует что данные будут удалены ;)

Это не сильно лучше чем ALTER TABLE DELETE и очень сильно не гарантирует что данные будут удалены ;)

они ведь рано или поздно удалятся, как вы писали где-то, optimize final схлопаывает их принудительно)

они ведь рано или поздно удалятся, как вы писали где-то, optimize final схлопаывает их принудительно)

Когда-то удаляться, но это не точно. Плюс старые и большие куски могут долго не мержиться или не мержиться вовсе. Колапсом хорошо работать по достаточно новым данным

OPTIMIZE дорогой процесс

и он не выполняется вместе с FINAL

FINAL на лету отдаст уже актуальные данные с учетом поля sign

Там обещают террабайты данных, можно никогда не дождаться SELECT с FINAL

Там обещают террабайты данных, можно никогда не дождаться SELECT с FINAL

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

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

Не удалять ) Надо знать что за задача и детали, сейчас есть еоробочное решение через ALTER DELETE, нужно его смотреть, возможно есть лучшие решение, но нужно больше деталей как и что будет храниться.

@milovidov_an вы не планируете что-то типа этого? ^^ КХ реально крут в процессинге данных, но вот с распределенностью у него не всё гладно. Идеально - это что-то типа кликхаус поверх торрнетов :) Когда части размазываются между участиниками сети в соответствии с представлением сети о том как должны быть "размазаны" данные :)

В планах есть, идёт пунктом "Облачные таблицы".

Не удалять ) Надо знать что за задача и детали, сейчас есть еоробочное решение через ALTER DELETE, нужно его смотреть, возможно есть лучшие решение, но нужно больше деталей как и что будет храниться.

кейсы чаще всего удалять, либо перезаписывать что-то, с ALTER не все так однозначно, а схлопнуть строки по условием, кажется простым решением, но только с артефактами)

кейсы чаще всего удалять, либо перезаписывать что-то, с ALTER не все так однозначно, а схлопнуть строки по условием, кажется простым решением, но только с артефактами)

Это не "конек" КХ, зачастую на практике проще перезалить партицию с откоректированными данными, но это тоже сильно редкие операции

В планах есть, идёт пунктом "Облачные таблицы".

?

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

добрый день, уважаемые

требуется помощь

при загрузке данных через $ clickhouse-client -n < data.sql загрузка падает с errno: 28

причём места достаточно

и мониторю место при загрузке

но.. стоит подключиться с помощью strace к процессу clickhouse-server, то больше не падает

VERSION_FULL ClickHouse 18.12.14 VERSION_DESCRIBE v18.12.14-testing VERSION_GITHASH 84cde3429bec15028992497b3ab7e7a0fb53a253 VERSION_REVISION 54407