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

select * from hit where id = "x" and sign=1 ммм?

select * from hit where id = "x" order by updated_time desc

select * from hit where id = "x" and sign=1

W: Conflicting distribution: http://repo.yandex.ru/clickhouse/deb/stable main/ Release (expected main/ but got clickhouse stable)

Говорят, что ещё что-то поправили. Посмотрите, не исчез этот Warning?

такой запрос может парочку записей вернуть

Версия кх ?

Всем привет. Подскажите как бороться с такой багой: При использовании LIMIT N BY ... не дает использовать агрегацию на уровне выше. Пример: SELECT count() FROM (SELECT parent_id, count() as c, id, date FROM example WHERE date between today()-30 and today() GROUP BY id, parent_id, date ORDER BY date, parent_id, count() desc LIMIT 10 BY date, parent_id ) При этом, если заменить count() на *, то все работает. Ошибка: "Code: 10, e.displayText() = DB::Exception: Not found column date in block. There are only columns: parent_id, e.what() = DB::Exception"

1.1.54245

надо обновиться, поправили в одной из последних версий.

1.1.54245

Спасибо

Подскажите пожалуйста в какой версии появился mysql join ?

Если речь про движок таблиц MySQL, то в версии 54337: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%9D%D0%BE%D0%B2%D1%8B%D0%B5-%D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D0%B8-2

Кстати, добавили changelog для версии 54370: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#clickhouse-1154370-release-candidate-2018-03-16

Поясните, пожалуйста, что имеется ввиду: >Добавлена возможность создавать ALIAS-ы для множеств

/stat@combot

combot.org/chat/-1001080295593

/stat@combot

combot.org/chat/-1001080295593

Поясните, пожалуйста, что имеется ввиду: >Добавлена возможность создавать ALIAS-ы для множеств

Имеются в виду запросы типа

WITH (1, 2, 3) AS set SELECT number IN set FROM system.numbers LIMIT 10

WITH (1, 2, 3) AS set SELECT number IN set FROM system.numbers LIMIT 10

Здорово! Этого сильно не хватало.

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

W: Failed to fetch http://repo.yandex.ru/clickhouse/trusty/dists/stable/main/binary-amd64/Packages 404 Not Found [IP: 213.180.204.183 80] E: Some index files failed to download. They have been ignored, or old ones used instead.

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

Пин

а где я могу прочитать про это?

и что делать с теми у кого это забито в sources.list ?

В самом верху прилепленное сообщение. sources.list придется обновить

вижу ?

/stat@combot

combot.org/chat/-1001080295593

/stat@combot

combot.org/chat/-1001080295593

Приветствую

не подскажете как вот такую ошибку пофиксить

DB::Exception: Cannot allocate block number in ZooKeeper: zkutil::KeeperException: connection loss.

/stat@combot

combot.org/chat/-1001080295593

/stat@combot

combot.org/chat/-1001080295593

Подскажите пожалуйста такой момент. Есть движки CollapsingMergeTree и ReplacingMergeTree в каждой из них должно быть служебное поле (sign и ver соответственно). Эти значение нужно вручную вставлять? Или clickhouse каким-то хитрым образом расчехляет где данные старше ?

если вручную не вставлять, там нули образуются. Допустим если это ReplacingMergeTree то version последний не узнать никак, видимо придется timestamp вставлять.

Подскажите пожалуйста такой момент. Есть движки CollapsingMergeTree и ReplacingMergeTree в каждой из них должно быть служебное поле (sign и ver соответственно). Эти значение нужно вручную вставлять? Или clickhouse каким-то хитрым образом расчехляет где данные старше ?

вручную

Спасибо. А как поведет себя движок CollapsingMergeTree при одинаковых ключах и с одинаковым sign ?

Как увидеть статистику выполнения запроса ( Processed 32.77 thousand ...), если я запрос выполняю через cat file.sql|clickhouse-client ?

запрос очень длинный (55кб) в интерактивном режиме не очень удобно. Ну или как вызвать на выполнение файл в интерактивном режиме (типа ораклового @file.sql)?

clickhouse-client --progress

clickhouse-client --progress

ClickHouse client version 1.1.54292. Проматывается и затирается, и исчезает после окончания запроса.

добавить 2>&1 | tee logfile

внутри logfile будет каша, из которой можно узнать полезное

Утро доброе, есть табличка с движком mergeTree и ~32млн строк. Есть запрос такого рода SELECT a, b, c, d, e, ..., z FROM table_name WHERE city = 'city_name' AND (some_id, row_create_ts) IN ( SELECT some_id, max(row_create_ts) FROM table_name WHERE create_date > /*недалёкая дата, например '2018-18-03'*/ AND city = 'city_name' GROUP BY some_id) AND some_id in (/*перечислено около сотни строковых id*/) AND (a in (1, 2) OR b in (1, 2) OR c in (1, 2) OR d in (1, 2) OR ... z in (1, 2)) row_create_ts, some_id, city в индексах есть. Выполняется около 20 секунд, хотелось бы побыстрее :) Можно ли его как-то оптимизировать?

Утро доброе, есть табличка с движком mergeTree и ~32млн строк. Есть запрос такого рода SELECT a, b, c, d, e, ..., z FROM table_name WHERE city = 'city_name' AND (some_id, row_create_ts) IN ( SELECT some_id, max(row_create_ts) FROM table_name WHERE create_date > /*недалёкая дата, например '2018-18-03'*/ AND city = 'city_name' GROUP BY some_id) AND some_id in (/*перечислено около сотни строковых id*/) AND (a in (1, 2) OR b in (1, 2) OR c in (1, 2) OR d in (1, 2) OR ... z in (1, 2)) row_create_ts, some_id, city в индексах есть. Выполняется около 20 секунд, хотелось бы побыстрее :) Можно ли его как-то оптимизировать?

Укажите структуры таблицы. Ещё можно посмотреть стадии выполнения запроса в логе КХ и понять как из них самая долгая (это такая альтернатива EXPLAIN)

Укажите структуры таблицы. Ещё можно посмотреть стадии выполнения запроса в логе КХ и понять как из них самая долгая (это такая альтернатива EXPLAIN)

Доброе утро! Пожалуйста, прикрепите ссылку на документацию о там, как выполнять просмотр стадий выполнения запроса.

Доброе утро! Пожалуйста, прикрепите ссылку на документацию о там, как выполнять просмотр стадий выполнения запроса.

Только если смотреть лог КХ, как-то так tail -f /var/log/clickhouse/clickhouse-server.log Путь примерный, но в нем будут писаться стадии выполнения запроса в реалтайме

Только если смотреть лог КХ, как-то так tail -f /var/log/clickhouse/clickhouse-server.log Путь примерный, но в нем будут писаться стадии выполнения запроса в реалтайме

Спасибо!

Укажите структуры таблицы. Ещё можно посмотреть стадии выполнения запроса в логе КХ и понять как из них самая долгая (это такая альтернатива EXPLAIN)

Спасибо. Увидел, что запрос перебирает практически всю таблицу. Помогло банально вынести условие по create_date и во внешний запрос

Теперь справляется за ~0.5 сек)

Теперь справляется за ~0.5 сек)

Кстати можно написать create_date в обоих WHERE

дак так и сделал

добрый день! Подскажите, как корректно (и, желательно, быстро) сделать из обычной MergeTree -> ReplicatedMergeTree

Мне помнится следующий алгоритм: 1. Остановить сервер 2. Перенести файлы из /var/lib/clickhouse/data/dbname/ 3. Включить сервер 4. Дропнуть таблицу 5. Создать Replicated 6. Стопнуть сервер 7. Подсунуть обратно файлы 8. Завести сервер

Так?

можно наживую с detach и attach, или файлов много?

партиций

Довольно много

такую же таблу с ReplicatedMergeTree создать, в MergeTree detach partition, перенести файлы, и в ReplicatedMergeTree attach partition

clickhouse-client -n "detach; detach; detach; ..." :)

или -m ключ, не помню

Коллеги, внесите пожалуйста ясность в вопрос, представим что у нас 7Тб данных в ClickHouse, как рассчитать приемлемый объем ОЗУ? 1:1 сами понимаете - не вариант

Тут, скорее, от запросов зависит...

а насколько быстро like работает в кх?

а насколько быстро like работает в кх?

достаточно быстро)

у меня есть несколько полей например "автор" и "тема" мне надо если введут "иванов авария" вывести поле "иванов иван иванович" "авария на теплотрассе"

тоесть это наверно придется все слова что передадут искать во всех полях, в которых надо искать

Тут конечно лучше сфинкс

больше напоминает юзкейс elasticsearch

тоесть это наверно придется все слова что передадут искать во всех полях, в которых надо искать

Может предобработку делать? Классифицировать перед заливкой

у нас классифицировано

но например авария на трассе, и на теплотрассе

у нас по теме в разных разделах

и поиск должен быть не полнотекстовый

тоесть могут написать "ивано авари"

или это уже перебор

слишком сложно будет

select userid, max(date) from table where userid like ('%c0e-41f%') group by userid - занял 62 секунды на 13 млрд строк

а как будет справлятся кх если я вместе с циферками в кх сделаю большие текстовые поля

с json объектами

чтобы отдавать их целиком клиенту

каждый объект около 30 кб

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

Но по вашему описанию кажется что вам лучше в elastic