Кстати, а можно узнать, чем вызвана необходимость пилить свой формат SQL? Почему нельзя было взять классику?

Кстати, а можно узнать, чем вызвана необходимость пилить свой формат SQL? Почему нельзя было взять классику?

Это которую?

Есть где то библиотека sqllib_std?

есть стандарт...

например, SQL-92

Ну так к нему вроде как идти надо

Сначала часть функций потом ещё

Сначала часть функций потом ещё

а джойны свои накастылить? ?

или вы сейчас описали светлое будущее, к которому CH рано или поздно придет априори?

Хз

Я описал как пишут софт

гмм.. не подскажете, почему такое может быть? SELECT id, timestamp FROM data WHERE timestamp = '2016-11-09 22:49:10'; ┌─id───┬───────────timestamp─┐ │ 123 │ 2016-11-10 01:49:10 │ └──────┴─────────────────────┘ движок MergeTree, на сервере вроде часовой пояс и все такое не менялось, не уверен, могу уточнить

гмм.. не подскажете, почему такое может быть? SELECT id, timestamp FROM data WHERE timestamp = '2016-11-09 22:49:10'; ┌─id───┬───────────timestamp─┐ │ 123 │ 2016-11-10 01:49:10 │ └──────┴─────────────────────┘ движок MergeTree, на сервере вроде часовой пояс и все такое не менялось, не уверен, могу уточнить

Clients does some offsetting?

Сдвиг 3 часа

Это таймзоны

А вот что именно не так - не очень понятно, да. Надо смотреть где какие настройки стоят и что менялось

ну да, я тоже об этом подумал, но почему такое расхождение-то все равно..

Ну 3 часа

Москва vs Гринвич

да дело даже не в том, что 3 часа и GMT vs MSK, а в том, что странно, что время в WHERE одно, а в выводе - другое

btw там выше был флуд про "кликхаус не для точных данных"

Хочу заметить, что всё это ерунда

Мы храним в CH в том числе и деньги, и считаем по ним аналитику. Это работает точно до копейки.

Все гарании можно обеспечить, как я уже говорил.

Игорь, да, это странное, такого быть не должно.

Напишите на рассылку подробности, пожалуйста

Попробуем понять где проблема

Мы храним в CH в том числе и деньги, и считаем по ним аналитику. Это работает точно до копейки.

DECIMAL?

копейки скорее

Краткий ответ: UInt32

Краткий ответ: UInt32

эммм,а как же НДСы и т.п.

Предрасчитываются и записываются отдельными столбцами.

Расчет правильных сумм делается не в ClickHouse по сути.

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

т.к. расчет на стороне, и если делать аналитический расчет, то гарантий нет

Напишите на рассылку подробности, пожалуйста

вроде понял, в чем проблема, можно лучше issue на гитхабе открою?

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

вроде понял, в чем проблема, можно лучше issue на гитхабе открою?

Не стоит: https://groups.google.com/d/msg/clickhouse/vqp6x41IOPA/WC4Ec3tMAwAJ

what about bank operations that involve fractions of smallest currency unit?

we do not this kind of operations generally

but it's possible to convert your data to this smallest fractions, for example multiply your money to 1.000.000

Не стоит: https://groups.google.com/d/msg/clickhouse/vqp6x41IOPA/WC4Ec3tMAwAJ

спасибо большое, извините за беспокойство! я успел разобраться в "проблеме" только на уровне того, что так вёл себя только нативный clickhouse-client, а по 8123 всё ок.

DECIMAL isn't supported for now.

печаль

А, вот в чем дело. Понятно, да.

Тогда это сложно считать багом.

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

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

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

а таймстемп парсит клиент?

Да, надо серверное время использовать.

Да, таймстемп парсит клиент.

some kind of annotation on timestamp column?

Привет. А как обстоят дела с партицированием? Есть какие-то ограничения на хэш?

Привет!

Насколько я помню, там UInt64

Ну и можно делать expressions

Но мы рекомендуем шардировать руками, это более эффективный и контролируемый способ работы с данными

Подробности тут: https://clickhouse.yandex/reference_en.html#Distributed

кстати, а есть какой-нибудь официальный гайд по использованию ClickHouse в Kubernetes?

ну то есть не обязательно именно кубернетес, ямлы нужные я и сам напишу

вопрос скорее про контейнеры, оверлей-сети и вот это все

Я немного не про шардирование, а именно партицирование с целью удаления кусков информации. Мы в VERTICA используем - это супер-удобно, т.к. без этого удаление становится банально невозможным.

удаление, вроде, сказали, будет в Q2 2017

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

Тема с произвольным ключем партиционирования действительно была бы очень крута

месяц не всегда удобно

согласен

Да, там так и делается, старые данные удалить можно только удалмив партиции (или мне показалось)

удаление, вроде, сказали, будет в Q2 2017

Ну удаление в таких системах, имхо, не сильно востребованная фишка. А вот партицирование по произвольному ключу и возможность удаления партиций - это огонь. Пока из-за этого КХ не можем рассматривать как решения для prod'а.

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

Ну удаление в таких системах, имхо, не сильно востребованная фишка. А вот партицирование по произвольному ключу и возможность удаления партиций - это огонь. Пока из-за этого КХ не можем рассматривать как решения для prod'а.

партицирование по произвольному ключу очень часто просят, да )

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

Т.е. делаешь INSERT INTO SELECT нужный диапазон в нужную таблицу, а потом атомарный RENAME с последующим DROP'ом? Кстати, RENAME атомарный имеется?

Партицирование про произвольному ключу будет, да.

Атомарный rename имеется.

Пишешь rename a -> a_old, a_new -> a;