У каждого шарда в конфигурационном файле может быть указан параметр internal_replication. Если он выставлен в true, то для записи будет выбираться первая живая реплика и данные будут писаться на неё. Этот вариант следует использовать, если Distributed таблица "смотрит" на реплицируемые таблицы. То есть, если таблица, в которую будут записаны данные, будет сама заниматься их репликацией. Если он выставлен в false (по умолчанию), то данные будут записываться на все реплики. По сути, это означает, что Distributed таблица занимается репликацией данных самостоятельно. Это хуже, чем использование реплицируемых таблиц, так как не контролируется консистентность реплик, и они со временем будут содержать немного разные данные.

Здравствуйте! Скажите, пожалуйста, а этот параметр имеет значение по умолчанию? То есть, если его явно не прописывать.

Это ошибка (лишнее квотирование) - давно хотели исправить. У @kshvakov даже был PR с исправлением, но до мержа не довели.

подскажите, пожалуйста, по словарям внешним. не работает внешний словарь: Code: 85, e.displayText() = DB::Exception: Format JSON is not suitable for input, json такой [ { "id": 1, "name": "ya.ru" } ] в JSONEachRow все получилось, а вот какой json должне быть в словаре? конфиг словаря https://gist.github.com/andrewrbe/9c4196322a309457fd971b87725d4e93

а почему при подневных партициях в именах партишенов добавляются обратные слеши?

Я поправлю, там нужно с tuple разобраться, всё никак руки не дойдут

Не уверен что стоит это менять.

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

Исправлено в master

Поэксперементировал немного. Я был уверен что при кастомовых ключах партиционирования - всегда используется синтаксис tuple (даже при единственном ключе). И в принципе вместо удаления кавычек можно было бы добавить скобки вокруг значения, тогда CAST работал бы без проблем. Но там похоже есть некоторая непоследовательность. Сейчас сделаю gist'a чтоб показать.

Исправлено в master

а можно узнать номер коммита?

Благодарю. Значит, в следующем релизе выйдет?

Вероятно вот это: https://github.com/yandex/ClickHouse/pull/2292

Да

Вечер добрый. Nullable(Date) не инсертится через clickhouse-client, если формат CSV. Если переделать файл и запрос на формат Values, то инсертится. Никто не сталкивался? Может быть, я что-то неверно делаю. Записал пример сюда https://github.com/yandex/ClickHouse/issues/79#issuecomment-386027065

оперативки примерно в 2 раза больше чем данных

Сейчас накидал простое API для внешних словарей, можно его поднять и ходить из ClickHouse к словарям по HTTP (формат JSONEachRow). В API пул конектов (пока хардкод https://github.com/ClickHouse-Ninja/clickhouse-dictionary-api/blob/master/clickhouse-dictionary-api.go#L31 ) https://github.com/ClickHouse-Ninja/clickhouse-dictionary-api

Гуд :) В рамках ревью: 1) TSV требует пересылки через сеть меньшего количества данных. В некоторых случае разница больше чем в 2 раза (например длинные названия колонок содержащих небольшие строки/числа). И обычно быстрее в сериализации/десериализации 2) там только полное чтение словаря реализовано, хорошо бы ещё по ключам чтоб умел читать (для layout <cache>). 3) можно ещё сделать сразу обвязку чтоб можно было запускать как системную службу. 4) пример xml файла с конфигурацией словаря для Clickhouse можно добавить.

Кликхаус порой напоминает этакий конструктор ЛЕГО, в которым части иногда можно соединить каким-то неожиданным способом. :)

Кстати сейчас в голову пришла забавная идея: как источник HTTP словаря можно использовать Clickhouse :D Типа http://localhost:8123/?query=SELECT%20*%20FROM%20mysql(...)

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

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

Добрый день. Подскажите пожалуйста, как в ch сделать срез данных, не используя агрегатный функций select toStartOfDay(date_time) AS grouped_time, AVG(close) from am_coll.buckets where date_time >= toDateTime('2018-05-01 00:00:00') and date_time <= toDateTime('2018-05-05 00:00:00,') group by grouped_time order by grouped_time в этом случае я получу среднее значение close, а я хотел бы получить значение close на 00:00:00 в периоде дат например с 2018-05-01 на 2018-05-05. с ch первый опыт, с timeSlots как-то сложно выходит...

@lavi1555 , так не честно, в вашем примере есть группироки и агрегатные функции :P

Если хотите без группировки и агрегатных функций - то можно например так SELECT * FROM table WHERE timestamp IN ( select toDateTime( toDate('2018-05-01') + number ) from numbers(10) ). Только если в этой секунде не будет данных то ничего не получите, а если будет больше 1 строки - то получите больше.

за сутки есть очень много данных, мне нужен именно срез, а не AVG, MIN и.т.д. чтобы каждый на день в 00:00:00 получить срез того, что есть. фактически первый row каждого дня

select * from table_name where (id, timestamp_col) in ( select id, min(timestamp_col) from table_name where date_col between ... group by id, date_col ) как нибудь так?

кроме табикса и консоли альтернатив нет совсем