а за постоянство "поведения" функции toDateTime(0) можно быть спокойным? а то в части запросов еще такие варианты остались

Вы же в distributed пишите, там по умолчанию распределение рандом, т.е. выши ретраи вполне себе могут писать в другой шард. Как уже сказали выше 1,5к для parts_to_throw_insert - это сильно много, нужно смотреть во что вы упираетесь при вставке, ну и понять почему Replicated* не мержат при смерти 1-й из 2-х реплик тоже, тут @ztlpn может рассказать почему так и почему так быть не должно. Вообще тут можно глянуть в логи и system.replication_queue + system.merges, возможно там что-то интересное будет.

Там разгадка в материализованных представлениях (навешанных на Distributed) :) Именно от них приходят сообщения про too many parts. А так как вставка в MV и в основную таблицу не транзакционна, вставки в основную таблицу проходят и дубликаты копятся.

подскажите, я правильно понял, что цепочка MergeTree -> матвьюха1 -> MergeTree -> матвьюха2 -> MergeTree будет работать нормально, но если заменить везде MergeTree на ReplicatedMergeTree, то матвьюха2 уже не будет срабатывать?

Если ли какой-нибудь красивый метод перебалансировать кластер, если добавляются новые шарды?

матвьюхи тоже надо сделать Replicated

Коллеги, у меня следующий вопрос. Нужно гарантировать порядок строк внутри групп после GROUP BY, чтобы результаты функций groupArray() былы детерминированы. Как этого проще всего добиться для такого запроса: SELECT -- во всех массивах нужно гарантировать правильный порядок по возрастанию timestamp groupArray(timestamp), groupArray(a), groupArray(b), groupArray(c), ... FROM table GROUP BY session_id Пока в голову приходит только ручная сортировка каждого столбца через arraySort((x, y) -> y, arr, timestamp). Но не хотелось бы выполнять это для каждого столбца.

завёл тикет на гитхабе: https://github.com/yandex/ClickHouse/issues/2739

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

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

чуть глупый вопрос. есть ли функция, которая переводит секунды во время? на входе 325 секунд, на выходе 00:05:25

чуть глупый вопрос. есть ли функция, которая переводит секунды во время? на входе 325 секунд, на выходе 00:05:25

если убрать any(message) as errorMessage 0.5 секунды

А message хочется получить

а как у одного messageId может быть много message? а кто "ключ этой таблицы?

Как-то можно быстрее получить message, который 1к1 с messageId по Которому группировка

а зачем группировать по messageId, если оно 1:1 с message? я мыслю не уловил :(

+ мне id в любом случае нужен

по одной таблице хоть? но вообще ответ на твой вопрос тогда: никак :)

Одной, да

там у тебя сколько триллионов записей?

А сделать список уникальных id-messAge и сделать последовательный запрос за ними с where in?

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

ну я больше про PG и MySQL, если конечно их можно считать бд

Подскажите почему не работает ALTER DELETE. Версия КХ 1,1,54394? Code: 62 Syntax error В справке написанно, что с 1,1,54388 есть такая функция

Покажите полную версию запроса

У вас точно таблица с движком MergeTree?