как на ютубчике

Поздравляю с 300 участниками :) Кстати, никто не знает, как вывести дамп группы на какую-нибудь страничку, чтобы находилось поисковиками?

есть tg-cli и скрипт на руби https://github.com/tvdstaaij/telegram-history-dump, который позволяет сделать дамп в json

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

есть tg-cli и скрипт на руби https://github.com/tvdstaaij/telegram-history-dump, который позволяет сделать дамп в json

А сервис, чтобы это постоянно обновлял и выводил на сайте есть?

не знаю :(

ORDER BY pk_prefix LIMIT не учитывает индекс. Мог бы учитывать, но это требует немного другой организации параллельной обработки запроса. Поэтому сейчас сканирует весь кусок. Впрочем, ORDER BY с LIMIT-ом хотя бы работает за O(LIMIT) оперативки. То есть, не требует полной сортировки.

кстати, из любопытства - а можно как-нибудь добиться обратного эффекта?) чтобы SELECT rand(), rand(); возвращал разные числа

SELECT rand(1), rand(2) Это отражено в документации.

блин, пардон :О

А сервис, чтобы это постоянно обновлял и выводил на сайте есть?

Конечно можно написать скрипт, который будет это выкладывать прямо на https://clickhouse.yandex/

Конечно можно написать скрипт, который будет это выкладывать прямо на https://clickhouse.yandex/

вот как раз хотел скрипт предложить, потому что этот telegram-history-dump умеет в html экспортировать можно в крон запихнуть ))

занес https://github.com/yandex/ClickHouse/issues/322

ORDER BY pk_prefix LIMIT не учитывает индекс. Мог бы учитывать, но это требует немного другой организации параллельной обработки запроса. Поэтому сейчас сканирует весь кусок. Впрочем, ORDER BY с LIMIT-ом хотя бы работает за O(LIMIT) оперативки. То есть, не требует полной сортировки.

limit тут сделан только для ручного удобства. ORDER BY pk_prefix без лимита будет индекс учитывать?

Не будет. Будет сортировать.

Не будет. Будет сортировать.

А как можно воспользоваться тем что данные по индексу уже упорядочены в файлах и играет ли индекс какую то роль в оптимизациях (т.е. есть вообще смысл думать что в индекс включать или можно просто дату оставить для разбивания на кусочки)?

Конечно влияет. Индекс очень важен. Он используется для выбора диапазонов для чтения по условию в WHERE.

да, это я уже сам понял. Что-то мозг ночью ступил. Спасибо.

а можно сделать чтобы при неавторизованном запросе выдавался заголовок: WWW-Authenticate: Basic realm="need password" ? Это нужно чтобы можно было писать/смотреть запросы прямо в браузере. Они видимо по умолчанию игнорируют форму http://user:password@server и отправляют запрос без авторизации и я получаю ответ сервера: Code: 194, e.displayText() = DB::Exception: Password required for user default, e.what() = DB::Exception а если к этому добавить заголовок требования авторизации думаю браузер уже спросит пароль и дальше будет отправлять запрос с передачей пароля.

Можно. И реализовать легко. Добавите сюда? https://github.com/yandex/ClickHouse/issues или у вас нет аккаунта?

есть, добавлю

а сделать так чтобы в параметрах url параметры принимались для readonly пользователей? те же логин, пароль (чтобы интерфейс smi2 например работал), http_compress и возможно что-то еще, что имеет отношение к сессии и никак не затрагивает данные на сервере?

@bobsmit Значение параметра readonly=2 должно помочь.

@bobsmit Значение параметра readonly=2 должно помочь.

спасибо, вроде то то надо. Хорошо бы еще в документацию его. Документацией как я понял в основном Игорь @iamigor занимается?

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

> Документацией как я понял в основном Игорь @iamigor занимается? в свободное время и если желание есть )

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

ну, можно пользователей разделить на тех, кто не будет поднимать лимиты оперативки и получит клёвую веб-морду и тех, кто любит ломать и останется без прав и интерфейса и в supervisor какой-нибудь обернуть, который будет поднимать упавший процесс КХшного сервера, если что

результаты агрегатной функции с format JSON возвращаются как строка: {"sum(changed)": "3"}. открывать issue или уже известно?

результаты агрегатной функции с format JSON возвращаются как строка: {"sum(changed)": "3"}. открывать issue или уже известно?

UInt64?

и output_format_json_quote_64bit_integers, если да

UInt64?

да

это сделано специально, чтобы js/perl-люди, которые не в курсе что такое 64-разрядные целые, не затирали себе последние 3-4 цифры, когда парсят этот json.

понял, спасибо.

Всем привет. Решили попробовать CH, за неимением драйвера для Go пришлось накидать свой, поэтому присоединяюсь к просьбам об описании нативного протокола работы с сервером по tcp, помимо уже сказанного очень не хватает что-то вроде prepare / execute т.к. пихать параметры в сам запрос (select) как-то не очень хорошо

Чем не устраивает http? Jdbc драйвер например отлично работает по верх http

сессии

а свой это через cgo?

Всем привет. Решили попробовать CH, за неимением драйвера для Go пришлось накидать свой, поэтому присоединяюсь к просьбам об описании нативного протокола работы с сервером по tcp, помимо уже сказанного очень не хватает что-то вроде prepare / execute т.к. пихать параметры в сам запрос (select) как-то не очень хорошо

а почему нехорошо? о_О

не совсем понял про cgo ?

Всем привет. Решили попробовать CH, за неимением драйвера для Go пришлось накидать свой, поэтому присоединяюсь к просьбам об описании нативного протокола работы с сервером по tcp, помимо уже сказанного очень не хватает что-то вроде prepare / execute т.к. пихать параметры в сам запрос (select) как-то не очень хорошо

В документации есть ссылка на драйвер на Go.

https://github.com/roistat/go-clickhouse/

этот, видимо

он не совместим с database/sql

https://github.com/kshvakov/clickhouse

не совсем понял про cgo ?

ну в CH есть же клиентская либа на ++, в теории поверх нее можно наваять С интерфейс и заюзать из ГО, но это скорее вызовет больше геморроя.

ну в CH есть же клиентская либа на ++, в теории поверх нее можно наваять С интерфейс и заюзать из ГО, но это скорее вызовет больше геморроя.

именно так, написать на чистом го не большая проблема

по спецификации line protocol сделать будет проще

или там требуется обработка сообщений от сервера?

и переключение между нодами?

Уже известна дата следующего митапа?

Пока точной даты нет. Ориентировочно - середина февраля.

А в дс2 так и не собирались?

Киев?)

Питер же

Я понимаю что такакое дс2 :) Вопрос подразумевался как "А в киев не собираетесь?"

Собирались и то, и другое. Как раз решаем. Надеюсь, скоро будет анонс.

Ждем

за Киев +1!

За Киев +2!

Давно митапов небыло в Киеве от Яндекса

https://telegram.me/clickhouse_en

а синтаксис JOIN session ON session.id == view.session_id в ближайшее время не планируется случайно? а то грустно делать через подзапрос только ради алиаса одного столбца :(

хм, хотя он вроде уже поддерживается, но я не понял, как он работает :( SELECT id, session_id FROM view ANY LEFT JOIN session ON id = session_id PREWHERE date = today() LIMIT 10; такой ругается на Unknown JOIN variant

так USING же?

а столбец можно через AS переименовать

так я так и делаю, просто лаконичнее хотелось бы :)

например select id as view_id, session_id as id ANY LEFT JOIN session ...

ааа

вариант, кстати, да, спасибо, запутаннее немного кажется, потому что основной селект по view делается, а столбец id внезапно уже сессионный айди содержит

но да, спасибо!

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

т.е. чтобы в разных таблицах столбцы обозначающие одно и то же всегда назывались одинаковым образом.

другие запросы правда менее красивыми получатся: SELECT session_id, session_name from session...

угу, тоже думали об этом

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

Здравствуйте. Этот чат как альтернатива гугл-группе или для более мелких вопросов? Имеет смысл сюда продублировать недавние вопросы?

Для более мелких, да

И для более живого общения

Дублировать не стоит

Ок, спасибо

Если ли у кого информация, когда появится функционал аля arrayConcat? О том, что он планируется к реализации, ранее писали тут: https://groups.google.com/forum/#!searchin/clickhouse/arrayConcat%7Csort:relevance/clickhouse/M76tQkluzqE/B7vK0331BAAJ

/stat@combot