Может у вас версия новее. У меня 1.1.54236

Сейчас стоит пересобирать на stable ? Или стоит подождать, так как там какое-то обновление с broken-pipe скоро будет?

SELECT number FROM ( SELECT * FROM system.numbers LIMIT 100000000 ) WHERE number IN ( SELECT arrayJoin(arrayMap(x -> cityHash64(x), ['AAABBB', 'BBBCCC', 'CCCDDD'])) ) Ok. 0 rows in set. Elapsed: 0.542 sec. Processed 100.01 million rows, 800.06 MB (184.60 million rows/s., 1.48 GB/s.) SELECT number FROM ( SELECT * FROM system.numbers LIMIT 100000000 ) WHERE number IN (9061446772526811008, 5491217007787768788, 7314285464923205752) Ok. 0 rows in set. Elapsed: 0.548 sec. Processed 100.01 million rows, 800.06 MB (182.46 million rows/s., 1.46 GB/s.)

SELECT number FROM ( SELECT * FROM system.numbers LIMIT 100000000 ) WHERE number IN ( SELECT arrayJoin(arrayMap(x -> cityHash64(x), ['AAABBB', 'BBBCCC', 'CCCDDD'])) ) Ok. 0 rows in set. Elapsed: 0.542 sec. Processed 100.01 million rows, 800.06 MB (184.60 million rows/s., 1.48 GB/s.) SELECT number FROM ( SELECT * FROM system.numbers LIMIT 100000000 ) WHERE number IN (9061446772526811008, 5491217007787768788, 7314285464923205752) Ok. 0 rows in set. Elapsed: 0.548 sec. Processed 100.01 million rows, 800.06 MB (182.46 million rows/s., 1.46 GB/s.)

Пажалуй обновлю testing

у меня тоже 1.1.54236

но причина скорее всего не в arrayJoin

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

Ну возможно, но я не вижу причины почему, так как там ничего хитрого нет.

Индекс по sym есть

(date,sym,time)

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

хитрого ничего нет, да

моя гипотеза - инлайн быстрее потому что по индексу, в отличие от select arrayJoin, который фуллскан.

Понял. Спасибо. Не понял только почему :)

потому что оптимизатор пока что недостаточно умен.

Ладно, я наверное вообще пойду поучусь вставлять данные в запрос. Может arrayjoin сам уйдет.

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

потому что оптимизатор пока что недостаточно умен.

Просто не понимаю если честно. В кбд нет оптимизатора. Все что тут делается - выполняется нормальный порядок вычисления: сначала подзапрос, потом запрос.

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

Хотел этого избежать.

Но я понял что оптимизатор что-то непонятное делает :) хотя по идее надо было просто вычислить в нормальной последовательности.

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

Такое ощущение, что любой sym in (select/функция...) отключает pk

Привет! ODBC драйвер для windows взлетел?

всем привет) смотрел удаленно недавнюю встречу про ClickHouse, там намекнули, что с джойнами дела обстоят не очень. может кто в курсе в чем именно косяк и как с ним бороться?

Могу ошибаться, но суть такая что нельзя написать так select * from t1 left join t2 on t2.id=t1.id

всем привет) смотрел удаленно недавнюю встречу про ClickHouse, там намекнули, что с джойнами дела обстоят не очень. может кто в курсе в чем именно косяк и как с ним бороться?

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

Всем привет! Подскажите пожалуйста следующий момент: в доке про ReplacingMergeTree есть предупреждение; "Слияние происходят в фоне, в неизвестный момент времени, на который вы не можете ориентироваться. Некоторая часть данных может так и остаться необработанной." Про CollapsingMergeTree такого замечания нет. Правильно ли я понимаю, что механизм слияния строк в обоих движках примерно идентичный и подобное замечание также актуально для CollapsingMergeTree?

Хм, там новый стейбл потегали. Кто знает что в нем нового?

всем привет. а кто нибудь писал NULL в rowbinary формате, как там правильно NULL строку писать? Из доков непонятно: https://clickhouse.yandex/docs/en/formats/rowbinary.html В JDBC коде от NULL значений все огорожено: public void writeString(String string) throws IOException { Preconditions.checkNotNull(string); writeUnsignedLeb128(string.length()); out.write(string.getBytes()); }

Всем привет! Подскажите пожалуйста следующий момент: в доке про ReplacingMergeTree есть предупреждение; "Слияние происходят в фоне, в неизвестный момент времени, на который вы не можете ориентироваться. Некоторая часть данных может так и остаться необработанной." Про CollapsingMergeTree такого замечания нет. Правильно ли я понимаю, что механизм слияния строк в обоих движках примерно идентичный и подобное замечание также актуально для CollapsingMergeTree?

Да.

всем привет. а кто нибудь писал NULL в rowbinary формате, как там правильно NULL строку писать? Из доков непонятно: https://clickhouse.yandex/docs/en/formats/rowbinary.html В JDBC коде от NULL значений все огорожено: public void writeString(String string) throws IOException { Preconditions.checkNotNull(string); writeUnsignedLeb128(string.length()); out.write(string.getBytes()); }

Сначала пишется один байт. 0, если не NULL, 1 если NULL. Если не NULL, далее пишется значение (также, как оно пишется в RowBinary для вложенного типа данных).

Хм, там новый стейбл потегали. Кто знает что в нем нового?

Полно всего нового - давно не было релизов. Расскажу в Минске на митапе...

Полно всего нового - давно не было релизов. Расскажу в Минске на митапе...

Эх, текстовый спойлер бы

темы интересные заявлены, повтор бы в москве потом :)

В Москве обязательно сделаем! Правда может быть уже осенью (хотя это пока не точно).

@milovidov_an вот прям очень бы хотелось хотя бы краткие чейнджлоги

@milovidov_an вот прям очень бы хотелось хотя бы краткие чейнджлоги

+1

@milovidov_an вот прям очень бы хотелось хотя бы краткие чейнджлоги

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

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

А вот хочется чтобы поддерживался :)

Наши желания не всегда совпадают с возможностями Яндекса. Я попробую по новому релизу написать что-то аналогичное https://www.altinity.com/blog/2017/5/22/clickhouse-release-notes

Сегодня попозже напишу сюда краткие release notes

Сегодня попозже напишу сюда краткие release notes

+++

Сегодня попозже напишу сюда краткие release notes

+++

Алексей, а в новый билд вошло <version_query> для словарей?

Да.

Также вошла возможность посмотреть словари в виде таблицы.

Сегодня попозже напишу сюда краткие release notes

Это было бы просто замечательно! :)

Отлично

заканчивается место, нашел в директории Distributed-таблицы 400Gb данных и 350 тысяч файлов ? это нормально?

mergetree таблица, куда пишет Distributed, 1 Tb

А пишете в Distributed?

Sorry, we had to truncate this directory to 1,000 files. 20 entries were omitted from the list.

в тестах

да, все файлы в папке default\@шард\:9000, и все от 9 июня, я помню что была какая-то хрень при рестарте кликхаусов

как думаете, дропнуть может папочку тогда? :)

Если я не ошибаюсь, то это данные которые должны улететь на другой шард

У вас в логах нет случаем ошибки broken pipe?

Шарды никакие не выключали?

broken pipe много в логах

Всем привет! Кто-нибудь пробовал увеличивать значение max_bytes_to_merge_at_max_space_in_pool?

шарды рестартил вот тогда примерно, 9 июня, broken pipe до сих пор сыпется

broken pipe много в логах

ну это тогда те данные которые не улетели на тот шард. Мне помогал рестарт CH

что с этим делать хз

все воюю с реплицируемыми мат.вью. https://groups.google.com/forum/#!topic/clickhouse/7yEoT_cMyJ4 У всех нормально работают реплицируемые MV? Просто пока в тесте данных мало и очень хорошо видно разбежку в цифрах. Если вьюшку делать не реплицируемой, то все ок, цифры совпадают. Куда копать даже не знаю.

что с этим делать хз

попробуйте рестартовать тот шард на котором эти ошибки валятся. А вообще вроде как должна быть новая версия которая это фиксит

мне в таких случаях помогал рестарт того CH, где Distributed таблица создана... т.е. где bin файлы лежат...

вопрос, а в Grafana плагине для CH можно ли выводить array из uint32 просто списком?

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

вспомнил

О, в репах похоже новая версия появилась. 1.1.54198. Кто нибудь может сказать, в ней есть фикс с broken pipe?

это же вроде версия от 29 Mar, не?

1.1.54198 это старая версия. Новая это 1.1.54242

4 hours ago v1.1.54242-stable

Пакеты можете пробовать, фикс broken pipe там есть. Disclaimer - ещё не обкатаны у нас на продакшене.

вопрос, а в Grafana плагине для CH можно ли выводить array из uint32 просто списком?

Попробуйте преобразовать его в строку

ага, уже!)

сделал arrayMap(x=> IPv4NumToString(x), myarray)

Пакеты можете пробовать, фикс broken pipe там есть. Disclaimer - ещё не обкатаны у нас на продакшене.

А где их брать? В яндексовой deb репе только 1.1.54236

http://repo.yandex.ru/clickhouse/trusty/pool/main/c/clickhouse/

http://repo.yandex.ru/clickhouse/trusty/pool/main/c/clickhouse/

А, оно еще как stable не помечено, понял, спасибо.

а не менялись ли протоколы/взаимодействие с внешним миром? JDBC перестал работать после апгрейда, валится на любом запросе (включая select timezone()) с ошибкой ClickHouse exception, code: 27, host: 192.168.11.11, port: 8123; Code: 27, e.displayText() = DB::Exception: Cannot parse input: expected eof before: false

Проверил - на 1.1.54236 jdbc драйвер нормально работает

Имею ввиду вот эту версию 1.1.54242

https://github.com/yandex/ClickHouse/tree/v1.1.54242-stable

Откатился назад на 1.1.54236, JDBC работает. Просто я из jdbc выполняю какие то команды (то ли рейс drop table/create table, то ли кривой insert) которые стабильно рушат сервер в версии 1.1.54236. Я подумал что в 1.1.54242 это исправлено, но там JDBC не работает :)

в 236 версии есть фикс broken pipe?

в 236 версии есть фикс broken pipe?

нет

со своей проблемой разобрался. сегфолтилось вот поэтому ttps://github.com/yandex/ClickHouse/issues/875, то есть в 1.1.54242 пофикшено. Осталось понять почему JDBC в 1.1.54242 поломался :)