единственное, что вижу здесь из значительных отличий - явное указание бд в Distributed (vs ’’ в моем случае).

непонятно, почему так

Distributed таблице нужна бд, я почему-то думал что currentDatabase() раскроется в момент create и в моем случае будет dw, но я не уверен как работает currentDatabase, и не использовал.

похоже раскрывается в базу в которой создана distributed USE test CREATE TABLE dw.tableX on cluster replicated as test.tableX_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableX_',rand ()); select * from dw.tableX; DB::Exception: Table dw.tableX_ doesn't exist..

интересно с '' use test CREATE TABLE dw.tableX on cluster replicated as test.tableX_ ENGINE = Distributed (segmented_mirrored,'','tableX_',rand ()); select * from dw.tableX; ... 1 rows in set. Elapsed: 0.002 sec. use dw select * from dw.tableX; Received exception from server (version 18.12.17): Code: 60. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Table dw.tableX_ doesn't exist..

Боюсь что все это связано больше стем, что никто не думал (нет понимания того) как это должно работать в данной ситуации, если описать поведение то его можно поправить.

Можно на HL++ собраться и обговорить подобные штуки, ну и все что накопилось, и обсудить что хочется/чего не хватает и кто что может сделать.

@milovidov_an ^ я думаю можно организовать маленький "круглый стол" ? :)

мне кажется что проблема molo4ko абсолютно в другом: https://github.com/yandex/ClickHouse/issues/3253

Может быть оффтопик, но я сделал статью целиком благодаря ClickHouse: https://medium.com/@aleksey_80472/crypto-kitties-from-the-raise-to-inbreeding-4bed53600c26 и я сомневаюсь сделал ли я что то подобное без него

мне кажется что проблема molo4ko абсолютно в другом: https://github.com/yandex/ClickHouse/issues/3253

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

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

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

Да, я скорее о том, что это проявляется при прохождении этапа оптимизации, на котором мой случай ломается

в смысле после него

мое вот здесь: https://github.com/yandex/ClickHouse/blob/master/dbms/src/Interpreters/ExpressionAnalyzer.cpp#L226 то есть прямо в конструкторе, а #3235 - дальше

@milovidov_an ^ я думаю можно организовать маленький "круглый стол" ? :)

Обязательно. Выясню, в какой день будет мой доклад, и на другой день назначим митап (круглый стол).

Может быть оффтопик, но я сделал статью целиком благодаря ClickHouse: https://medium.com/@aleksey_80472/crypto-kitties-from-the-raise-to-inbreeding-4bed53600c26 и я сомневаюсь сделал ли я что то подобное без него

Не оффтоп... Довольно интересно, почитаю на досуге. PS. Сейчас нажал Ctrl+R в браузере и не нашёл там упоминания ClickHouse.

Не оффтоп... Довольно интересно, почитаю на досуге. PS. Сейчас нажал Ctrl+R в браузере и не нашёл там упоминания ClickHouse.

да это упущение исправлю

Про Яндекс-ядро действительно устарело (оно почему-то не обновляется). Сейчас уберём.

Спасибо. А про mdadm вместо LVM актуально?

Спасибо. А про mdadm вместо LVM актуально?

Уже давно используем на серверах mdadm без LVM. Один раз были подозрения на старом сервере, что mdadm поверх LVM разделов может приводить к деградации производительности. Но мы это не подтвердили и не опровергнули. То есть получается, что совет не серьёзный (на уровне народной приметы).

Единственное - не нужно делать RAID лишь средствами LVM, так как он хуже, чем mdadm (там есть какая-то ограниченная возможность делать RAID-ы).

Уже давно используем на серверах mdadm без LVM. Один раз были подозрения на старом сервере, что mdadm поверх LVM разделов может приводить к деградации производительности. Но мы это не подтвердили и не опровергнули. То есть получается, что совет не серьёзный (на уровне народной приметы).

Или там наоборот был LVM поверх RAID - уже не помню.

А почему не физические контроллеры для рейдов?

У нас их нет.

С финансовой точки зрения не имеет смысла? Или исторически?

Просто мало смысла (или вообще нет смысла). Впрочем я не могу на 100% сказать про мотивацию.

Спасибо

'Code: 164, e.displayText() = DB::Exception: Cannot execute query in readonly mode, e.what() = DB::Exception\n’ Ловится при отправке запроса на Insert через HTTP-интерфейс Sqlalchemy дает ConnectionError со временем

Кто-нибудь может поделиться секретом вставок на питоне?)

'Code: 164, e.displayText() = DB::Exception: Cannot execute query in readonly mode, e.what() = DB::Exception\n’ Ловится при отправке запроса на Insert через HTTP-интерфейс Sqlalchemy дает ConnectionError со временем

инсерт можно только POST, у вас похоже через GET

Этот драйвер использует Native интерфейс, передающий на сервер готовые данные для вставки, разложенные по столбцам и сжатые. Что конечно очень круто и эффективно :) Но из-за этого получается так, что если в запросе INSERT присутствуют выражения (а не просто готовые значения), то их надо сначала выполнить, на клиенте. И если клиент не содержит в себе маленький ClickHouse, то он не может это сделать.

Я кстати пробовал передавать без UUIDStringToNum, не выходит

инсерт можно только POST, у вас похоже через GET

сейчас попробую

инсерт можно только POST, у вас похоже через GET

Храни вас Аллах, заработало!

ConnectionError: ('Connection aborted.', BrokenPipeError(32, 'Broken pipe’))

И снова

С финансовой точки зрения не имеет смысла? Или исторически?

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

Софтовыми рейдами

Привет, я правильно понял, что для репликации данных, нужно на серверах указать в конфиге хост с ZooKeeper, и создать таблицы из семейства Replicated с одинаковым путем в ZooKeeper и все ?

С разными путями а так всё верно

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

С разными путями а так всё верно

имя узла для таблиц и путь все разное ?

Кстати, еще вопрос про ZooKeeper. Сейчас у нас 2 ноды КХ и на них же 2 ZooKeeper + еще на одном левом сервер zookeeper и работает все достаточно плохо. Сейчас переделываем архитектуру, будет 3 ноды КХ на них же 3 зукипера. + 2 зукипера на соседних серверах. Стоит ли так делать? или лучше взять 3 мега слабых сервера под зукипер, зато без соседей? как мы поняли, SSD ему обязатален.

вообще не стоит ставить ZooKeeper на серваки с КХ

имя узла для таблиц и путь все разное ?

Что такое имя узла для таблицы, ЗК это файловая система по сути и вроде как там нет такого понятия как имя узла

вообще не стоит ставить ZooKeeper на серваки с КХ

почему?

В ReplicatedMergeTree 2 параметр

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

но их будет 3 + 2 резевных на мощных серверах(но там беки проектов)

В ReplicatedMergeTree 2 параметр

Шард должен быть одинаковый имя реплики разными

но их будет 3 + 2 резевных на мощных серверах(но там беки проектов)

Ну три сдохнут и вы получите чудеса

Разделите по виртуалкам

Не следует запускать ZooKeeper на тех же серверах, что и ClickHouse. Потому что ZooKeeper чувствителен к latency, тогда как ClickHouse легко может нагрузить все ресурсы сервера.

Шард должен быть одинаковый имя реплики разными

Спасибо ✌️

Разделите по виртуалкам

SSD очень критично на них? Мы сейчас видим, что ЗК на HDD сильно отстают от тех, что на SSD… или если все будут на HDD - не будет разницы?

SSD очень критично на них? Мы сейчас видим, что ЗК на HDD сильно отстают от тех, что на SSD… или если все будут на HDD - не будет разницы?

Они же все в памяти держат, как они могут отставать?

Раз уж настал вечер вопросов, я тоже задам - кто сравнивал производительность кликхауса в кластере на SSD и HDD - какие выводы можно сделать?

На нашей нагрузке и данных хдд хватает с головой

В целом при пике кх утилизирует 150-200мб в секунду что в целом потолок для хдд

Просто если данных много там разница в цене чуть ли не на порядок

Они же все в памяти держат, как они могут отставать?

у нас 2 ЗК на HHD, один на SSD, и те что HDD постоянно отстают. Как мы поняли, ЗК для сохранности данных скидывает все на диск

КХ справляется с записью на HDD с большим запасом

у нас 2 ЗК на HHD, один на SSD, и те что HDD постоянно отстают. Как мы поняли, ЗК для сохранности данных скидывает все на диск

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

но их будет 3 + 2 резевных на мощных серверах(но там беки проектов)

у ZK всегда используются все ноды, кластер ZK работает со скоростью самого медленного zk. Чем больше нод в ансамбле тем больше тормоза. Поэтому у яндекса 3 ноды в zk на полтыщи КХ.

SSD очень критично на них? Мы сейчас видим, что ЗК на HDD сильно отстают от тех, что на SSD… или если все будут на HDD - не будет разницы?

Подтюньте периодичность снепшотов в зоо. Он будет сильно меньше писать

SSD очень критично на них? Мы сейчас видим, что ЗК на HDD сильно отстают от тех, что на SSD… или если все будут на HDD - не будет разницы?

ОЧЕНЬ. SSD the must. ZK пишет на диск все транзакции.

ОЧЕНЬ. SSD the must. ZK пишет на диск все транзакции.

Все таки на производительность в памяти оно не влияет, и аппенд записи вроде там нет только дампы

Все таки на производительность в памяти оно не влияет, и аппенд записи вроде там нет только дампы

+1

ЗК подтверждает транзакцию только если был fsync лога на диск.

короче SSD на 3х серверах не связанных с КХ=(

что никто не видел ZK fsync warning ? fsync.warningthresholdms A warning message will be output to the log whenever an fsync in the Transactional Log (WAL) takes longer than this value. The values is specified in milliseconds and defaults to 1000. This value can only be set as a system property.

Да, я видел :) Чуть подробнее - ЗК хранит свои данные на диске в виде WAL + снапшотов. Чтобы подтвердить транзакцию, она сначала должна оказаться на диске записанной в WAL. А снапшоты делаются периодически, чтобы можно было удалять старый WAL. И их конечно лучше делать не слишком часто, чтобы ЗК сам себе не мешал.

Но и не слишком редко, а то проигрывание WAL-а при рестарте будет долго занимать :)

Да, я видел :) Чуть подробнее - ЗК хранит свои данные на диске в виде WAL + снапшотов. Чтобы подтвердить транзакцию, она сначала должна оказаться на диске записанной в WAL. А снапшоты делаются периодически, чтобы можно было удалять старый WAL. И их конечно лучше делать не слишком часто, чтобы ЗК сам себе не мешал.

В Яндексе зукипер стоит на SSD?

В Яндексе зукипер стоит на SSD?

В Метрике да

В Метрике да

Спасибо

Раз уж настал вечер вопросов, я тоже задам - кто сравнивал производительность кликхауса в кластере на SSD и HDD - какие выводы можно сделать?

Сравнивал, небольшая разница. Это если в общем

Правильные mat-views решают все (в моей задаче)

Подскажите пожалуйста, почему ClickHouse считает, что следующий запрос не верен? :) SELECT toDateTime('2018-01-01T00:00:00') < toDate('2019-01-01');

А логи и ошибки какие?

вообще-то работает, и в 18.14.0 и в 1.1.54394 но исторически у КХ строгая типизация

Не верен в смысле возвращает поль, сорян.

баг может, SELECT toDateTime('2018-01-01 00:00:00') < toDateTime(toDate('2019-01-01')) ┌─less(toDateTime('2018-01-01 00:00:00'), toDateTime(toDate('2019-01-01')))─┐ │ 1 │

Ага. Собственно в этом вопрос.

что происходит понятно SELECT toDateTime('1970-01-01 03:00:08') = toDate('1970-01-09') AS z ┌─z─┐ │ 1 │ └───┘

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

Подскажите пожалуйста, почему ClickHouse считает, что следующий запрос не верен? :) SELECT toDateTime('2018-01-01T00:00:00') < toDate('2019-01-01');

Это известное некорректное поведение, и у нас есть задача на исправление.

Доброе утро! Вопрос про DELETE/UPDATE и MaterializedView типа MergeTree: Если я выполняю delete/update на исходной таблице, то меняются ли данные во вьюхе? Например, если имеется вьюха с движком AggregatingMerge и там есть колонка uniqState(id) as uniqIds, я выполняю Delete над исходной таблицей, удаляя половину уникальных id, то значение в колонке uniqIds уменьшится в два раза?

Доброе утро! Вопрос про DELETE/UPDATE и MaterializedView типа MergeTree: Если я выполняю delete/update на исходной таблице, то меняются ли данные во вьюхе? Например, если имеется вьюха с движком AggregatingMerge и там есть колонка uniqState(id) as uniqIds, я выполняю Delete над исходной таблицей, удаляя половину уникальных id, то значение в колонке uniqIds уменьшится в два раза?

нет

Ок. Спасибо

Всем привет! Делаю запрос SELECT 1 format JSON; получаю ошибку Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 17: JSON FORMAT TabSeparatedWithNamesAndTypes;. Expected identifier, e.what() = DB::Exception Подскажите, плз, что я делаю не так

Всем привет! Делаю запрос SELECT 1 format JSON; получаю ошибку Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 17: JSON FORMAT TabSeparatedWithNamesAndTypes;. Expected identifier, e.what() = DB::Exception Подскажите, плз, что я делаю не так

Какой коннектор?

jdbc

Jdbc сам добавляет формат

т.е. его конфигурить как-то надо?

или не получится json вытащить?