подскажите, есть int64 в нем timestamp с точностью до миллисекунд, надо экспортить в CSV, как сконвертить timestamp в ISO 8601 с точностью до миллисекунды?

Попробуйте concat(toString(toDateTime(intDiv(x, 1000))), toString(x % 1000))

Промахнулся... Был вопрос про словари и количество коннектора к mysql

ха, это был мой вопрос, общем-то я победил это thread_handling = pool-of-threads

подскажите, сервис кх падает сразу после старта с (code=exited, status=232/ADDRESS_FAMILIES) . В users.xml заменил все <ip>::/0</ip> на <ip>0.0.0.0/0</ip> и все равно падает

Посмотрите users.xml И config.xml - все адреса, которые там есть. И ещё проверьте, у вас IPv4 only или IPv6 only.

ребят, вопрос не по теме, слышал что Яндекс балуется с ClickHouse в porto, есть какой то чатик про porto или можно кого то попинать, есть пару вопросов

На некоторых серверах в Яндексе ClickHouse работает внутри porto. Конкретных особенностей не знаю.

Посмотрите users.xml И config.xml - все адреса, которые там есть. И ещё проверьте, у вас IPv4 only или IPv6 only.

ip4 only

Если по логу непонятно на какой именно адрес ругается, запустите с помощью sudo -u clickhouse strace -f -e trace=network /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml.

Если по логу непонятно на какой именно адрес ругается, запустите с помощью sudo -u clickhouse strace -f -e trace=network /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml.

о, спасибо большое

Добрый день. Есть ли в ClickHouse какие-либо функции для работы с геоданными? У меня сейчас задача выбрать из базы количество точек внутри полигона. Понятно, что окружность или прямоугольник обработать очень просто, но есть ли возможность что-то сделать с рандомным полигоном?

https://github.com/yandex/ClickHouse/blob/61e5b0476f9a990952bea046c3415405d8d43a2e/dbms/tests/queries/0_stateless/00500_point_in_polygon.sql

Ооо, спасибо.

Всем привет! Есть таблица с метриками, которые собираются очень часто, но нужны значения только изменившиеся, промежуточных дубликатов будет 99% и не хочется их хранить. Также, не хочется перед записью точки данных делать select для проверки, не изменилось ли. Подскажите, плиз, подходит ли Relacing Merge Tree для этой дадачи? айди | дата-время | количество 1 | 2018-01-01 01:00:00 | 100 1 | 2018-01-01 01:00:01 | 100 1 | 2018-01-01 01:00:02 | 100 1 | 2018-01-01 01:00:03 | 101 V айди | дата-время | количество 1 | 2018-01-01 01:00:00 | 100 1 | 2018-01-01 01:00:03 | 101

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

нет там разного уровня, просто в докер все достаточно криво реализовано. Если скрестить LXC и Docker, взяв от докера его удобства в виде API, registry и прочего получилось бы очень ничего, это и пытаются сделать в LXD, но, получается не то чтобы очень в виду того что делают это только 2-а человека и, в виду того что они в теме и ко многим вещам просто привыкли и они им кажутся очевидными, оно получается немного топорно для людей со стороны. Но, 3-я версия совсем неплоха + она LTS, я думаю что оно еще выстрелит.

ребят, вопрос не по теме, слышал что Яндекс балуется с ClickHouse в porto, есть какой то чатик про porto или можно кого то попинать, есть пару вопросов

Про использование Porto в Яндекс есть https://www.youtube.com/watch?v=2QJgCTF1cIE, а вообще да, не хватает howto и различных примеров как запускать. По ощущениям близок к LXC/LXD, но проще что-то туда добавить/поправить если нужно.

нет там разного уровня, просто в докер все достаточно криво реализовано. Если скрестить LXC и Docker, взяв от докера его удобства в виде API, registry и прочего получилось бы очень ничего, это и пытаются сделать в LXD, но, получается не то чтобы очень в виду того что делают это только 2-а человека и, в виду того что они в теме и ко многим вещам просто привыкли и они им кажутся очевидными, оно получается немного топорно для людей со стороны. Но, 3-я версия совсем неплоха + она LTS, я думаю что оно еще выстрелит.

Я пока на 2.21

Про использование Porto в Яндекс есть https://www.youtube.com/watch?v=2QJgCTF1cIE, а вообще да, не хватает howto и различных примеров как запускать. По ощущениям близок к LXC/LXD, но проще что-то туда добавить/поправить если нужно.

Как минимум они уже отказались от имплементации корректной /proc в кт https://github.com/yandex/porto/issues/37

Я там кстати немного в ишью понадоедал розрабам. Там есть примеры полезные если кому нужно :)

нет там разного уровня, просто в докер все достаточно криво реализовано. Если скрестить LXC и Docker, взяв от докера его удобства в виде API, registry и прочего получилось бы очень ничего, это и пытаются сделать в LXD, но, получается не то чтобы очень в виду того что делают это только 2-а человека и, в виду того что они в теме и ко многим вещам просто привыкли и они им кажутся очевидными, оно получается немного топорно для людей со стороны. Но, 3-я версия совсем неплоха + она LTS, я думаю что оно еще выстрелит.

Я что-то не смог найти чейнджлог. Не в курсе, где посмотреть?

Я что-то не смог найти чейнджлог. Не в курсе, где посмотреть?

https://discuss.linuxcontainers.org/t/lxd-3-0-0-has-been-released/1491

Спасибо

Как минимум они уже отказались от имплементации корректной /proc в кт https://github.com/yandex/porto/issues/37

Их право, если это не нужно Яндексу они делать не будут, но, думаю, PR могут и принять

Их право, если это не нужно Яндексу они делать не будут, но, думаю, PR могут и принять

Ну никто и не спорит:) Нужно же было понять что и как

Попробуйте concat(toString(toDateTime(intDiv(x, 1000))), toString(x % 1000))

Извините, тут написана глупость. Странно, что никто не заметил.

Привет всем! Как то тут пусто, неужели телеграм таки заблокировали? Или просто выходные? Столкнулся с особенностями кворумной записи. 1. Пишем в консольном клиенте строчку в таблицу ReplicatedMergeTree (3 реплики), кворумная запись отключена. Затем через HTTP читаем из таблицы, выставив настройки select_sequential_consistency=1 - записи нет. Долго нет, минут 15. Возник вопрос - насколько долго можно жеё ждать? И дождемся ли? При select_sequential_consistency=0 запись видна на всех репликах, появляется в течении секунд. В процессе в базу активно пишутся данные с выставленной настройкой insert_quorum=3. Если записать те же данные в режиме кворума - всек ок, запись появляеся сразу же. Появилось ощущение, что при использовании select_sequential_consistency вся запись должна быть исключительно кворумной... 2. Пишем данные в базу с настройкой insert_quorum=3 в один поток. Запускаем параллельно второй такой же поток, через некоторое время один из них вываливается с эксепшном, общий смысл "Другая кворумная запись только что стартовала". Получается, что кворумные записи в принципе не распараллеливаются, или мы что-то делаем неправильно?

> Привет всем! Как то тут пусто, неужели телеграм таки заблокировали? Или просто выходные? просто КХ не тормозит, вот и вопросов нет ?

1. При включенной настройке select_sequential_consistency, из таблицы читаются данные до последнего куска, записанного с кворумом, включительно. Более новые записи - те, что были записаны без кворума, а также те, которые записываются с включенным кворумом, но когда кворум ещё не достугнут - не видны. 2. Да, получается что не распараллеливается. От пользователей есть фич-реквест - сделать "расслабленную" кворумную запись: каждый INSERT подтверждается только когда записан с кворумом, но не обязательно на реплики, содержащие все предыдущие записи. Если так сделать, то будет распараллеливаться.

Спасибо!

Добрый день. Подскажите, можно ли поменять ключ шардирования в таблице с движком Distributed, расположенной на нескольких шардах по две реплики каждый? Если да, то что будет с чтением уже имеющихся данных?

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

чтение останетсят точно таким же

Спасибо.

Алексей (@milovidov_an), не подскажите. В текущей версии группировка по таблице CollapsingMergeTree с модификатором FINAL требует неожиданно много памяти несмотря на настройки. Видимо делает группировку полностью в памяти. Раньше в этом замечен не был. Это временные трудности, или теперь это стандартное поведение?

Бага в русской документации Если искать PREWHERE - то ничего не находится, если разбить пробелом - то виден раздел PREWHERE Если ввести только PREWHER то раздел находится В английской - работает

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

отдетачить, скопировать файлы и потом приаттачить?

я юзаю такой скрипт: бэкап - select * from TableName INTO OUTFILE 'backup.chdb' format Native рестор - cat backup.chdb |clickhouse-client —query="INSERT INTO TableName FORMAT Native"

я юзаю такой скрипт: бэкап - select * from TableName INTO OUTFILE 'backup.chdb' format Native рестор - cat backup.chdb |clickhouse-client —query="INSERT INTO TableName FORMAT Native"

это очень долго

а уровнем повыше? на сервере Б уже будет идти запись в эту таблицу. Раньше пользовался "SELECT * FROM $i FORMAT Native" | INSERT INTO $i FORMAT Native. Но очень долго

а уровнем повыше? на сервере Б уже будет идти запись в эту таблицу. Раньше пользовался "SELECT * FROM $i FORMAT Native" | INSERT INTO $i FORMAT Native. Но очень долго

не очень понятно зачем вам такие вещи делать , есть же реплика и все такое

Реплика да.. тут была бы в тему

но нужен зоотехник, и вообще страшно

это очень долго

зато полный контроль :) в моем случае подошло

Зачем сразу зоотехник? https://clickhouse.yandex/docs/en/operations/tips/#zookeeper - вполне рабочий конфиг

Зачем сразу зоотехник? https://clickhouse.yandex/docs/en/operations/tips/#zookeeper - вполне рабочий конфиг

это я перевёл слово "zookeeper"

это я перевёл слово "zookeeper"

Работник зоопарка!

это я перевёл слово "zookeeper"

зукипер не так сложен чтобы жить без него

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

standalone сервер КХ сложно в реплицируемый преобразовать?

в доке есть описание как мерджтри в репликейтед переделать вроде

как быстро получить последнюю по дате запись? колонка с датой используется как разделитель партиций

order by date desc limit 1

немного странный вопрос, а может кто-то уже написал свой скрипт, который автоматически эмулирует retention? У меня подневные партиции и нужно дропать все, что старше Х дней.

order by date desc limit 1

Max(Field) гораздо быстрее срабатывает

немного странный вопрос, а может кто-то уже написал свой скрипт, который автоматически эмулирует retention? У меня подневные партиции и нужно дропать все, что старше Х дней.

https://github.com/ClickHouse-Ninja/clickhouse-partition-cleaner но он с дневными партициями должен криво работать из-за экранирования дат, надо будет поправить

Max(Field) гораздо быстрее срабатывает

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

@kshvakov ооо, круть!

спасибо :) идея ясна!

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

тогда вот такой вариант SELECT * FROM Table PREWHERE Date = ( SELECT Max(Date) AS Last FROM Table ) LIMIT 1

тогда вот такой вариант SELECT * FROM Table PREWHERE Date = ( SELECT Max(Date) AS Last FROM Table ) LIMIT 1

Да, такое должно быть быстрее. А почему здесь prewhere а не where ?

Да, такое должно быть быстрее. А почему здесь prewhere а не where ?

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

из справки: "Например, полезно писать PREWHERE для запросов, которые вынимают много столбцов, но в которых фильтрация производится лишь по нескольким столбцам."

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

а по date по идее index же

День добрый ! Есть 2 ноды КХ, есть локальная табличка (большая). Заливаю данные в такую же, но реплицируемую табличку (измеены индексы). Скорость что-то не "кх-шная" (11.95 thousand rows/s). Какие ручки покрутить ?

День добрый ! Есть 2 ноды КХ, есть локальная табличка (большая). Заливаю данные в такую же, но реплицируемую табличку (измеены индексы). Скорость что-то не "кх-шная" (11.95 thousand rows/s). Какие ручки покрутить ?

Залить в нереплицируемую, сделать DETACH партициям -> переместить в detached реплицируемой и сделать ATTACH

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

Я полагаю, не должно быть проблемы с тем, что просаживаются IO, показатели более чем прекрасные

День добрый ! Есть 2 ноды КХ, есть локальная табличка (большая). Заливаю данные в такую же, но реплицируемую табличку (измеены индексы). Скорость что-то не "кх-шная" (11.95 thousand rows/s). Какие ручки покрутить ?

а как заливаете ?

inset into ... SELECT * FROM ... WHERE PARTITIONKEY < 'some-date'

По всем мониторилкам, сервер скучает

А кто нить использует КХ для большого количества запросов( более 100) в секунду на SELECT ? Часть из них читает по одним таблицам.

inset into ... SELECT * FROM ... WHERE PARTITIONKEY < 'some-date'

в нереплицируемую все бытсро ? Мб проблема в zookeeper е

Я полагаю, не должно быть проблемы с тем, что просаживаются IO, показатели более чем прекрасные

Вообще - да, есть такое, при подобных запросах почему-то есть деградация

А кто нить использует КХ для большого количества запросов( более 100) в секунду на SELECT ? Часть из них читает по одним таблицам.

У нас больше 100 в секунду, особых проблем нет

У нас больше 100 в секунду, особых проблем нет

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

Вообще - да, есть такое, при подобных запросах почему-то есть деградация

А при нормальных инсертах стоит ждать проблем ?

А при нормальных инсертах стоит ждать проблем ?

Нет, в реплицируемую чуть медленнее чем в обычную пишет

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

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

Нет, в реплицируемую чуть медленнее чем в обычную пишет

чуть медленнее - это вместо 1кк - 900к или 1кк - 10к ?

А то мало ли что

чуть медленнее - это вместо 1кк - 900к или 1кк - 10к ?

Нет, там тратиться время только на запись в Zookeeper (несколько записей на блок). Т.е. просадка не сильно зависит от объема данных, а только от частоты вставки. На 1 insert будет + сколько-то ms

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

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

Нет, там тратиться время только на запись в Zookeeper (несколько записей на блок). Т.е. просадка не сильно зависит от объема данных, а только от частоты вставки. На 1 insert будет + сколько-то ms

Я так понимаю, при этом, best practice будет вставка через buffer в replicated?

А кто в курсе, как insert into select работает? Не по одной же вставляет, в конце-концов ?

А то 100 млз за 2 часа - это как-то жёстко, особенно, если учесть под триллион записей в табличке