Нельзя приоритизировать потоки запросов, утилизируя полосу по полной

Не эффективная упаковка данных

Отсутсвие строгой типизации в запросах --> ошибки приведения типов

Прогресс - аргумент. С потоками аргумент не понял. Оверхед есть, это правда. Упаковка данных непонятно где страдает, в теле передаются бинарные данные. Строгая типизация в запросах очевидно есть, это не зависит от протокола.

насчет типизации - может имеется в виду отправка данных например в формате json? там нельзя заюзать функции в значениях (toUInt64() какой-нибудь), но оно и не надо в таком случае, КХ сам приводит к нужному формату

json как-то не очень противоречит http.

справедливо, извините)

1)про потоки: Я не могу получать результат запроса частями (например, по 100 кортежей) и отдавать их клиенту не вычитав остальные триллионы записей? Я не могу сделать так, чтобы в рамках одного tcp-соединения мультиплексировались запросы разных клиентов? 2) Про бинарные данные - не понял. С каких пор HTTP 1.1 стал бинарным? 3) строгая типизация есть у парсера запросов, но не у аргументов http-запроса

а у clickhouse-client разве строгая типизация есть? > 2) Про бинарные данные - не понял. С каких пор HTTP 1.1 стал бинарным? тело ответа запросто может быть бинарным, если например http_compression=1 прокинуть

А СН валидирует JSON?

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

@iamigor компрессия в транспорте != бинарный протокол.

Раз уж зашел разговор про это все: если документация не врет и неверный запрос отдает 500, было бы очень круто поправить его на 400. Ну и на случай мажорных обновлений заверсионировать апишку (добавить /v1)

Вот, смотрю доку и в упор не вижу json-формата запросов. Ткните пожалуйста на пример.

JSONEachRow

если речь про данные для INSERT'а. https://clickhouse.yandex/reference_ru.html#JSONEachRow

SELECTы можно делать более громоздкими JSON и JSONCompact

Это про результат, а я про запрос

по-моему, хочется странного :) что такого ужасного в query string или теле обычного POST-запроса?

JSON запрос - это {"query": "SELECT 1"} или что-то другое?

JSON запрос - это {"query": "SELECT 1"} или что-то другое?

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

так строгая типизация на уровне схемы таблицы же

и это тоже никак не связано с http

по-моему, хочется странного :) что такого ужасного в query string или теле обычного POST-запроса?

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

если попытаться insertнуть в таблицу с полем string String JSON формата {"string": 123}, то сервер отдаст ошибку и потребует обернуть 123 в кавычки

Ну т.е сначала нужно закачать весь json на сервер, а потом получить отлуп? А если он большой? Правильно - сломаться на клиенте.

так если речь о запросе, это же зачастую что-то не очень громоздкое, ну 16 КБ текста.

а, я понял

Речь о запросе. (Запросы бывают батчевые и их бывает много) Ответ - тема отдельного разговора.(там свои приколы с приведением типов обратно в разных ЯП)

1) про потоки: можно получать результат запроса частями. Мы так делаем. Да, поверх http. В рамках одного соединения запросы разных клиентов: нет, и дело не в протоколе. 2) HTTP позволяет передавать в теле любые данные, не вижу тут никакой проблемы. Картинки же как-то передаются по HTTP, правда ведь? 3) строгая типизация есть у парсера запросов, именно так. Если отослать неправильный запрос, не важно, насколько он неправильный. Вы отсылаете много неправильных запросов или что?

В-общем, непонятно.

У нас много запросов и они батчевые

И у нас нет проблем с HTTP

Запрос это в любом случае строка, это SQL

Какая разница как её передавать

1)дело не в логическом соединении с БД(там понятно, что дело не в http), а в транспорте. Я переживаю за сокеты и мне кажется не оптимальным держать большое количество открытых соединений. (Можно написать мультиплексирующий прокси, а можно все убрать в клиента) 2)Бинарные данные по http передаются крайне не оптимальным способом. Все рано, я не очень понял, как в СН хотят бинарные запросы по http. Ткните в пример, пожалуйста.

И у нас нет проблем с HTTP

Понятно. А у нас есть проблемы с http-транспортом и оверхедом на переупаковку json в протобуф

json в протобуф: причём тут кликхаус?

Смысл понятен. В конце концов, ClickHouse сам использует бинарный протокол без HTTP для межсерверного взаимодействия и не зря. Наружу доступен простой HTTP интерфейс, который подходит для большинства случаев. Хотя в некоторых случаях он, без сомнения, не оптимален.

json в протобуф: причём тут кликхаус?

При том, что возвращай СН структуры данных не сериализованные не самым быстродесериалмзуемым способом - было бы меньше оверхеда.

Ну так не запрашивайте json

Смысл понятен. В конце концов, ClickHouse сам использует бинарный протокол без HTTP для межсерверного взаимодействия и не зря. Наружу доступен простой HTTP интерфейс, который подходит для большинства случаев. Хотя в некоторых случаях он, без сомнения, не оптимален.

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

так она открыта, исходники есть же

в формате RowBinary в документации тоже немного написано

а передавать бинарные данные можно, например, так: ❯ echo -ne '\xff\x00\x00\x00\x06foobar' | curl "http://127.0.0.1:8123/?query=INSERT+INTO+test+FORMAT+RowBinary" -i -- в случае, когда таблица имеет структуру CREATE TABLE test (number UInt32, string String) ENGINE = Memory;

на выходе будет number == 255 и string == 'foobar'

но по-моему проще TSV, CSV и прочие JSONы :)

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

В принципе можно описать. Я правда немного боюсь. Периодически протокол меняем. Хотя при этом всегда есть совместимость в обе стороны. Но - всё-таки мне не хотелось бы, если совместимость придётся поддерживать вечно. Сейчас совместимость с очень старыми версиями всё-таки удаляется из кода: https://github.com/yandex/ClickHouse/commit/6f4fc79cde4b4da23ae834e4d39643c8a96cf768#diff-79777e228d054f50a7d555f3aafd30e4L66

кстати, а enable_http_compression=1 работает для данных в INSERT-запросах? ну, т.е., можно передавать сжатые gzip/defalte данные?

Да. Можно отправлять сжатые данные с заголовком Content-Encoding.

ага, спасибо!

Ну вот RowBinary возможно и хватит. Дело не в том, чтобы открыть, а в том чтобы можно быто быть уверенным что API этого протокола не поменяется без изменения мажорной версии, а минорные версии останутся бексовместимыми. Остальное итак можно взять из исходников.

так это.. а ничего, что формат TabSeparated/CSV в моем примере получается компактнее, чем RowBInary? :D ❯ echo -ne '\xff\x00\x00\x00\x06foobar' | wc -c 11 ❯ echo -ne '255,foobar' | wc -c 10 это в случае двух полей - UInt32 и String мне кажется, экономия на спичках может получиться, но я ненастоящий сварщик, заранее извините

В принципе можно описать. Я правда немного боюсь. Периодически протокол меняем. Хотя при этом всегда есть совместимость в обе стороны. Но - всё-таки мне не хотелось бы, если совместимость придётся поддерживать вечно. Сейчас совместимость с очень старыми версиями всё-таки удаляется из кода: https://github.com/yandex/ClickHouse/commit/6f4fc79cde4b4da23ae834e4d39643c8a96cf768#diff-79777e228d054f50a7d555f3aafd30e4L66

Изменения - это не проблема, если они отражаются в версиях. Если есть возможность описать - было бы здорово. Нет - тоже не беда.

Сейчас у нас совместимость между версиями в окне времени где-то около пары лет. При апгрейде на новую версию совместимость есть всегда. То есть, мы не выпускаем несовместимые мажорные версии.

Ок, тогда покопаем исходники нативного протокола.

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

мы вот свой скоро заопенсорсим на scala

опять же, если много надо засылать - проще сжимать данные

Ок, тогда покопаем исходники нативного протокола.

держите ссылочки :) https://github.com/yandex/ClickHouse/blob/master/dbms/include/DB/Core/Protocol.h#L9 https://github.com/artpaul/clickhouse-cpp

мы вот свой скоро заопенсорсим на scala

??

я попытался на прошлой неделе использовать CH в качестве бекэнда для другого open-source проекта, который на java. interop scala-java конечно есть, но код на java выглядит страшненьким.

А для Scala разве неудобно пользоваться готовым JDBC драйвером?

ну решили повелосипедить)

jdbc драйвер я использую в zeppeline, так что тоже хорошо

а внутри jdbc вроде же тот же http клиент с json?

Да. Правда я не помню, там JSONCompact или TSV. Для INSERT вроде бы TSV.

ага, query += "&query=" + sql + " FORMAT TabSeparated";

про неудобство http - мне лично неудобно отсутствие сессий и как следствие - невозможность использования временных таблиц (с их прибиванием со стороны сервера).

а Memory или Buffer не подходят?

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

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

там тоже проблема с таймаутами - если поставить прибивать таблицы старше 2-3 минут они могут прибиться ее в процессе запроса. Если несколько часов - много памяти занимать.

Кроме того нужно создавать уникальные имена таблиц для каждого процесса. В целом это не сложно, но вместо "CREATE TEMPORARY TABLE tmp ..." нужно писать что-то вроде CREATE TABLE tmp_" + tmpSuffix + " ...". И писать и читать это не очень удобно.

еще как обходной путь - можно попробовать писать дофига подзапросов и всё через них делать, но снова читабельность будет страдать.

Сейчас у нас совместимость между версиями в окне времени где-то около пары лет. При апгрейде на новую версию совместимость есть всегда. То есть, мы не выпускаем несовместимые мажорные версии.

кстати, а сервер как-нибудь принимает во внимание версию, которую сообщает клиент? полагаю, всё может сломаться, если начать передавать что-нибудь типа v0.2.345? )) upd: собственно да, сервер не отвечает на hello, если revision сильно отличается от текущего

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

если вы через http работаете, запросы же какое-то приложение или скрипт должно делать? может, хоть на его стороне сделать создание таблицы? я так реализовал, вроде норм, но у меня масштабы не очень большие, наверное :(

да понятно что через приложение и что можно сделать. Но это всё равно нужно помнить, всё равно имена таблиц генерировать и т.п. с временными было бы гораздо удобнее.

окок, извините :(

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

потому что память конфилось или место

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

ни у кого случайно нет хотя бы приблизительного чейнджлога сервера с 1.1.54083 по 1.1.54127 (стабильные)?

Игорь, можно по коммитам посмотреть: https://github.com/yandex/ClickHouse/compare/v1.1.54083-testing...v1.1.54127-stable

там пишут что изменений много, только 250 коммитов показано. Но можно или локальным клиентом по истории или инкрементально посмотреть.

да по коммитам я и сам могу, и посмотрел уже бегло :)

Виктор. А сессия это хорошо, потому что соединение установил, таблиц временных понасоздавал для текущих запросов. Потом соединение закрыл, а временные таблицы сами грохнулись. + если в двух разных сессиях сделать CREATE TEMPORARY tmp ..., то это будут две разные таблицы tmp, т.е. не надо дополнительных генераторов для имени таблицы придумывать.

может имеет смысл хоть wiki включить на гитхабе? можно будет community-driven changelog сделать :)

Мне кажется больше имеет смысла changelog.txt или changelog.md, т.е. файлом. Сообществом может поддерживаться в виде пул-реквестов и в интерфейсе сразу видно и список изменений сразу правильный внутри версии и вспоминать что там вики есть не надо - изменения сразу в списке файлов видны.

fair enough

у меня вопрос по WITH TOTALS: https://clickhouse.yandex/reference_en.html#WITH TOTALS modifier здесь сказано что аггрегаты будут вычислены для всех строчек

можно ли сделать WITH TOTALS когда у меня есть 2 group by , и мне нужны totals после первого group by?

т.е. TOTALS внутри групп, как у olap-cubes?

всем привет! а в кликхаусе же можно в несколько реплик писать? оно потом разъедется?

писать можно. отреплицируется достаточно быстро(для нас секунды)

@f1yegor круто, спасибо!

Totals внутри первого group by получить не получится

а внутри произвольного?