Всем привет! Подскажите, плз, как проверить, что строка s1 является постфиксом строки s2 (аналог endswith в Python). Только через substring это можно сделать?

Делаю так: substring(s1, length(s1) - length(s2) + 1, length(s2)) = s2, но мб есть способ покороче?

Всем привет! Подскажите, плз, как проверить, что строка s1 является постфиксом строки s2 (аналог endswith в Python). Только через substring это можно сделать?

Почему "только"? Можно like, можно position, можно регулярным выражением. См. https://clickhouse.yandex/docs/en/functions/string_search_functions/

Всем привет! Подскажите, плз, как проверить, что строка s1 является постфиксом строки s2 (аналог endswith в Python). Только через substring это можно сделать?

В следующем релизе будет endsWith. https://github.com/yandex/ClickHouse/blob/8eee32cdd250d34499a60fb90eb72a528695c8b2/CHANGELOG_RU.md

Спасибо!

select * from (select 'asd' as a, 'sd' as postfix) where a like concat('%', postfix)

Делаю так: substring(s1, length(s1) - length(s2) + 1, length(s2)) = s2, но мб есть способ покороче?

А так не получится? select 'abcd' like ('%' || 'cd');

select * from (select 'asd' as a, 'sd' as postfix) where a like concat('%', postfix)

select c_1 like concat('%', c_2) from ( select 'a***b' as c_1, '_b' as c_2) возвращает единицу. Стоит быть аккуратным со спецсимволами *, _ и проч. из паттернов

А так не получится? select 'abcd' like ('%' || 'cd');

?

Может быть я покажусь занудой, но вы читали README того clickhouse-driver? :) Там есть пример и инсерта и селекта. https://github.com/mymarilyn/clickhouse-driver

эту доку читал, но как-то упустил этот момент. помогло! спасибо!!!

Делаю так: substring(s1, length(s1) - length(s2) + 1, length(s2)) = s2, но мб есть способ покороче?

можно упростить SELECT substring('abcd', -length('cd')) = 'cd'

Всем привет, я мог пропсутить, обсуждался ли вопрос апгрейда версии сервера в рамках шарда? Есть ли какой то best practice? Единственное что я нашел это https://groups.google.com/forum/#!topic/clickhouse/7Z9o4BBj8VE To do upgrade, just install new package and restart clickhouse-server. To do upgrade on cluster without downtime, install new package everywhere, then restart on half of replicas, then on another half. Но обсуждение достаточно старое, может есть более свежее что то?

ну все таки осталось

собственно реплики друг с другом не работают если разные версии

а шардам друг на друга пофиг все работает

при изменении uncompressed_cache_size и mark_cache_size надо рестартить кх? при этом в config-preprocessed.xml значения поменялись

собственно реплики друг с другом не работают если разные версии

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

при изменении uncompressed_cache_size и mark_cache_size надо рестартить кх? при этом в config-preprocessed.xml значения поменялись

Надо

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

раньше было так по доке

Надо

?

Надо

при периодических ошибках ZooKeeper session has expired. Switching to a new session. DB::Exception: Table is in readonly mode куда копать? нагрузка мизерная, зукиперы на тех же тачках

у zk при этом: 2018-06-28 14:40:43,673 [myid:1] - WARN [RecvWorker:3:QuorumCnxManager$RecvWorker@1025] - Connection broken for id 3, my id = 1, error = java.net.SocketException: Connection timed out (Read failed)

при периодических ошибках ZooKeeper session has expired. Switching to a new session. DB::Exception: Table is in readonly mode куда копать? нагрузка мизерная, зукиперы на тех же тачках

Надо смотреть почему они не могут достучаться друг до друга, вообще лучше ZK выносить от КХ чтоб они друг друга не афектили. У нас просто сильно больше чем 3 ZK и если там что-то "моргает" мы этого не замечаем )

Надо смотреть почему они не могут достучаться друг до друга, вообще лучше ZK выносить от КХ чтоб они друг друга не афектили. У нас просто сильно больше чем 3 ZK и если там что-то "моргает" мы этого не замечаем )

т.е. я вот пару раз замечал, что если кто-то запускает монстр-запрос, при этом ложится коннект к зк, это вот поэтому? лучше унести зк от кх?

у нас на основном класетере 8 тачек и 7 зк, но такое тодже периодически случается

но зк на тех же тачках находятся

Да, лучше убирать

ребята, подскажите пожалуйста, я тут пытаюсь компилить clickhouse на mac os, на этапе Build Clickhouse после cmake вызываю ninja, у меня выскакивается ошибку ninja: error: loading 'build.ninja': No such file or directory

может у кого-то была похожая проблема ?

ребята, подскажите пожалуйста, я тут пытаюсь компилить clickhouse на mac os, на этапе Build Clickhouse после cmake вызываю ninja, у меня выскакивается ошибку ninja: error: loading 'build.ninja': No such file or directory

cmake -G Ninja?

cmake -G Ninja?

сработало, спасибо большое )

yandex/ClickHouse was tagged: v1.1.54388-stable Link: https://github.com/yandex/ClickHouse/releases/tag/v1.1.54388-stable Release notes: v1.1.54388-stable

Уууу, еще changelog бы где-нить глянуть

Уууу, еще changelog бы где-нить глянуть

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

благодарю

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

да все будет сжиматься

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

Почему не будет сжиматься? Будет размер партиции в день, а не месяц

почему не будет то ?

Почему не будет сжиматься? Будет размер партиции в день, а не месяц

Там же он сжимает в рамках партиции? Или я ошибаюсь?

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

Там же он сжимает в рамках партиции? Или я ошибаюсь?

Да, жмет в рамках партиции поэтому при партиции в день сжатие не такое эффективное

Партиция - некий логический кусок данных, на которые побита таблица

Да, жмет в рамках партиции поэтому при партиции в день сжатие не такое эффективное

Спорное утверждение, всё зависит от данных

Спорное утверждение, всё зависит от данных

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

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

Пожаты лучше почему? Я согласен что лучше не менять дефолтные параметры без сильной необходимости. Но пока не могу понять почему одни и те же данные в партиции по месячно жмутся лучше чем по дню. Я понимаю, что для кого-то на 1 % меньше - куча съэкономленных денег. О каком порядке "лучше" идёт речь?

Пожаты лучше почему? Я согласен что лучше не менять дефолтные параметры без сильной необходимости. Но пока не могу понять почему одни и те же данные в партиции по месячно жмутся лучше чем по дню. Я понимаю, что для кого-то на 1 % меньше - куча съэкономленных денег. О каком порядке "лучше" идёт речь?

Когда я "игрался" с нашими данными у меня партиции по дно занимали в 7-8 раз больше места

А у вас не сохранилось данных в КХ? Было бы интересно посмотреть файлы за один и тот же месяц при партиционирование по месяцу и по дню. Что там с размерами индекса например

На размер индекса это не будет сильно влиять

Когда я "игрался" с нашими данными у меня партиции по дно занимали в 7-8 раз больше места

Любопытно. У нас разница есть, но там проценты а не в разы. Там если память мне не изменяет данные жмутся поблочно (по 64 Кб вроде по умолчанию). Ну и вся разница в том насколько разные у вас будут данные в рамках каждого блока (а это зависит от выбора PK).

Данных у нас в КХ много, но месяц сливать очень долго чтоб посмотреть

Любопытно. У нас разница есть, но там проценты а не в разы. Там если память мне не изменяет данные жмутся поблочно (по 64 Кб вроде по умолчанию). Ну и вся разница в том насколько разные у вас будут данные в рамках каждого блока (а это зависит от выбора PK).

У нас сильно много одинаковых данных: юзерагенты, рефереры ... возможно из за этого сильно большая разница

У нас сильно много одинаковых данных: юзерагенты, рефереры ... возможно из за этого сильно большая разница

Нас тут таких много с юзерагентами, реферерами и т.п. :)

Нас тут таких много с юзерагентами, реферерами и т.п. :)

+1

Нас тут таких много с юзерагентами, реферерами и т.п. :)

Знаем-знаем. Если честно то я не знаю почему наши данные так себя повели, да и копаться не стал, нам партиции по дно ненужны. Может, как будет время, попробую ради интереса еще раз переналить.

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

А чего, DELETE так и не завезли?(

Из замеченных (довольно неприятных) особенностей дневного партиционирования - это медленный старт сервера.

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

Мы пользуемся недельными партициями

А чего, DELETE так и не завезли?(

ALTER TABLE t DELETE WHERE а это не оно?

Я ожидал просто DELETE видимо) А реплицированных таблиц это ReplicatedMergeTree тоже?

Я ожидал просто DELETE видимо) А реплицированных таблиц это ReplicatedMergeTree тоже?

Да

мм ну как практика показала при апгрейде одной реплики 1.1.54362 ==> 1.1.54385 репликация с более новой на более старую версию продолжает бежать, само по себе ничего не останавливается

Знаем-знаем. Если честно то я не знаю почему наши данные так себя повели, да и копаться не стал, нам партиции по дно ненужны. Может, как будет время, попробую ради интереса еще раз переналить.

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

Пожаты лучше почему? Я согласен что лучше не менять дефолтные параметры без сильной необходимости. Но пока не могу понять почему одни и те же данные в партиции по месячно жмутся лучше чем по дню. Я понимаю, что для кого-то на 1 % меньше - куча съэкономленных денег. О каком порядке "лучше" идёт речь?

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

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

Да, я понимаю, у нас для части данных партиции по неделе, они быстро "устаревают" и их так проще выкидывать. А сканить онбудет мало если просто дата в индексе есть. Сейчас (с ALTER DELETE) все проще, не нужно делать дневную партицию чтоб ее удобнее было заменять, можно просто удалить день )

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

Если запросы за большие интервалы и затрагивают много партиций - это хуже работает

Если вы за год/два выбираете это будет очень сильно заметно с партициями по дню ;)

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

Чем меньше партиций нужно будет прочитать при "средних" запросах - тем лучше будет производительность.

Т.е. если у вас типичные запросы за месяц - то и партиционирование делайте по месяцах.

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

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

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

Да, в этом несомнено плюс, почистить колонку гораздо проще и безболезненнее чем сделать ALTER DELETE. У нас немного другие заморочки, гранулярность индекса на разных данных разная: 32, 64 и 16к )

Джентельмены, у вас в доке написано, что движок MergeTree из tab-separated дампа тянет на запись 50-200МБ/сек, чем это обусловлено? Хочу посчитать, сколько серверов мне нужно в кластере, если я знаю количество строк в секунду, их средний размер и производительность дисковой подсистемы, а вставка будет идти через jdbc драйвер.

А как реализована поддержка Alias в запросах: alias вычисляется единожды или при каждом использовании в выражениях? Сколько раз будет вычислен 'A' в таком select, например: SELECT (1+2 as A) + 3 AS B, A+B AS C

Джентельмены, у вас в доке написано, что движок MergeTree из tab-separated дампа тянет на запись 50-200МБ/сек, чем это обусловлено? Хочу посчитать, сколько серверов мне нужно в кластере, если я знаю количество строк в секунду, их средний размер и производительность дисковой подсистемы, а вставка будет идти через jdbc драйвер.

Зависит от количества колонок и их типа/размера. Посчитать будет несколько сложно, так как дисковая система, да и сам сервер будут нагружены неравномерно, те же мержи могут афектить. Проще накидать тастовых даных в сервер и посмотреть, а гадать тут относительно сложно

Кстати, кто-нибудь пробовал ? https://github.com/housepower/ClickHouse-Native-JDBC This is a native JDBC library for accessing ClickHouse in Java. Uses native ClickHouse tcp client-server protocol, with higher performance than HTTP Compatibility with java.sql Data Compression

Кстати, кто-нибудь пробовал ? https://github.com/housepower/ClickHouse-Native-JDBC This is a native JDBC library for accessing ClickHouse in Java. Uses native ClickHouse tcp client-server protocol, with higher performance than HTTP Compatibility with java.sql Data Compression

да, мы

приходи

а на сколько быстрее будет по нативному протоколу?

если передача данных не большая

если небольшая то и разница будет не большой

а на сколько быстрее будет по нативному протоколу?

Там даже дело не столько в скорости, а в том что данные уже "подготовлены" и сервер не тратит ресурсы на преобразование типов, все это можно вынести в пишущий воркер. По скорости - да, быстрее, но все зависит от того что пишите

Эх, теперь бы ещё документацию актуальную :)

будет и дока, оно всё закоммичено

будет и дока, оно всё закоммичено

?

я по диффам смотрел, все ок

Господа вопрос про дату/время. Данные вставляются через параметры ADO.NET и интерпретируются как UTC. В запросе toDateTime('yyyy-MM-dd HH:mm:ss') через тот-же провайдер интерпретируются как локальные в таймзоне сервера... Как добится консистентного предсказуемого поведения? Как-нить можно в toDateTime передавать таймзону дабы не зависить от настроек клиента/сервера?

Дополнительно, функция toString от аргумента типа DateTime может принимать второй аргумент String - имя тайм-зоны. Пример: Asia/Yekaterinburg В этом случае, форматирование времени производится согласно указанной тайм-зоне. SELECT now() AS now_local, toString(now(), 'Asia/Yekaterinburg') AS now_yekat ┌───────────now_local─┬─now_yekat───────────┐ │ 2016-06-15 00:11:21 │ 2016-06-15 02:11:21 │

мне не форматировать. мне сформировать sql-запрос вида select * from tableName where dt>=toDateTime('bla-bla-bla') чтобы этот bla-bla-bla интепретировался как мне надо а не как админ на сервере таймзону выставил

мне не форматировать. мне сформировать sql-запрос вида select * from tableName where dt>=toDateTime('bla-bla-bla') чтобы этот bla-bla-bla интепретировался как мне надо а не как админ на сервере таймзону выставил

SELECT toDateTime('2018-06-29 10:05:34', 'Asia/Yekaterinburg') AS test_datetime, toTypeName(test_datetime) AS type ┌───────test_datetime─┬─type─────────────────────────────┐ │ 2018-06-29 10:05:34 │ DateTime(\'Asia/Yekaterinburg\') │ └─────────────────────┴──────────────────────────────────┘

а список локалей ('Asia/Yekaterinburg') где взять???

какая локаль для UTC?

локали - в /usr/share/zoneinfo

А UTC он и есть UTC (не путать с GMT!)

https://en.wikipedia.org/wiki/List_of_tz_database_time_zones