Кешируются ли вложенные запросы? Или кеш идет по всему запросу целиком?

Ничего не кешируется.

CH активно полагается на кэш файловой системы

Обычно, это работает хорошо, если данные запрашиваются близкие.

Для аналитического паттерна обычно кэширование по запросам бесполезно, так как запросы не повторяются.

О, статья на вики: https://en.wikipedia.org/wiki/ClickHouse

не знаю, меня очень порадовал (в плане производительности) INSERT INTO SELECT с фильтром только нужных данных

Только как-то страшно применять такой трюк для шардированых/реплицированных на много серверов таблиц

https://yadi.sk/i/fYaD8jjByPEir Что дает такой результат тогда?

Как раз кэш файловой системы

Ага, интересно

На count() работает очень эффективно потому что по сути данные не читаются, и это random access

Ну и разница между диском и памятью для random access понятно что очень большая

@milovidov_an я ведь прав?

Просто я как раз пишу запрос с count() для пагинации, и мне интересно как это правильно сделать

Только не тыкайте палками если я чтото неправильно спрашиваю, я не хайлоад, я только учусь

В смысле - для того чтобы написать сколько там ещё страниц листать можно?

Да

Советую посмотреть на rows_before_limit_at_least

https://clickhouse.yandex/reference_en.html#JSON

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

Получается, можно получить всю информацию за один запрос.

Круто, спасибо

На count() работает очень эффективно потому что по сути данные не читаются, и это random access

@zloool В таком случае если не ошибаюсь читается одна (самая маленькая) колонка. Поэтому в бенчамарке при увеличении количества строк время первого запроса увеличивается (хоть и не линейно). Но вторые и третие запросы уже вполняются в разы быстрее, а зависимость от числа строк становится более линейной, что говорит о том, что какой-то кэш работает. В кликхаусе для таких кейсов есть кэш разжатых блоков https://clickhouse.yandex/reference_ru.html#use_uncompressed_cache По-умолчанию он выключен, а даже если и включен, то старается использоваться для маленьких кусков данных. Не понятно какие настройки использовались в бенчмарке, но есть основания полагать, что тут она использовалась.

Спасибо

В бенчмарке не используется use_uncompressed_cache.

А как правильнее проверить столбец на NULLоподобность, и если он таковой, то подставить в данные что-нибудь другое? вот, например, моя попытка избавиться от "0000-00-00 00:00:00" и фигачить пустую строку: toUInt64(created_at) != 0 ? toString(created_at) : ''

я думаю вместо нула писать несуществующее или не имеющее логического смысла значение

типа -100

я думаю вместо нула писать несуществующее или не имеющее логического смысла значение

Isn't that the point of NULL?

yeah, but NULLs aren't supported for now

what about ASCII null character?

It is used in the FixedStrings

Игорь, не очень понял: хочется ткое в данных хранить или как?

Если тип данных это DateTime то лучше хранить именно 0000-00-00 00:00:00

хочется, наоборот, вывести SELECTом, экспортнуть в TSV, всё такое

что по сути является 0

А

Да, тогда ваш запрос вполне окей

да, знаю) просто запрос совсем страшным становится из-за таких выражений, а все лишь для того, чтобы в CSV было не "0000-00-00 00:00:00", а пустая строка

ОК, спасибо!

Проще пока что пути не вижу

Ну и не так уж страшно =)

это вы еще мой способ конвертить FixedString(16) в UUID не видели!

хотя, наверное, видели. ну да ладно

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

не представляю :)

machine learning формулы на sql например

как раз недавно натыкался на статью, как нейронную сеть на SQL писали

http://blog.itdxer.com/2016/07/01/neural-networs-in-mysql.html вот эта вроде. извините за оффтоп

Проще пока что пути не вижу

а планиурете добавить NULL или отказ был осознаным и ждать не стоит?

Планируется

Отказ был осознанным :)

Но необходимость понятна

отлично

Так что будут nullable типы и столбцы

Пулл реквест даже уже есть https://github.com/yandex/ClickHouse/pull/70

Пулл реквест даже уже есть https://github.com/yandex/ClickHouse/pull/70

lgtm

Они будут работать несколько медленней.

Так что только по необходимости

Если тип данных это DateTime то лучше хранить именно 0000-00-00 00:00:00

АААА, где вы берёте такое время?

его же нет, нет в мире года 0000

потом человеческие парсеры ломаются

:) select toDateTime(0) SELECT toDateTime(0) ┌───────toDateTime(0)─┐ │ 0000-00-00 00:00:00 │ └─────────────────────┘ 1 rows in set. Elapsed: 0.003 sec. :)

gis=> select to_timestamp(0); to_timestamp —---------------------- 1970-01-01 03:00:00+03 (1 row)

gis=> select to_timestamp(0); to_timestamp —---------------------- 1970-01-01 03:00:00+03 (1 row)

Кстати, прикольно, похоже и правда не сохранить чистый 1970-01-01 00:00:00, он будет нулями отображаться

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

это всё мелочи по сравнению со скоростью движения прогрессбара!

да, а я потом в постгресе fdw не могу сделать в базы, которые год 0000 изобрели :)

да мы с коллегами сейчас тоже не смогли, пришлось после FORMAT CSV еще sed -i -- 's/\"0000-00-00 00:00:00\"//g' натравливать

:'(

SELECT toYear(toDateTime(0)) ┌─toYear(toDateTime(0))─┐ │ 1970 │ └───────────────────────┘

забавно :) select toDateTime('1950-01-01 00:00:00'); SELECT toDateTime('1950-01-01 00:00:00') ┌─toDateTime(\'1950-01-01 00:00:00\')─┐ │ 0000-00-00 00:00:00 │ └─────────────────────────────────────┘ 1 rows in set. Elapsed: 0.001 sec.

да, не поддерживается ничего до unixepoch

его unsigned сделали, что ли?

по-моему потому что там в UInt64 фактически время хранится

а, то есть 20001 год нужен, а 1950 нет :'(

Причем у toDateTime есть хитрая особенность, он до какого-то числа жрет не секунды, а дни

:) SELECT toDate(365); ┌─toDate(365)─┐ │ 1971-01-01 │ └─────────────┘

действительно. в доке есть про это "Позволяет хранить значения от чуть больше, чем начала unix-эпохи до верхнего порога, определяющегося константой на этапе компиляции" ну не очень-то и хотелось

:) SELECT toDate(10000) AS a, toDate(100000) AS b, toDate(1478877709) AS c; ┌──────────a─┬──────────b─┬──────────c─┐ │ 1997-05-19 │ 1970-01-02 │ 2016-11-11 │ └────────────┴────────────┴────────────┘

вот наглядней

это вообще проектировали? :)

ну, на доске, хотя бы

ну видимо в метрике понадобилось оптимизировать какие-нибудь запросы с toDate

SELECT toDate(24855), toDate(24856) ┌─toDate(24855)─┬─toDate(24856)─┐ │ 2038-01-19 │ 0000-00-00 │ └───────────────┴───────────────┘

а функция empty() разве не должна возвращать true для FixedString, полностью заполненных NULами?

оборачивать в toStringCutToZero как-то глупо

:) SELECT toFixedString('', 4) AS str, empty(str) AS is_empty; ┌─str──────┬─is_empty─┐ │ \0\0\0\0 │ 0 │ └──────────┴──────────┘

Да, для FixedString функция empty сейчас бессмысленна. Можно пересмотреть.

ОК, спасибо!

Обсудили. Коллеги говорят, что делать empty = 1 для FixedString, заполненной нулевыми байтами, нелогично.

Можно писать типа IPv6 = toFixedString('', 16) вместо empty(IPv6)

хм, а почему? не совсем понял :(

Спорный момент. Строка, заполненная нулевыми байтами, всё-таки непустая. И если не упоминать, что это строка фиксированного размера, то это совершенно ясно.

Также ради инварианта: empty(x) то же самое что и length(x) = 0.