Я откатил на 19.1.9

В мастере это в какой версии?

Что значит в clickhouse-client команда \
?
минимизированное приглашение ?

В основной ветке на гитхабе, но ни в какой версии еще

Наверно значит много строчек

Многообещающее. А когда ждать релиз?

Чем скорее потестируем, тем быстрее будет. Вот, добровольцев ищу )

А чем можно помочь? Поставить последний мастер и потестить?

Нет. Спотыкается как обычно, начиная со второй

ну напшии все в одну без переноса

Добрый день!

Пытаюсь подключиться прямо из JetBrains Rider к ClickHouse в облаке. Хост правиьный, БД написал, SSL включил, сертификат присоединил... и тест коонекшена не проходит.

[1002] ClickHouse exception, code: 1002, host: ... failed to respond .

Из DBeaver всё норм.

Причём к нашему локальному ClickHouse подключаюсь без проблем и из Rider и из DBeaver. Никто не сталкивался?

Да, потестить на своих запросах

Разобрался. Как и в DBeaver надо было настраивать соединение через вкладку Advanced.

А вы используете ssl? Я никак не могу подключится к КХ через ssl через DBeaver

Тогда результат не отличается от того, что в обычном приглашении пишу

Да, там в Connection settings -> Driver properties : ssl выставил в true. Ну и путь до серитификата надо указать в поле sslrootcert.

Добрый день коллеги
С чем может быть связана ошибка при чтении из таблицы?
После этого таблица перестала быть доступной для чтения

DB::Exception: Cannot write to ostream at offset 2570059776
<Error> HTTPHandler: Cannot send exception to client

Доброе утро! Кто знает, чем отличается countState от uniqState по уникальному полю в materializedView? countMerge выдаем неправильные данные, uniqMerge - четко правильные

count - это count (считает кол-во строк), uniq - это алиас для COUNT(DISCTINCT()) - считает кол-во УНИКАЛЬНЫХ значений

в MergeTree таблицу добавляем 100 значений, во вьюшке с countState в итоге 70, во вьюшке с uniq в итоге 100 (правильно)

то есть count() в AggregatingMergeTree куда-то девает часть данных

Покажите запрос создание исходной таблицы и матвьюхи

CREATE MATERIALIZED VIEW IA ENGINE=ReplicatedAggregatingMergeTree(path,smth,iDate, (iDate,managerId,userId,campaignId,creativeId,sourceId,domainId), 8192)
AS SELECT
iDate,
managerId,
userId,
campaignId,
creativeId,
sourceId,
domainId
countState(id) as iCount
FROM MergeTreeTableName
GROUP BY
iDate,
managerId,
userId,
campaignId,
creativeId,
sourceId,
domainId

countState(id) as iCount - не получается потом вытащить правдивое число

uniqState(id) - правильно все хранит

как будто где-то там внутри при мерже поведение count() какое-то не такое, как я думаю)

Запрос
SELECT
iDate,
managerId,
userId,
campaignId,
creativeId,
sourceId,
domainId
count(id) as iCount
FROM MergeTreeTableName
GROUP BY
iDate,
managerId,
userId,
campaignId,
creativeId,
sourceId,
domainId

Показывает значения, совпадающие с uniqMerge ?

ага

И покажите запрос, который выполняете над матвьюхой (там где uniqMerge)

select countMerge(iCount) from impressionsAggregatedCountNoId where impressionDate='2019-03-01' and userId=64 and creativeId=2322

select uniqMerge(impressionsCount) from impressionsAggregatedUniq where impressionDate='2019-03-01' and userId=64 and creativeId=2322

вот 2 вьюхи, в одной uniqState во второй countState

и эти 2 запроса

uniq правильное

Вы же понимаете что countState(id) применяется к каждому блоку, вставляемому в исходную таблицу? А не ко всей исходной таблице?

А uniqStat - вычисляет промежуточное состояние этой агрегатной функции (для каждого вставляемого блока) и при вызове uniqMerge - доагрегирует и потому показывает правильное значение

то есть countState() не будет во вьюшке показывать правильное количество строк? Мне казалось это 2 одинаковые ф-ции, за исключением того что uniq уникальные ищет

1. это не одинаковые функции.
2. матвью указаный при создании запрос применяет к вставляемому блоку

то есть ожидалось что при вставке countState() добавит именно вставляемое количество, как и uniqState

КХ это не про ожидание, а про суровую реальность

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

но по факту uniq нас спасает)

Это да

попробовали на новой версии кликхауса

это был баг

у нас древняя 1.1.54.. версия

count() работает на свежих версиях нормально)

Подскажите а какой момент перестраивается materualuzed view

коллеги, в кликхаусе есть функции toStartOfHour, toStartOfDay, а если нужна функция toStartOf12Hours то как быть? может как-то можно через деление в самом sql запросе это прописать?

ClickHouse тормозит

toStartOfInterval(t, INTERVAL 12 hour)

оО спасибо, жаль только что в документации этого не написано(

Ребят подскажите, кто нибудь добавлял модели catboost в КХ. Проблоема след плана - выкачиваю прекомпилированные файлик с гита https://github.com/catboost/catboost/releases, и в конфиге КХ указываю путь до него
<catboost_dynamic_library_path>....catboost.so</catboost_dynamic_library_path>
Плюет пошибку -
Code: 375, e.displayText() = DB::Exception: Cannot dlopen: /usr/lib64/python2.7/site-packages/catboost/libcatboostr-linux.so: undefined symbol: R_DimSymbol, e.what() = DB::Exception

Пробовали также устанвоить catboost через pip шибка была другая -
Code: 375, e.displayText() = DB::Exception: Cannot dlopen: /usr/lib64/python2.7/site-packages/catboost/_catboost.so: undefined symbol: PyExc_KeyboardInterrupt

В итоге я выкачал рекомпиленные файлы из докер контейнера из данного туториала https://github.com/yandex/clickhouse-presentations/blob/master/tutorials/catboost_with_clickhouse_ru.md, и все заработало.

Но хотелось бы понять почему КХ не принимал файлы выачанные с гита и через pip

Еще вопрос

Задача: Перенести MergeTree в ReplicatedMergeTree

Делаю: ALTER TABLE ch_log ATTACH PARTITION '20190301_20190301_111745_113127_278'

Получаю: Code: 53, e.displayText() = DB::Exception: Type mismatch in IN or VALUES section. Expected: UInt32. Got: String

Почему?

Ожидал сообщение что файл кривой, его нет, но не про типы

Вы пытаетесь приаттачить кусок, а не партицию (кстати, почему?) соответственно, вам нужен запрос ATTACH PART

ALTER TABLE ch_log ATTACH PART '20190301_20190301_111745_113152_283'

Code: 33, e.displayText() = DB::Exception: Cannot read all data. Bytes read: 0. Bytes expected: 4.

скопировал файлы с боевой БД на новый сервер - пытаюсь их развернуть

права 777

попробовал из каталога detatched/ch_log_data

ALTER TABLE ch_log ATTACH PARTITION 'ch_log_data'

Code: 53, e.displayText() = DB::Exception: Type mismatch in IN or VALUES section. Expected: UInt32. Got: String

есть варианты что не так? )

Делаю так

ALTER TABLE ch_log ATTACH PARTITION '201902'

Code: 53, e.displayText() = DB::Exception: Type mismatch in IN or VALUES section. Expected: UInt32. Got: String

Есть одно поле UInt32, ощущение что ATTACH вставляет его как String

Попробуйте указать без кавычек

https://clickhouse.yandex/docs/en/query_language/alter/#alter_attach-partition
Хотя в таблицах старого типа кавычки тоже допускаются

да, а в ру версии ковычки https://cl.ly/f74ae046cfe8

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

ALTER TABLE [db.]table ATTACH PARTITION|PART 'name'

Следующий вопрос

ALTER TABLE ch_log ATTACH PARTITION 201902
ALTER TABLE ch_log ATTACH PARTITION 201903
ALTER TABLE ch_log ATTACH PARTITION 777777

Все 3 запроса возвращают ОК

есть куски

20190201_20190221_50350_93852_12781
20190301_20190301_111745_113152_283

Но в таблице ничего. Почему?

По идее надо ругать на 777777 или сказать сколько чего вставил

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

в старых специально не задавалось

в новых PARTITION BY toYYYYMM(created_at)

плохо что нет сообщений что не так, даже если явно нет партиции - непонятно что делать

ну в этом и разгадка

таблица нового стиля просто не считает эти директории кусками - формат имени не тот

https://cl.ly/09d177e390e7 - это больше похоже на стандартный формат хранения

Русскую документацию поправим на днях.

А почему записи не добавляются и ошибок нет? )

кусок есть 20190201_20190221_50350_93852_12781

201902

ALTER TABLE ch_log ATTACH PARTITION 201902

хотя консольный клиент пишет 0 rows in set. Elapsed: 0.003 sec.

Добрый вечер, а нужно ли учитывать порядок при описании атрибутов внешних словарей из локальных csv файлов или нет? Если нужно, то как работает сопоставление порядка колонок (сначала секций key, затем уже attribute?)

попробую сделать дамп

jfyi все команды так делают и optmize и drop partition, может для идемпотентности.

да, ключ - первая(ые) колонки в csv

Тут специфика формата имени куска - кусок старого стиля воспринимается таблицей нового стиля, как кусок партиции 20190201 (а не 201902). Хотя этот случай наверняка довольно распространённый, и можно было бы добавить сообщение об ошибке.

ну надеюсь shadow дамп совместим между версиями

нет, не совместим

а как мне данные перенести? )

или вы про версии кликхауса?

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

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

ClickHouse client version 1.1.54318.
ClickHouse client version 19.3.3.

вот у меня такая разница

между старой и новой версией

Так тут проблема не в версиях сервера, а в том, что у вас старая таблица создана как MergeTree(Date, ..., а новая как MergeTree PARTITION BY toYYYYMM(Date). Создайте новую таблицу также через синтаксис MergeTree(Date, ... и данные отлично подцепятся.

может в csv?

Есть такое :) https://cloud.yandex.ru/services/managed-clickhouse

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

Если вы изменили конфиг и изменения не применились - значит нужно перезагружать

это официальный ответ? =)

Официальный ответ что? Тут чат, где читают и пишут пользователи КХ. Явного списка параметров, которые требуют перезагрузки - нет (можете поискать по чату)

да я имею в виду, что в документации не появится список таких параметров? как у Postgres, например

Здравствуйте. Почему JOIN такой тормозной? Это так и должно быть?

Поищите по чату. На вскидку - конфиг словарей подхватывается без перезагрузки

Нужно больше деталей: какая схема, сколько записей, как джоините, зачем вам это

Ну когда будет КХ 25 лет, список будет в документации и в таблице (settings) будет колонка (dynamic y/n)
Нельзя изменять настройки (размеры) кешей и настройки megretree

а то что там конфиг надо заливать через api? не очень то высокоуровневое решение))

он не тормозной (я думал что в КХ hash join тормозной, потом сравнил с вертикой и понял что нет).
Ну и есть специальный движок Join, он летает, как и словари.
По большому счету в OLAP можно использовать только HJ.

ясно понятно

Но вообще можно запилить NL и эвристикой на него переключаться (правая отсортирована и записей <10млн., я проверял быстро работает).

create table l1( A Int64 ) Engine=MergeTree order by A;
insert into l1 select number from numbers(1000000000);
create table r1( A Int64 ) Engine=MergeTree order by A;
insert into r1 select -number from numbers(10000000);

HJ: SELECT r1.* FROM l1 ANY INNER JOIN r1 using A
Elapsed: 9.800 sec. Processed 1.01 billion rows

NL: select A from l1 where A in (select A from r1)
Elapsed: 0.759 sec. Processed 8.19 thousand rows

А хотя, эот неправильно, наверное надо наоборот (миллиард раз сходить в правую, а не миллион в левую)

IN тоже использует hash алгоритм, но в данном примере, дополнительно используется ещё и PK.

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

Коллеги, вопрос.
Есть таблица secret.t1.
Есть схема view, для неё юзер view с настройками:
<view>
<password></password>
<profile>view</profile>
<allow_databases>
<database>view</database>
</allow_databases>
</view>
Пользователь view - readonly.
Есть таблица view.t1 ENGINE = Merge(secret, 't1'). В версии 18.6.0 из неё можно читать этим юзером, а в 18.14.15 - нет.
Вопрос задачи - что делать? Я где-то пропустил настройки какие-то?

За движок таблиц Join -- спасибо, попробую. Иначе придется делать UPDATE, что в случае ClickHouse -- тоже плохо.

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

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

Обходные способы не знаю - можно вместе подумать.

А Distributed таблица также проверять ACL будет?

Нет, она пойдёт под тем пользователем, который прописан в конфигурации кластера.

Кто-нибудь знает, таблица с движком Join хранится в памяти в сжатом виде или нет?

нет

Добрый вечер, подскажите пожалуйста как писать данные с nested arrays через JDBC ?

Можно попробовать через RowBinaryStream, передав setObject(i, Collection<Collection>)

Но сходу не проверю

у JDBC (java) нет мапинга для вложенных массивов.
select [[1,1]]
java.lang.RuntimeException: Parse exception: ByteFragment{[[[1,1]]], start=0, len=7}

наверное формировать sql как строку в TSV например

а есть англогязычный тг-канал кликхауза? я бы туда отправил пару знакомых

@clickhouse_en

thx!

множественный джойн дает более правильный результат, это как-то странно.
set join_use_nulls = 1
select t.a, s.a, y.a,y.b from t left join s on (t.a = s.a and t.b = s.b) left join y on (y.a = s.a);
┌─t.a─┬──s.a─┬──y.a─┬──y.b─┐
│ 1 │ 1 │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │
│ 2 │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │
└─────┴──────┴──────┴──────┘

убираю третью таблицу и null превращается в неправильный 0, и меняется имя поля

select t.a, s.a from t left join s on (t.a = s.a and t.b = s.b)
┌─a─┬─s.a─┐
│ 1 │ 1 │
│ 2 │ 0 │
└───┴─────┘

Он подставляет алиас, как в том тикете

есть сложности с разруливанием полных имен приходящих из правой и левой части джойна (например джойн сам на себя). множественный джойн решает эту проблему неявно подставляя всем именам (у которых еще нет) алиасы, а потом снимает лишние в выдаче. Поэтому все работает как если бы у колонки был алиас

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

его починка в ближайших планах

Добрый вечер. Столкнулся со странной проблемой… Делаю ALTER TABLE … ADD COLUMN … получаю:
Received exception from server (version 18.16.1):
Code: 341. DB::Exception: Received from ch626308:9000, 10.149.163.72. DB::Exception: Alter is not finished because timeout when waiting for some replicas: ch626308 (replication_alter_columns_timeout = 60). Alter will be done asynchronously..

0 rows in set. Elapsed: 60.021 sec.

При это данных в таблице нет

в show processlist нет ничего ни на этом хосте ни на реплике

У кого-нибудь есть идеи куда смотреть?

Причём асинхронно альтер тоже не делается

Может быть такое, что права на создание и удаление таблиц есть, а на модификацию нет?

нет, тогда ошибка была бы точно другой

в смысле сервер ch626308 сам не выполнил alter у себя?

хз, но похоже на то

Альтер зарегистрировался, но реплика его не скачала и не выполнила.
Это фича 18.16.1
сделайте detach/attach таблице

ну альтер вроде реплицируемая операция. не выполнилась нигде

все реплики качают и выполняют
даже те, которые его зарегистрировали

После detach/attach появилась колонка сразу

Code: 44. DB::Exception: Received from ch626308:9000, 10.149.163.72. DB::Exception: Cannot add column partner_birthday: column with this name already exists.

Огонь

спасибо

А есть ссылка на эту фичу? Почитать)

Нет, это не фича, это “фича” 🙂
Мы все надеемся, что в 19.х.х ее нет

Ааааа :)) Спасибо, Татьяна!

Пора мне поднимать всё же тестовый кластер и проводить там все тесты необходимые новых версий, прежде чем накатывать в прод что-то)

А может есть под рукой ссылка на issue?

Было несколько штук про репликацию, которые закрыты уже. Конкретно про alter не знаю

Пытаюсь дамп развернуть

clickhouse-client --host="localhost" --port="9000" --user="default" --max_threads="1" --query="INSERT INTO db.$table FORMAT Native" < "/home/$table-dump-$today.native"

Гдето все ок, где то Bad cast, где вообще ни записей ни ошибок

Както не прозрачно все )

Правда дамп снимается со старой версии и накатывается на новую, как переносить данные - непонятно

Прошу подсказки у знатоков. Есть ли смысл использовать clickhouse для мессенджера? Использовал его для аналитики gps координат - скорость впечатлила.

что-то где-то в чате проскакивала такая идея, КХ не особо подходит для хранения длинных текстовых строк

Больше интересует хранение аудиозаписей. Данная реализация возможна?

зачем их хранить в КХ?
Вы их будете хранить во внешнем хранилище, а в КХ имя файла или ID

Хранилище файлов на основе КХ с S3 апи? Идея для стартапа.

А что такого? Это тож самое, что хранилище на s3, где мета информация сохраняется в мускуль, только с той разницей, что id файла будет ещё в кх попадать

Я имел в виду - файлики в КХ пихать.

А профит-то в чем ? В целом, идея прям плохая.

Just for fun

Копир не сможет помочь? https://clickhouse.yandex/docs/en/operations/utils/clickhouse-copier

Ну нет, тут проще работать с экстентами и в базе хранить inode и sblock, как принято в dfs

Господа, а где-нибудь описана интерпретация планов выполнения запросов CH?

Ну ты читаешь в логе что как и куда и интерпретируешь

Или вы хотите чтобы читал в логе за вас ии?

Оценить стоимость сложно

Ну если вам сложно то ии тем более он же тупой

Если не можете прочитать, просто опытным путем посмотрите

Уважаемые чатовцы, подскажите как быть: если сделать большой дисковый кэш - медленно выполняются инсерты, а если сделать маленький - при SELECT и O_DIRECT часто возникает ошибка доступа к файлу.... сделал средний - теперь и инсерты медленные и ошибка доступа появляется.. где та тонкая грань?

думаете почему почему в названии канала "Не тормозит"?
Потому что не указано, селекты или вставки не тормозят, так и живём.

Может у вас с методологией чего не так? Много инсертов мелких?

Батчи по 300к строк, 25 колонок раз в 20-30 секунд ... И я знаю почему чат называется именно так

Какой то затык, как преобразовать юникс таймстемп в Date Time. Беру toDateTime(1551523615581) и он делает даты в 2002 году. Раньше писал всегда даты как строки и парсятся они нормально. Решил переделать на числа чтобы места меньше было и какая то фигня

у вас timestamp кривой

милисекунды лишние

От блин, спасибо

Столкнулся со странным поведением — преобразование datetime при реплицировании

- сначала на машинах 1 и 2 была создана реплицируемая таблица (Обычный ReplicatedMergeTree)
- на машинах 1 и 2 был не установлен timezone (по-умолчанию UTC)
- после реплицируемая таблица была создана на машине 3 имеющую конфиг timezone: Europe/Moscow

Проблема: SELECT datetime FROM table на машине 3 у всех строк на 3 часа больше, хотя бинарные данные таблиц одинаковые на всех машинах

Нашёл два решения:
1. На машине 3 убрать настройку timezone — SELECT сразу начинает показывать правильную дату
2. Полностью уничтожить все 3 реплики и узел зукипера.
На всех 3х машинах поставить timezone: Europe/Moscow
Заново создать реплицируемые таблицы на всех 3х машинах

Описаное выше поведение выглядит неправильным, и оба текущих решения не устраивают.
Теряюсь в догадках в какую ещё сторону посмотреть)

так не должно быть.
как вы меняете размер кеша? Что вы вообще подразумеваете под этим?
Какая ошибка, точно (копи пейст)?
O_dicrect по умолчанию включается на файлах больше 10гб (можно его выключить вообще).
какая фс?

Воспроизводится довольно легко
https://gist.github.com/nezed/78bc357335b970901bb8a98b117704ee

ваш клиент (jdbc?) конвертирует даты в зависимости от таймзоны на сервере. Это можно выключить. Но наверное проще иметь utc на всех репликах.

http/clickhouse-client/redash

ну да, так работает jdbc драйвер кх. Там в настройках можно сказать что не смотри tz на сервере используй msc.

Там такие же настройки.

Вот так когда реплики были изначально созданы с одинаковыми timezone

У клиента есть настройка use-server-timezone

(Чиню скриншот)
Вот так выгдялит запрос ch-client когда реплики с разными timezone

На обоих скриншотах для ch3 установлена timezone: Europe/Moscow
Только в первом случае
datetime: 00:00:00
а во втором
datetime: 03:00:00

При чтении с одинаковыми настройками клиента и сервера с которого читают

Да, клиенты переводят в свою таймзону из таймзоны сервера. На втором скрине похоже у клиента moscow у сервера utc.

На скрине две тачки. ch1 действительно UTC - и к нему нет претензий.
ch3 - Мск, и время поломано.
На первом скрине ch3 - тоже Мск

Можете посмотреть как воспроизводится
https://gist.github.com/nezed/78bc357335b970901bb8a98b117704ee

На двух скриншотах для машины с ch3 с одной и той же конфигурацией и клиента и сервера разное поведение

И поведение машины ch3 меняется из-за таймзоны ch1 🤯💥

Под большим дисковым кэшем вы понимаете большие значения vm_dirty*? Его размер должен быть согласован со скоростью записи на диск. Чем выше скорость записи, тем больше можно делать кэш "грязных" страниц. Если сделать слишком большой кэш для медленных дисков, то получите периодические задержки на (cache_size_in_bytes/disk_write_speed_bytes_per_second) секунд, когда операционка будет скидывать содержимое кэша на диск. Например, если размер кэша - 10ГБ, а максимальная скорость записи на диск - 100МБ/с, то получаются задержки до 10000/100=100 секунд.

Что касается ошибок при O_DIRECT, то это выглядит как баг на стороне КХ, который нужно зарепортить и пофиксить

Спасибо, сразу видно телепата в действии, да, речь о dirtycache

yandex/ClickHouse was tagged: v19.3.6-stable
Link: https://github.com/yandex/ClickHouse/releases/tag/v19.3.6-stable
Release notes:
v19.3.6-stable

Про O_DIRECT уже есть тикет на failback фичу: https://github.com/yandex/ClickHouse/issues/4449

Предполагаю, что особенность с большими задержками для больших vm_dirty кэшей можно пофиксить на стороне КХ, периодически вызывая fsync во время мержа, если отключен O_DIRECT. Я не смотрел код, так что это только предположение. @milovidov_an .

Что за ошибка доступа?

Да, у нас в длинном списке есть задача - делать fsync после записи больших кусков, либо асинхронно - при удалении старых, оставшихся после мержа, делать fsync того, что помержено.

(просто так на каждый кусок не получается, так как много файлов, и от многих вызовов fsync очень плохо)

нужно вызывать fsync не на каждый кусок, а на каждые N мегабайт, записанные в output кусок при мерже. Это ограничивает максимальную задержку при сбросе dirty страниц операционкой, т.к. мы сами сбрасываем эти страницы кажде N мегабайт

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

там вроде не работает таймаут по умолчанию

Ого, как то не прикольно.

Попробую тогда буфер уменьшит, а то в PoC данных не особо много.

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

То есть fsync не использования? При этом DIRECT тоже не всегда?

Как можно гарантировать, что кх все сбросил на диск?

так не гарантирует. При внезапном ребуте сервера возможна потеря данных, именно поэтому неактивные парты удаляются через 10мин ) , и если нужна страховка надо ждать записи в две реплики https://clickhouse.yandex/docs/en/operations/settings/settings/#settings-insert_quorum

Ок. insert_quorum уже используется.

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

специально для вашей проблемы есть для кафка таблиц настройка

18.16.0 Для движка таблиц Kafka: проверка наличия подписок перед началом чтения из Kafka; настройка таблицы kafka_max_block_size.

Но его тоже можно на уровне всего КХ устанавливать а не для разных таблиц разное значение ?

Я был неправ т.к. не понимал что при вставке даты она приводится и хранится в UTC
Спасибо!

Привет, в ReplacingMergeTree если указать несколько ключей то уникальность будет проверяться по всем ним?

Подскажите. Materialuzed vview обновляется на инсерт?

Да.

В ReplacingMergeTree невозможно указать несколько ключей. Наверное вы имеете ввиду составной ключ - состоящий из нескольких столбцов. В этом случае проверяется равенство одновременно всех указанных столбцов (то есть, равенство кортежей).

Друзья, помню была волна, когда некий бот сканил IP, находил кликхаус и дропал базы, напоминал, так сказать, что не стоит пароли оставлять дефолтные.
На сервантах доступных из интернета, кроме смены паролей нужно ещё какие-то действия принимать?

Закрыть все фаерволом

у меня помимо паролей и файрволла прикрыто ssl-авторизацией на фронте

Так там тисипи же

будут коннекты с другого сервера, могу, конечно, всем кроме него запретить.
И возможно, коннекты с локальной машины, там IP динамический, но думал, что можно например SSH-туннель сделать.

Доступ по http не нужен, просто портам нули в конфиге указать?

Так по дефолту все запрещено , указывать только те порты что хотите конкретному айпи открыть

tcp у меня вообще для локалки только

yandex/ClickHouse was tagged: v19.1.10-stable
Link: https://github.com/yandex/ClickHouse/releases/tag/v19.1.10-stable
Release notes:
v19.1.10-stable

Привет,в докладе на HL за 2017 год и копипасте отсюда, было сказано, при высокочастотной записи по одной записи КХ начинает отставать, потом зависает. На сколько это сейчас актуальная информация? И считаются ли инсерты через http таковыми ?

а какая разница тисипи или хттп

вы попробуй прочитать вообще что значит merge tree, ничего там в кх не зависает просто устройство таблицы непозволяет писать по одной записи

просто пишите сразу большими блобами

каждый инсерт создает новый парт, парты в бекграунде мержатся в более крупные.
если мелких инсертов слишком много, мерж процесс не успевает, и парты копятся
если партов становится 150, КХ паузит инстерт на 1 сек.
если партов 300, инсерт падает с ошибкой too many parts.

150, 1 сек, 300 -- это параметры которые настраиваются.

можно их заменить например на 15000 и 0, 30000 ? Можно, тогда select -ы начнут работать мееееедддддлееенннноо.

Спасибо, если правильно понял, что инсерт нескольких записей будет считаться за 1 инсерт, парт, тогда всё ок)

неправильно
insert into t values (1);
insert into t values (2);

правильно
insert into t values (1), (2);

бот

вернее 2

Привет. Кликхаус перестает отвечать на 8123 порту. Пробовал версии 19.3.5, 19.3.6, 19.1.10. Запускаю через docker. В логах ничего полезного нет. Или я не туда смотрю?
root@652f42e256bd:/var/log# cat /var/log/clickhouse-server/clickhouse-server.err.log
2019.03.03 22:24:58.807875 [ 1 ] {} <Error> Application: Listen [::]: 0: DNS error: EAI: -9 If it is an IPv6 or IPv4 address and your host has disabled IPv6 or IPv4, then consider to specify not disabled IPv4 or IPv6 address to listen in <listen_host> element of configuration file. Example for disabled IPv6: <listen_host>0.0.0.0</listen_host> . Example for disabled IPv4: <listen_host>::</listen_host>

root@652f42e256bd:/var/log# tail -n 5 /var/log/clickhouse-server/clickhouse-server.log
2019.03.03 22:27:19.014939 [ 30 ] {0ec8aa71-aaaa-44a7-836c-2d45e7f32943} <Debug> MemoryTracker: Peak memory usage (for query): 92.84 MiB.
2019.03.03 22:27:19.015087 [ 30 ] {} <Information> HTTPHandler: Done processing query
2019.03.03 22:27:25.956003 [ 28 ] {} <Trace> SystemLog (system.part_log): Flushing system log
2019.03.03 22:27:25.958148 [ 28 ] {} <Trace> system.part_log (Data): Renaming temporary part tmp_insert_201903_3_3_0 to 201903_3_3_0.
2019.03.03 22:29:45.692389 [ 22 ] {} <Information> TCPHandler: Done processing connection.
Как понять, почему ClickHouse виснет?

Какая вообще версия стабильная?

docker ps
показывает что контейнер жив? может КХ сервер упал или убит OOM-м.

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
652f42e256bd yandex/clickhouse-server:19.1.10 "/entrypoint.sh" About an hour ago Up About an hour 0.0.0.0:8123->8123/tcp, 0.0.0.0:9000->9000/tcp, 9009/tcp some-clickhouse-server

curl -vvvv localhost:8123 ?

clickhouse-client продолжает работать нормально

$ curl localhost:8123 висит и ничего не говорит

$ curl -vvvv localhost:8123
* Rebuilt URL to: localhost:8123/
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8123 (#0)
> GET / HTTP/1.1
> Host: localhost:8123
> User-Agent: curl/7.54.0
> Accept: */*
>

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

то есть сломался только HTTP-интерфейс

интересно, а
curl localhost:9000

$ curl localhost:9000 молчит.

но вот так работает:
$ docker run -it --rm --link some-clickhouse-server:clickhouse-server yandex/clickhouse-client:19.1.10 clickhouse-client --host clickhouse-server
ClickHouse client version 19.1.10.
Connecting to clickhouse-server:9000.
Connected to ClickHouse server version 19.1.10 revision 54413.

652f42e256bd 🙂

а если из контейнера

docker exec -it 652f42e256bd /bin/bash

wget -O- localhost:8123

Из контейнера работает

# wget -O- localhost:8123
--2019-03-03 23:32:16-- http://localhost:8123/
Resolving localhost (localhost)... 127.0.0.1, ::1
Connecting to localhost (localhost)|127.0.0.1|:8123... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4 [text/html]
Saving to: ‘STDOUT’

- 0%[ ] 0 --.-KB/s Ok.
- 100%[==============================================================================================>] 4 --.-KB/s in 0s

2019-03-03 23:32:16 (21.6 KB/s) - written to stdout [4/4]

То есть возвращает Ok.

а что показывает select uptime()

652f42e256bd 🙂 select uptime()

SELECT uptime()

┌─uptime()─┐
│ 4254 │
└──────────┘

1 rows in set. Elapsed: 0.004 sec.

правду показывает. чуть более часа назад контейнер создал и запустил скрипт миграции данных

и он почти сразу упал

что значит упал?

кто?

скрипт ошибку выдал [2019-03-04 00:27:21 +0200] [55717] [ERROR] ClickHouse ServerDisconnectedError: None.

и после этого localhost:8123 вечно грузится и ничего не возвращает

ну это похоже на проблему докера, а не КХ. Я бы обновил докер например.
И начал гуглить docker port forward fails after some time

возможно, спасибо

Есть возможность запустить с --net=host? Тогда форвардинг не используется

Добрый день! Подскажите пожалуйста, в таблице ClickHouse есть поле DateTime в формате YYYY-MM-DD HH:mm:ss, с помощью функции toYYYYMMDD() берется только дата и по этому новому полю создаются партиции. Это нормально, что каждый день создается более одной партиции? (от 3 до 6). Можно ли как-то задать число партиций в день? Система состоит из 2ух реплик и 2ух шардов, и на каждом сервере создано по Distributed table

Вы куски с партициями не путаете?

Партиция должна быть одна, а вот партов создаэтся на каждый инсерт. Потом они мерджятся.

По некоторым причинам в конце может остаться больше одного парта, к примеру из-за превышения размера парта на мердж.

Запрос на выдачу партиций выглядит так
SELECT partition, table, database FROM system.parts WHERE active AND database = 'logs';

так выводит с name

parts != partitions

то есть в ней содержаться куски партиций? а как тогда посмотреть партиции

это именно куски(Parts)

сагрегировать, например так:
SELECT partition,formatReadableSize(size) AS size,rows,days,formatReadableSize(avgDaySize) AS avgDaySize FROM(SELECT table,partition,sum(column_bytes_on_disk) AS size,(sum(rows)) AS rows,min(min_date) AS min_date,max(max_date) AS max_date,max_date - min_date+1 AS days,size / (max_date - min_date +1) AS avgDaySize FROM system.parts_columns WHERE active GROUP BY table,partition ORDER BY rows DESC)

запрос сверху брал из оф.документации

да, но это куски

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

Привет. Подскажите, как можно узнать, сколько занимает в памяти и на диске таблица с движком Join?

Всем привет. Подскажите пожалуйста, как вывести в отдельной колонке номер столбца в выборке?
Например
|row number| name |
1 | Vasya
2 | Vitya
3 | Dima

rowNumberInAllBlocks ищите

Да, видел ее. Но как я понял, она возвращает номер строки в блоках данных, по которым осуществлялась выборка, а мне нужен номер строки в итоговой выборке)
От 1 до колва полученных строк

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

Хмм. Значит я что-то не так делаю

Интересно что именно)

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

Кто знает есть ли какое-либо отличие toUnixTimestamp от toUInt64 от времени?

Для toUnixTimestamp 0 = 1970-01-01 00:00:00, а для toUInt64 0 = 0, например такое отличие

Всем привет. А кому-нибудь удалось обеспечить приватность данных на кластере?… У меня 15 шардов, в шардах локальные таблицы, поверх натянуты distributed. Хочу изолировать эту всю прелесть от внешнего мира и пускать только конкретных «пользователей» что бы это ни значило. В общем и целом - просто ограничить доступ

Коллеги, всем доброго дня. А вакансии в тему постить не возбраняется? Я не HR, ищу человека себе в команду :)

Мне кажется это только взбодрит чат

надо бы админам продумать правила и прописать их в шапке. имхо.

если постить в этом чате, то в каком виде. или в отдельный чат/канал

Окей :) Ну удалят так удалят.
Компания: https://airpush.com
Полностью удаленная работа, fulltime.

Описание вакансии:
DevOps Data Engineer

We're looking for a devops engineer to help us maintain and scale our data backend and infrastructure. As an engineer you'll be responsible for caring for and feeding our servers, monitoring them, and scaling the infrastructure as we grow. Like every member of the Airpush team you'll also be involved in making decisions about product development and the user experience.

You'll be:
• Taking responsibility for our data layer stability and performance.
• Working together with BI to optimize analytics queries.
• Scaling our physical and cloud infrastructure as the product grows.
• Developing and improving our monitoring and reporting system.
• Automating everything.
• Participating in high level design decisions about our platform & product.
• Working with a team of intelligent developers who are passionate about the platform and ad-tech.

You have:
• Hands on experience in some combination of engineering/building systems/test automation.
• Hands-on experience with server-side development and deployment (Kafka, MySQL, ClickHouse, Redshift, Hazelcast, Zookeeper, etc.).
• Experience coding in Python, Java or Go (preferred).
• Experience in managing databases and writing queries in SQL.
• Strong troubleshooting and debugging skills.
• Experience with physical servers as well as cloud providers (AWS, Google Cloud, etc.).
• Experience with configuration management and automation tools.

What wouldn't hurt:
• An interest in automating yourself out of a job.
• An interest in working in a rapidly-growing environment and helping us create a strong dev culture.

Ребят, подскажите а есть способ заставить кх перерасчитывать materialized expression

Думаю, в КХ единственный способ - контроль на программном уровне. Искал сам долго, но ничего не смог найти. Способа разделить доступ к таблицам пользователям/ролям пока нет.

Всем привет. Подскажите есть ли аналоги tableau но чтобы можно было первое время бесплатно и в докере, нужно для PoC чтобы быстро и легко прикрутить для бизнеса УИ красивый к кликхаус.

По моему в конфигах есть возможность ограничить к "схеме", разве нет?

<read_user>
<password></password>
<profile>web</profile>
<quota>default</quota>
<allow_databases>
<database>test</database>
</allow_databases>
</read_user>

Но ведь не к конкретной таблице, к сожалению.

Это да. Просто под каждую конкретную задачу, надо своё колесо изобретать. Или на програмном уровне. Если там репликации нету, можно например в однельной схеме создать мат вью и дать доступ только к этому. В теории, сам не пробовал

Довольно хлопотно делать разделение доступа средствами КХ. На мой взгляд проще реализовать программно.

Вы его поменяли alter-м ? Или у вас нечистая функция?
alter update / clear column или использовать alias вместо materialized.

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

Привет!
Нубский вопрос)
Что-то не могу найти в доках. Есть ли нативный метод выгрузки данных из pg в кликхаус? Сейчас делаю через промежуточный файлик (copy из pg на диск, а потом через clickhouse-client на диск).
Каким-нибудь питоном сздавать сессию в pg и в цикле выбирать батчами данные, а потом через либу писать их в ch, мне кажется, не очень удобно и быстро. Мб есть в ch нормальный способ переноса данных?

Ребят, а подскажите как работает materialized expression. Я предполагаю что результат функции (expression) при 1 select будет записан на диск и следующие запросы будут выполняться быстрее, т.к берут уже готовые данные с диска

select не меняет файлы.
materialized expression вычисляется каждый раз если в парте колонка не записана.
insert и мерж вычисляют materialized expression и записывают в файл.

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

после добавления колонки (materialized / default) она будет рассчитываться при каждом select для старых данных,
она будет материализована и записана на диск для новых данных, также она будет материализована и записана на диск при мерже старых данных.

к девопсерам не ходили ? Вакансии и поиск работы: @devops_jobs

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

Спасибо

select number%13 n, rowNumberInAllBlocks() from numbers(100) order by n limit 10

select n, rowNumberInAllBlocks() from (select number%13 n from numbers(100) order by n ) limit 10

create table XXX (d Date) Engine = MergeTree partition by d order by tuple();
insert into XXX(d) values(yesterday());
alter table XXX add column a Int64 materialized 6;
insert into XXX(d) values(today());
select d,a from XXX;
optimize table XXX partition yesterday() final;
alter table XXX modify column a materialized 7;
select d,a from XXX;
alter table XXX clear column a in partition yesterday();
optimize table XXX final;
select d,a from XXX;
alter table XXX clear column a in partition today();
select d,a from XXX;

С вебмордой есть несколько. Попробуйте redash

А вообще есть в планах что-то про пользователей/права/разграничение доступов и т.д.? Вдруг просто что-то на подходе, а я не в курсе?

Вопрос к администрации скорее 🙂

Есть, но насколько я понимаю - ещё не на подходе.

Спасибо, вот как раз пытаюсь под мак завести это все используя их скрипт для докера

Мне бы чуточку больше конкретики

https://clickhouse.yandex/docs/en/roadmap/
Q3 2019¶ Fine-grained authorization

🙂

Спасибо)

Относительно простое разделение прав (на уровне - список разрешенных баз, можно ли инсерты, можно ли ddl) есть сейчас. В планах (кажется на Q3 2019) есть разработка более гибкой модели, что-то типа ACL если я правильно понимаю

Вообще я осознаю как это сделано в оракле и например в информиксе, и фича на самом деле очень сложна, особенно в плане перфоманса, если нарезать права по колонкам (при создании сессии вычисляются права для каждого объекта и сохраняются в памяти сессии), и все равно есть ручки, типа выключить точную проверку прав для view (для перфоманса. Ну и в оракле и в информиксе у view два типа авторизации возможны на таблицы внутри view -- по создателю / по текущей сессии).

Добрый день.

Смущает поведение ANY LEFT JOIN с аггрегациями. Если в таблице справа от JOIN нет записи, то в поле оказывается значение 0 вместо NULL.

Пример.
В первой таблице две записи
INSERT INTO `users` (`user_id`)
VALUES ('1'),
('2');Во второй таблице одна запись
INSERT INTO `purchases` (user_id, item_id, price) VALUES ('1', '1', 1);
Когда происхдит выборка с LEFT JOIN и аггрегацией:
SELECT `user_id`, `price_sum`
FROM `users` ANY
LEFT JOIN (SELECT `user_id`, sum(`price`) AS `price_sum`
FROM `item_purchased_events`
GROUP BY `user_id`) USING `user_id`;
В ответе для второго айди, которому не соответствует ни одна строка в запросе справа, находится значение не NULL, но 0.
Вот так:
user_id price_sum
1 212121
2 0

По аналогии с SQL ожидался NULL для значений, которых нет в запросе справа.

Искал в документации - нашел только про join_use_nulls (https://clickhouse.yandex/docs/en/query_language/select/#null-processing_2),
но ничего прямо указывающее на подобное. Допускаю, что плохо искал.

Подскажите, пожалуйста, это ожидаемое поведение? Это где-то документировано?
Заранее спасибо.

спасибо. Но, к сожалению, в текущей схеме мы свои задачи никак решить не можем. Будем ждать… А пока закостылим, наверное, как-то со стороны клиентов

так оно и есть join_use_nulls
set join_use_nulls = 1;
┌─user_id─┬─price_sum─┐
│ 1 │ 1 │
│ 2 │ ᴺᵁᴸᴸ │
└─────────┴───────────┘

или костыль CAST(sum(price), 'Nullable(Float64)') AS price_sum

┌─user_id─┬─price_sum─┐
│ 1 │ 1 │
│ 2 │ ᴺᵁᴸᴸ │
└─────────┴───────────┘

join_use_nulls неправильно работает для полей по которым джойнится (USING (user_id)), скоро пофиксят (это легко обойти).

Большое спасибо. Праивльно ли я понимаю, что в случае, когда join_use_null = 0 поведение, которое я вижу, является корректным и ожидается в дальнейшем? В моем случае это очень удобное поведение.\

если бы от меня зависело (я не разработчик КХ и не имею отношения к Я), то с точки зрения маркетинга я бы конечно поставил set join_use_nulls = 1 по дефолту прямо сейчас.

чем дальше, тем больнее исправлять нестадартное поведение, а таблу и миллиарду других тулов пофиг на КХ.

Простите, что вмешиваюсь, но мне кажется проще избавится от NULL значений изначально. Так надежней и проще.

о чем вы? Про конретное приложение или про КХ? КХ вроде двигается к полноценной стандартной ANSI SQL поддержке NULL (год назад null-в в КХ вообще не было, отсюда все костыли -- типа join_use_nulls)

Конкретное приложение, использующие КХ нельзя рассматривать отдельно друг от друга. Потому мое предложение касалось обоих. Данные в аналитической СУБД, которой является КХ, лучше вставлять уже без NULL, тем более таблицы с Nullable занимают больше места, чем хотелось бы.

чего? о чем вы? У топикстартера не хранятся null. У него sql запрос возращает неверный результат (с точки зрения ANSI комитета)

Мне глубоко пофиг на SQL и ANSI и на КХ. Но с точки зрения маркетинга для КХ нужно двигаться в сторону стандарта SQL, а не изобретать мили и фаренгейты.

Ваша позиция понятна, но относительно КХ нужно просто правильно использовать то, что есть в наличии. СУБД развивается и требовать от нее абсолютного соответствия несколько преждевременно.

как сделать select * from mysql(..) where day = today(), чтобы в мускуль корректно передалось условие today()?

я ничего не требую, я просто ответил на вопрос изменится-ли текущее поведение (дефолтная настройка join_use_nulls), так вот я думаю -- да, изменится.

Mea culpa. Не правильно Вас понял.

Ответ: создать вьюху в мускуле с нужными условиями

Большое спасибо.

К сожалению, в случае LEFT JOIN избавиться от нулов не так-то просто. Иногда необходимо отличать отсутствие значения справа от его наличия или нулевого значения.

Стоит попробовать тогда отличить null in DateTime & 1970-01-01 00:00:00. Не всегда это однозначно удается.

Да. Именно про подобное я и говорю.

Я видимо не совсем догоняю как argMax устроен, подскажите как его вместе с группировкой использовать?
Есть таблица timestamp, userid и другие колонки, пытаюсь сгруппировать по пользователю, и через argMax получить по одной последней записи на каждого, но не выходит. Что я делаю не так?
SELECT
argMax(StatsDateTime, StatsDateTime) as time
, User
FROM db.stats
GROUP BY StatsDate, StatsDateTime, User
ORDER BY StatsDateTime DESC

Рекомендовал бы группировать по пользователю

Правда, не совсем понятна логика..

argMax выберет значение первого параметра при максимальном значении второго параметра. т.е. например у вас пользователь посетил 2 URL (колонка page_url)
при запросе select user_id, argMax(page_url, timestamp) from ... group by user_id вы получите последнюю посещенную страницу для каждого юзера

Мне кажется нужен анализ посещаемости страниц...

Пользователей нет, я подменил сущности для простоты, есть события с показателями по устройствам, и надо определять отклонения показателей за последние 5 минут, по отношению к среднесуточным. И иногда просто последние записи, чтобы показать как "текущие"

А можно узнать суть задачи? Возможно есть более простые пути решения. Не претенду, конечно, но не исключаю.

Так я собственно её описал

Вы уписали варинт решения, но не задачу.

Попробуйте формализовать ее (задачу) абстрактно.

Всем привет.

Выполнили clear column. И похоже так сложилось, что в этот момент, как раз мерджились парты в этой партиции.
В итоге мердж и clear column висят уже более 5 часов.
Как быть? Можно ли рестартануть эту реплику?
kill query не помогает

Из сервера идет дым, io 100%

detach / attach table ?

прям весь table? там 5ТБ данных)

https://clickhouse.yandex/docs/ru/query_language/misc/#detach
Удаляет из сервера информацию о таблице name. Сервер перестаёт знать о существовании таблицы.
Но ни данные, ни метаданные таблицы не удаляются. При следующем запуске сервера, сервер прочитает метаданные и снова узнает о таблице. Также, "отцепленную" таблицу можно прицепить заново запросом ATTACH (за исключением системных таблиц, для которых метаданные не хранятся).

А мердж отменится при этом?

2019.03.04 20:46:54.821853 [ 10 ] {} <Debug> table (ReplicatedMergeTreeQueue): Can't execute command for range 201901_0_533609_999999999 (entry queue-0002125745). There are 1 currently executing entries blocking it: MERGE_PARTS part 20190128_20190131_480513_533569_14,

вот такая ошибка

в system.merge есть этот парт elapsed у нее 32562

у clear column 17724

Определять отклонения текущих показателей от среднесуточных

Лучше идти от медианы. Она точнее.

Согласен, вопрос как оптимальнее сделать такой запрос

Было бы удобней видеть исходные данные. Если это не противоречит ... сути задачи.

Даже не даные видеть, а только логику их обработки.

Select deviceid, avg(metric) as daily_average, avgIf( metric, timestamp > now() - INTERVAL 5 MINUTE) as last_five_min_average, last_five_min_average/daily_average from table where timestamp > now() - interval 24 hour group by deviceid

Замените avg на нужную функцию, если нужно значение в последней точке - используйте argMax вместо avgIf

Благодарю, попробую

Похоже на какой-то deadlock. Можете по логам подробно восстановить последовательность событий? Может быть удастся воспроизвести и починить.

Разобрались. Оказалось, что 9 часов шел merge больших кусков

когда мердж закончился - clear column прошел

осталось понять почему merge занял 9 часов

Да, многовато. А насколько велик кусок? Может быть диск медленный?

вот как раз разбираемся

объема там большие. Вполне может быть 1-2ТБ кусок

подкручено ограничение на макс. размер куска? В принципе 2 тб за 9 часов - это примерно 60мб/сек. Что конечно не является впечатляющим результатом, но и чем-то из ряда вон выходящим это тоже не назову.

я регулярно наблюдаю как на загруженных селектами на 100% hdd куски по 150ГБ мержатся по 20 часов. Тут ничего удивительного нет, если чтобы просто прочитать 512 байт уходит 250мс.

как лечить? 2019.03.05 01:22:40.535852 [ 6 ] {} <Trace> DB_NAME.TABLE_NAME (StorageReplicatedMergeTree): Executing log entry to mutate part 20180411_20180411_0_0_0_8 to 20180411_20180411_0_0_0_9
2019.03.05 01:22:40.536493 [ 6 ] {} <Debug> DB_NAME.TABLE_NAME (SelectExecutor): Key condition: unknown
2019.03.05 01:22:40.536527 [ 6 ] {} <Debug> DB_NAME.TABLE_NAME (SelectExecutor): MinMax index condition: unknown
2019.03.05 01:22:40.536542 [ 6 ] {} <Debug> DB_NAME.TABLE_NAME (SelectExecutor): Selected 0 parts by date, 0 parts by key, 0 marks to read from 0 ranges
2019.03.05 01:22:40.536572 [ 6 ] {} <Trace> InterpreterSelectQuery: FetchColumns -> Complete
2019.03.05 01:22:40.536641 [ 6 ] {} <Trace> Aggregator: Aggregating
2019.03.05 01:22:40.536669 [ 6 ] {} <Trace> Aggregator: Aggregation method: without_key
2019.03.05 01:22:40.536697 [ 6 ] {} <Trace> Aggregator: Aggregated. 0 to 1 rows (from 0.000 MiB) in 0.000 sec. (0.000 rows/sec., 0.000 MiB/sec.)
2019.03.05 01:22:40.536713 [ 6 ] {} <Trace> Aggregator: Merging aggregated data
2019.03.05 01:22:40.536747 [ 6 ] {} <Trace> virtual DB::MergingAndConvertingBlockInputStream::~MergingAndConvertingBlockInputStream(): Waiting for threads to finish
2019.03.05 01:22:40.536789 [ 6 ] {} <Trace> DB_NAME.TABLE_NAME (MergerMutator): Part 20180411_20180411_0_0_0_8 doesn't change up to mutation version 9
2019.03.05 01:22:40.536839 [ 6 ] {} <Debug> DB_NAME.TABLE_NAME (Data): Cloning part /database/clickhouse/data/DB_NAME/TABLE_NAME/20180411_20180411_0_0_0_8/ to /database/clickhouse/data/DB_NAME/TABLE_NAME/tmp_clone_20180411_20180411_0_0_0_9

2019.03.05 01:21:56.712125 [ 7 ] {} <Error> DB_NAME.TABLE_NAME (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 107, e.displayText() = DB::Exception: /database/clickhouse/data/DB_NAME/TABLE_NAME/tmp_clone_20181112_20181130_0_16_1_25/duration_ms.bin doesn't exist, e.what() = DB::Exception, Stack trace:

0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x568fcb6]
1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0x29b94cf]
2. clickhouse-server(DB::MergeTreeDataPartChecksum::checkSize(std::string const&) const+0x86) [0x51c72d6]
3. clickhouse-server(DB::MergeTreeDataPartChecksums::checkSizes(std::string const&) const+0x51) [0x51c7581]
4. clickhouse-server(DB::MergeTreeDataPart::checkConsistency(bool)+0x1d4) [0x51bcc24]
5. clickhouse-server(DB::MergeTreeData::cloneAndLoadDataPart(std::shared_ptr<DB::MergeTreeDataPart const> const&, std::string const&, DB::MergeTreePartInfo const&)+0x47b) [0x519930b]
6. clickhouse-server(DB::MergeTreeDataMergerMutator::mutatePartToTemporaryPart(DB::MergeTreeDataMergerMutator::FuturePart const&, std::vector<DB::MutationCommand, std::allocator<DB::MutationCommand> > const&, DB::Context const&)+0x651) [0x51b0181]
7. clickhouse-server(DB::StorageReplicatedMergeTree::tryExecutePartMutation(DB::ReplicatedMergeTreeLogEntry const&)+0x4ab) [0x512d32b]
8. clickhouse-server(DB::StorageReplicatedMergeTree::executeLogEntry(DB::ReplicatedMergeTreeLogEntry&)+0x89) [0x512e1d9]
9. clickhouse-server() [0x512eb50]
10. clickhouse-server(DB::ReplicatedMergeTreeQueue::processEntry(std::function<std::shared_ptr<zkutil::ZooKeeper> ()>, std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&, std::function<bool (std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&)>)+0x41) [0x521faa1]
11. clickhouse-server(DB::StorageReplicatedMergeTree::queueTask()+0x19a) [0x510572a]
12. clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x396) [0x5162456]
13. clickhouse-server() [0x5d9675f]
14. /lib64/libpthread.so.0(+0x7e25) [0x7f55003dbe25]
15. /lib64/libc.so.6(clone+0x6d) [0x7f54ffbff34d] По этой таблице есть активные мутации которые не не могут исполнится. в моей сборке KILL mutation не работает
KILL MUTATION WHERE database = 'default' AND table = 'table'
;

Expected QUERY

Привет, у нового mergetree по дефолту партиционирование отключено?

Мм, господа, а почему у меня может на маке падать коннект через последний ODBC драйвер с 19.3.5 кликом вот так:

➜ ~ cat /tmp/clickhouse-odbc.log
../driver/handles.cpp:59 SQLAllocHandle handle_type=1 input_handle=0x0
../driver/environment.cpp:72
2019.03.04 18:49:01
../driver/environment.cpp:104 === Driver started === VERSION=1.0.0.20190201 UNICODE=1 ODBC_WCHAR=1 sizeof(SQLTCHAR)=4 sizeof(wchar_t)=4 ODBCVER=351 ODBC_LIBRARIES=/usr/local/lib/libodbc.a;/usr/local/lib/libiodbcinst.a;/usr/local/lib/libltdl.a;/usr/local/lib/libiodbcinst.a;/usr/local/lib/libltdl.a ODBC_INCLUDE_DIRECTORIES=/usr/local/include
../driver/attr.cpp:15 impl_SQLSetEnvAttr
../driver/attr.cpp:19 SetEnvAttr: 200
../driver/attr.cpp:39 Set ODBC version to 2
../driver/attr.cpp:61 impl_SQLGetEnvAttr
../driver/attr.cpp:65 GetEnvAttr: 200
../driver/handles.cpp:79 SQLAllocConnect input_handle=0x7fc742d00580
../driver/handles.cpp:22 allocConnect environment=0x7fc742d00580 out_connection=0x7fc74382e5c0
../driver/escaping/../utils.h:29 Exception: wstring_convert: to_bytes error
../driver/odbc.cpp:1362 SQLErrorW
../driver/handles.cpp:112 SQLFreeConnect
../driver/handles.cpp:107 SQLFreeEnv
../driver/environment.cpp:109 ========== ======== Driver stopped =====================

это что то известное?

Release 2018-10-17 я помню работал без проблем

https://github.com/yandex/clickhouse-odbc/issues/156

Добрый день. Нет ли новостей по поводу этой оптимизации? В PR https://github.com/yandex/ClickHouse/pull/3292 комментарий, что «I was hoping this is a building block for #1344 :)», но не понятно, можно ли ускорить выборку последних записей через LIMIT и ORDER BY DESC, кроме как использовать итерацию по временным окнам?

Я прошу прощения что вклиниваюсь, но раз пошло оживление может кто то подскажет? это нормально что на версии 19.3.5 как минимум select table_name.column from table_name на mergetree работает а на distributed дает exception: unknown identifier ?

tableau генерит именно такой квери (

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

Звучит не очень "нормально". А на предыдущих версиях работало?

я сразу с этой начал, сейчас начну даунгрейд/проверку

вот такой ексепшн:

localhost 🙂 select count(connection_rate_distributed.is_cracked) from connection_rate_distributed;

SELECT count(connection_rate_distributed.is_cracked)
FROM connection_rate_distributed

Received exception from server (version 19.3.5):
Code: 47. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received from af-data-clickhouse-04.afdata.internal:9000, 172.31.36.5. DB::Exception: Unknown identifier: connection_rate_distributed.is_cracked, context: query: 'SELECT count(connection_rate_distributed.is_cracked) FROM connections.connection_rate ' required_names: 'connection_rate_distributed.is_cracked' source_tables: 'connections.connection_rate' table_aliases: private_aliases: column_aliases: public_columns: masked_columns: array_join_columns: source_columns: .

0 rows in set. Elapsed: 0.046 sec.

почему source_tables: 'connections.connection_rate'

в 19.1.10 еще работает

Нужен не libodbc.a а libiodbc.a. даже если это симлинк

хм, я делал по мануалу отсюда https://github.com/yandex/clickhouse-odbc/blob/master/MACOS.md

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

я перепроверю

подтверждено что работает так?

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

Там не очень корректное определение odbc - iodbc и надо его исправить

ок, я перепроверю и пересоберу

спасибо

Доброе утро. Подскажите как лучше автоматически накатить схему на клик? Сразу после установки

cat schema.sql | clickhouse-client -mn

Похоже он пытается передать имя колонки вместе с названием Distributed таблицы в нижележащую.

Ну попробуйте ещё на 18.16, "глубже" можно не спускаться.

На 19.1.10 взлетело, мне пока хватит, не хочется совсем глубоко уходить

Надо бы на это issue открыть я думаю?

Коллеги, привествую!
избитая тема - подскажите как дела с множественными джойнами?
можно ожидать в ближайшее время или делать по классике с кучей подзапросов?

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

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

Спасибо, про примерные планы тоже хотелось узнать.

См. https://clickhouse.yandex/docs/en/roadmap/ и список открытых пулл-реквестов

имхо 99% готово (тещу в мастере, нашел мелкий бвг).

Надо. И описать как повторить ("в лоб" - не воспроизводится, возможно какие-то настройки).

открою

Добрый день
Поймал ошибку too many parts
Есть ли возможность указать настройки max_insert_block_size и stream_flush_interval_ms отдельно для выбранной таблицы
Данные читаю из Кафки

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

Частично закостылено

но не зарелижено еще https://github.com/yandex/clickhouse-odbc/commit/b8cb5f5d01bf7a0125793c5599e5e4f4cc2f45bf

и нормальный фикс будет в самом ClickHouse - https://github.com/yandex/ClickHouse/pull/4381

Всем привет. гошный драйвер от mail.ru умеет вместе с chproxy работать?
У нас такое возникло: http://foo:bar@proxies_chproxy:8123/mydb: can't ping clickhouse
При этом
$ curl -X POST -d 'SELECT 1' http://foo:bar@proxies_chproxy:8123/mydb
"10.0.151.86:49142": unsupported path: "/mydb"
$ curl -X POST -d 'SELECT 1' http://foo:bar@proxies_chproxy:8123
1
$ curl -X POST -d '' http://foo:bar@proxies_chproxy:8123
Code: 62, e.displayText() = DB::Exception: Empty query

такое ощущение, что chproxy все оборачивает в POST-запросы, а для работоспособности мейловского драйвера нужны еще и GET-запросы, так как
if err != nil || len(resp) < 7 || string(resp[4:7]) != "Ok." {
return driver.ErrBadConn
}

Добрый вечер, с этим что-то можно сделать, или данные безвозвратно потеряны?
https://pastebin.com/raw/txfQ0TeB

чему равен точный размер Path.mrk и других .mrk файлов?

3535156 у всех

это килобайты, а в байтах?

байты

ошибся, 3619979920 в байтах, то килобайты

Не может быть :) du же показывает 3.4G - должно быть 3619979920

ага, значит с данными всё в порядке

попробуйте сделать SYSTEM DROP MARK CACHE или перезапустить сервер

не помогло

подскажите, на ReplictedMergeTree делаю rename column через:
ALTER TABLE name ADD COLUMN new_column AFTER old_column DEFAULT old_column
Как сделать так чтобы все default значения однозначно проставились чтобы можно было удалить старую колонку?

optimize table ... final

както так:
Storage ReplicatedMergeTree doesn't support FINAL.

а вру, это когда селект делал

а когда optimize table - говорит что нет пароля для пользователя default

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

(увы никак этот баг не хочет фикситься, хотя вроде уже 2 попытки были)

лидер в конфиге прописывается? из select * from system.cluster можно сделать вывод о лидерстве?

ага, оттуда. Он не в конфиге, выбирается динамически.

а если таблица лежит на 3 нодах и у каждой ноды есть 1 реплика, то получается надо 3 раза найти лидера и 3 раза сделать optimize?

select database, table, replica_name from system.replicas where is_leader;

попробуйте ещё понять, повторяется ли проблема на предыдущих версиях сервера (судя по всему, у вас 19.3, попробуйте 19.1 и 18.16)

Да. Ну и есть ещё шанс что с ON CLUSTER сработает (но я не уверен).

Да, сейчас 19.3.5 revision 54415.
попробую откатиться

не помогло, пробовал 19.1, 18.16, трейс с 18.16: https://pastebin.com/i3VC3h9t

Товарищи, подскажите пожалуйста!
Хотелось бы понять насколько применим ClickHouse для такой задачи..

Сервис видеонаблюдения получает данные от камер в виде голых h264 nal (грубо говоря это кадры).
Для быстрого запроса из базы данных, удобства бекапа и прочих преимуществ хранения в базе перед хранением на диске в виде файлов хотелось бы попробовать использовать ClickHouse.

Общий поток с камер на сервер около 70-80 Мбайт/с.
Количество вставок в секунду около 8-10 тысяч.
Объем данных на вставку колеблется от нескольких байт до нескольких десятков килобайт.
Общий объем данных в базе около 70Тб.
Количество индексов в таблице - id камеры, таймстамп, тип нала.

Запросов на чтение в разы меньше.
Изменений данных нет вообще, только если удаление или пересоздание таблицы полностью.

Задача на чтение в основном выбрать кадры для определенного интервала времени по таймстампу.

скажите пжл - команда OPTIMIZE TABLE table FINAL DEDUPLICATE; - подхиодит для дедупликации по первичному ключу? Она не задокументирована, а просто кто-то написал на гитхабе

Команда
OPTIMIZE TABLE table FINAL
подходит. Чем вам не подходит?

1й раз когда запустил - выполнилась, сожрав +3гб от 18гб таблы. Второй запуск - падает с ошибкой DB::Exception: Unknown log entry type: 0

Попробуйте по партициям оптимизнуть
OPTIMIZE TABLE table PARTITION ... FINAL

не применим вообще. КХ будет 70ТБ перекладывать с место на место постоянно.

ок, спс

Чё это? Ну, помержит несколько раз

Но не постоянно же

спасибо буду пробовать

Если поставить максимальный размер куска поменьше, то пару раз может переместит данные

ну да, непстоянно, раз 7 переложит.

КХ так делает с любыми данными

Чем видеофайлы плохи ?

Не очень понятно почему..
70Тб это в месяц со всех камер..они и на обычных файлах перезаписываться раз в месяц точно будут

Основной нюанс заключается в том, что клик ну так себе подходит для сжатых данных

Я бы на вашем месте посмотрел в сторону hadoop (hdfs)

Это невероятно медленно

медленно для чего ?

Записи там выйдут не медленнее

Чтение

Человеку чтение не очень нужно

Да, чтение для пользователей вообще практически нет, для системы видеоаналитики не больше 1-4 раз прочитать и то если в реальном времени данные обработать не успели..

посмотрите на hadoop, в clickhouse вам не много профита будет

да, спасибо, уже читаю)

В 2Тб (сутки) в hdfs выбрать что-то за конечное время? Не помню такого

т.е. вы рекомендуете хадуп что бы в 2ТБ файле делать навигацию на кусок 2МБ в середине ???? Мир сошел с ума по-моему.

Не я не рекомендую, а отговариваю)

мне кажется скорее кассандра тут пойдет

а я понял, то был сарказм. Моя рекомендация - BoltDB

А можно пошутить про MySql ?

погодите, а откуда взялись 2ТБ файлы ?

Там фреймы, их просто очень много

Всем привет! Подскажите, пож-ста, насколько адекватно в Clickhouse создавать внешний hashed Dictionary на 3 млн строк и более? Справочник будет содержать только id и одну строковую переменную. Вариант - добавить расшифровку id в основную таблицу новым столбцом рассматривал, но хочу понять жизнеспособность альтернативы. С Click-ом пока знаком только по документации :(

Да, все врено!
кадр по 0-60кб, в секунду около 8-10 тысяч их всего
хранить файлы по 2Тб не надо)

все отлично будет. (ну памяти съест >500МБ и <1GB)

в контексте обсуждения видео, ради интереса посмотрел на чем работает Youtube
оказалось вот https://github.com/vitessio/vitess

берите https://github.com/boltdb/bolt
The goal of the project is to provide a simple, fast, and reliable database

Понял. Спасибо!

Not bad

YouTube stores all its videos directly on a file system, it uses MySQL to store all the metadata needed to serve each video, such as user preferences, advertising information, country customization and other needed bits of information.
с просторов кворы

не берите витесс, он оч плохо работает) та версия которую использует youtube и та, которая в паблике, очень отличаются друг от друга :) мы пытались его внедрить на протяжении полугода и так и не смогли. Но это было года полтора назад, сейчас может что и изменилось

Спасибо, почитаю.. Немного работал с ним когда-то
Смущает что репозиторий в архиве)

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

На самом деле хранение больших и уже хорошо сжатых объектов - не самая сильная сторона кликхаус. Но если выбирать вам нужно всегда относительно большими диапазонами (скажем по несколько минут) то может и сработать, если некоторые настройки подкрутить. Хотя если честно не очень понимаю чем плохи простые и понятные видеофайлы аккуратно разложенные по папкам.

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

ну так сами метаданные о файлах храните в любой бд, хоть в sqlite

Надобность в КХ у вас очень сомнительная.
Да, мускуль такой объём тяжело будет ворочать, но лить файлы в КХ - нафиг надо.
Лейте файлы в ФС, в КХ сохраняйте путь.
Вам именно морда нормальная нужна и КХ там только для ускорения поиска нужных кадров.
Имхо

Понятно, спасибо! Выбирать как раз диапазонами поменьше..
иногда нужно выгрузить час-два допустим, но это редко..
куда чаще пользователь просто ткнул на перемотку и вот минуту надо выдрать и ему быстро отдать

так и делаю, в тарантуле храню и бакенд в нем же на lua..
но думал КХ поможет все сделать проще и удобнее)

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

тут как раз речь о том чтобы не создавать файлы по несколько минут, а тупо кадры хранить и налету из них собирать все что нужно, mp4, mpeg-dash и тд

да, я храню h264 NAL в нем может быть I слайс (ключевой кадр - жирный до 50кб) либо P-B слайсы, который как раз меньше.. но для базы это все просто один кадр грубо говоря.. полный или нет уже не важно

так написанное мной не противоречит.
От хранения файлов целиком в КХ вы ничего не выиграете по сравнению с тем, что если будете хранить файлы в структуре типа
/Год/Месяц/День/Час/Минута/*

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

10 минут - это у вас 600 000 файлов.
Если вы их храните в одной директории, то конечно долгое удаление будет

Можно попробовать - вдруг заработает :) Я думаю что если использовать партиционирование например по часам (например по 4/6 часов) сортировать данные по id камеры и номеру кадра, снизить index_granularity и выключить сжатие для колонки с видеокадрами - то может даже и будет работать не сильно хуже чем честные файлики, но с SQL интерфейсом :)

Да, буду тестить! Спасибо за советы
База все же дает много удобств..

у вас место в ФС ограничено?

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

те это отдельный сервер со своими дисками, а не облако

Если камер немного - то можно попробовать по id камеры партиционировать.

Дайте знать потом - получилось ли что-то из этого. Ваш сценарий использования очень далек от нормального для КХ, поэтому любопытно :)

Я просто всё равно никак не пойму.
Если хранить путь к кадрам, как я предлагаю, вы так же будете мутации запускать, чтобы выкинуть устаревшее, а потом когда-нибудь удалите свои файлики.
Будет вам и удобство и КХ не будет напрягаться с футблом партов и прочих своих внутренних штук.

а потом в удобное время будете дропать файлы

на этом же сервере видеокарта для видеоаналитики и хранилище.. пока так
камер немного потому как видеоаналитика много fps дать не может
баланс между скоростью сети, местом на диске и fps видеоаналитики вот какой-то такой что 100-500 камер на сервер..

к тому же, вы хотите в КХ писать нон-стоп, как я понимаю, он этого не любит

Почему я думаю что может получиться - для видео стандартный и наиболее подходящий формат хранения - это видеофайлы, которые представляют собой последовательно записанные друг за другом кадры. Данные в КХ это тоже - просто записанные друг за другом значения. Поэтому такой файл с данными КХ по сути практически ничем не будет отличаться от видеофайлы, с теми же плюсами (удобное последовательное чтение) и минусами (нужно пропускать ненужные блоки). Весь вопрос только в том - как будет справляться с вставками и не будет ли много лишней работы делать при фоновых слияниях.

ну хранить путь к кадрам уже как бы и не нужно тогда..
сейчас я точно знаю где искать конкретный момент времени, по таймстампу и id клиента/камеры знаю в какой файл смотреть и в нем уже мелкий индекс + перебор до нужного кадра.. причем могу сделать это даже в mp4 контейнере.. этот файл в плеере даже играется, но при этом в нем есть atom с кастомными пользовательскими данными в которых мелкий индекс лежит уже внутри файла

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

Учтите что вставлять в КХ нужно относительно большими блоками - идеально примерно по 100-200К строк, и что данные в КХ будут несколько раз перекладываться с места на место создавая доп. нагрузку на диск. (Грубо говоря будете вставлять по минуте данных - а он потом из минутых файлов делать бОльшие - на несколько десятков минут - потом на часы и т.п.)

если вы будете в БД, не обязательно кх, хранить путь к файлам, то вполне можно организовать более эффективное хранение, которое будет более оптимизированное для выборок и удалений, нежели просто раскладка по дате.
Большая вложенность каталогов это тоже зло.
А так, взяли хеш по дате + камере, разложили практически красивым деревом, всё сбалансировано, всё работает.
Ручками только фиг удалишь уже.

Но вообще, как не вспомнить одну прекрасную статью, где написано, что КХ не панацея, не решение ваших проблем, и вообще писался не для вас(с)

короче: хотел сделать TRUNCATE этой таблицы. ( В моем случае это ок думал после транкейта все партиции удалятся). После этойго в process list. стали появляться запросы типа SELECT DISTINCT arrayJoin(extractAll(name, '[\\w_]{2,}')) AS res FROM (SELECT name FROM system.functions UNION ALL SELECT name FROM system.table_engines UNION ALL SELECT name FROM system.formats UNION ALL SELECT name FROM system.table_functions UNION ALL SELECT name FROM system.data_type_families UNION ALL SELECT name FROM system.settings UNION ALL SELECT concat(func.name, comb.name) FROM system.functions AS func CROSS JOIN system.aggregate_function_combinators AS comb WHERE is_aggregate UNION ALL SELECT name FROM system.databases LIMIT 10000 UNION ALL SELECT DISTINCT name FROM system.tables LIMIT 10000 UNION ALL SELECT DISTINCT name FROM system.columns LIMIT 10000) WHERE notEmpty(res), KILL query не помогал. Судя по всему после таймаута CH запускал такой же запрос опять. Принял решение рестартить ноду. Рестарт тоже не прошлел гладко. Сервер не мог корректно завершить работу, висело на собщении “Stopped being leader” как раз бля этой таблицы. Сделал KILL -9 Received termination signal (Terminated) и далее при старте CH визимо заигнорил битые партиции. Именно для этой таблицы я готов мириться с потерей даннхых, но вообще беда =( Эта таблица у меня реплицируемая, но в шарде всего одна репоика. Сделал это на будещее (Может в этом причина?)

ничего непонятно, кто на ком стоял.

>короче: хотел сделать TRUNCATE этой таблицы.
TRUNCATE-м чинили проблему и проблема возникла из-за TRUNCATE

Прочитайте сообщение на которое я ответил, у меня не проходили мутации по таблице

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

А в чем вопрос? Лечение той проблемы truncate напоминает лечение головной боли топором :) Приведенные запросы делает clickhouse-client при запуске для инициализации автодополнений

Д я это понимаю. Эта таблица содердит временные данные которые я готов был потерять. А как лечить первоночальную проблему? Когда мутации не проходят из-за тоно что CH не может найти чать данных в партиции? DB::Exception: /database/clickhouse/data/DB_NAME/TABLE_NAME/tmp_clone_20181112_20181130_0_16_1_25/duration_ms.bin doesn't exist, e.what() = DB::Exception, Stack trace:

detach?

Я не спрашиваю почему это произошло(хотя тоже интересно), я спрашиваю как лечить

jfyi: fixed https://github.com/yandex/ClickHouse/issues/4581

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

и этот файл был в порядке в исходной таблице 20181112_20181130_0_16_1_25/duration_ms.bin ?

Я его не мог найти, но вроде-бы был файл с этой директории с .tmp суффиксом. Нужно было скопировать директорию что-ли =)

В след раз буду умнее

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

да, делаю DELETE каждый день, это часть ETL. Удаляю данные по location ( Эта таблица очнь маленькая)

какая версия КХ ?

отменить мутацию для нереплицированной t.me/clickhouse_ru/62084
для реплицированной в зукипере удалить

ClickHouse client version 18.16.1, спасибо

Доброго времени суток!
Подскажите как посмотреть сколько съел тот или иной запрос.
Например у меня в логе фигурирует
2019.03.05 16:40:48.270950 [ 1497167 ] {c2a973a7-3310-4a1b-95f4-2acae830a10c} <Debug> MemoryTracker: Peak memory usage (total): 31.15 MiB.
2019.03.05 16:40:48.270983 [ 1497167 ] {c2a973a7-3310-4a1b-95f4-2acae830a10c} <Debug> MemoryTracker: Peak memory usage (for query): 14.75 MiB.
как я понимаю в 4 столбце это id запроса. А вот чем отличается total от for query?

Спасибо

Если я все правильно понял то это происходит здесь https://github.com/yandex/ClickHouse/blob/d45b90b530f53444d601d60080d4c76e0db0feac/dbms/src/Interpreters/ProcessList.cpp#L156 Судя из имени класса - total это суммарное максимально потребление памяти всеми запросами а for query для текущего запроса. А 4 параметр возможно идентификтор соединения

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

будут доступны, по умолчанию disitributed читает все шарды (см. новый параметр 19.1.6 optimize_skip_unused_shards)

тобишь шард выбирается при инсерте а при селекте читается со всех так?

спасибо

типа того. https://clickhouse.yandex/docs/ru/operations/table_engines/distributed/

инсерт зависит от ключа шардирования, и кол-ва шардов.
и select может читать не со всех optimize_skip_unused_shards / skip_unavailable_shards

да пасусь там спасибо, меня интересует как раз default behaviour, если по дефолту читает со всех то отлично

не, никак

lib ll /usr/local/lib/*odbc*
lrwxr-xr-x 1 i.morokin admin 68B Mar 5 18:15 /usr/local/lib/libclickhouseodbc.dylib -> ../Cellar/clickhouse-odbc/1.0.0.20190201/lib/libclickhouseodbc.dylib
lrwxr-xr-x 1 i.morokin admin 65B Mar 5 18:15 /usr/local/lib/libclickhouseodbc.so -> ../Cellar/clickhouse-odbc/1.0.0.20190201/lib/libclickhouseodbc.so
lrwxr-xr-x 1 i.morokin admin 69B Mar 5 18:15 /usr/local/lib/libclickhouseodbcw.dylib -> ../Cellar/clickhouse-odbc/1.0.0.20190201/lib/libclickhouseodbcw.dylib
lrwxr-xr-x 1 i.morokin admin 66B Mar 5 18:15 /usr/local/lib/libclickhouseodbcw.so -> ../Cellar/clickhouse-odbc/1.0.0.20190201/lib/libclickhouseodbcw.so
lrwxr-xr-x 1 i.morokin admin 47B Mar 5 18:10 /usr/local/lib/libiodbc.2.dylib -> ../Cellar/libiodbc/3.52.12/lib/libiodbc.2.dylib
lrwxr-xr-x 1 i.morokin admin 41B Mar 5 18:10 /usr/local/lib/libiodbc.a -> ../Cellar/libiodbc/3.52.12/lib/libiodbc.a
lrwxr-xr-x 1 i.morokin admin 45B Mar 5 18:10 /usr/local/lib/libiodbc.dylib -> ../Cellar/libiodbc/3.52.12/lib/libiodbc.dylib
lrwxr-xr-x 1 i.morokin admin 51B Mar 5 18:10 /usr/local/lib/libiodbcinst.2.dylib -> ../Cellar/libiodbc/3.52.12/lib/libiodbcinst.2.dylib
lrwxr-xr-x 1 i.morokin admin 45B Mar 5 18:10 /usr/local/lib/libiodbcinst.a -> ../Cellar/libiodbc/3.52.12/lib/libiodbcinst.a
lrwxr-xr-x 1 i.morokin admin 49B Mar 5 18:10 /usr/local/lib/libiodbcinst.dylib -> ../Cellar/libiodbc/3.52.12/lib/libiodbcinst.dylib
-rwxr-xr-x 1 11862 admin 2.6M Nov 28 20:36 /usr/local/lib/psqlodbcw.so

** Trace finished on Tue Mar 05 18:23:58 2019
../driver/handles.cpp:59 SQLAllocHandle handle_type=1 input_handle=0x0
../driver/environment.cpp:72
2019.03.05 18:25:09
../driver/environment.cpp:104 === Driver started === VERSION=1.0.0.20190201 UNICODE=1 ODBC_WCHAR=1 sizeof(SQLTCHAR)=4 sizeof(wchar_t)=4 ODBCVER=351 ODBC_LIBRARIES=/usr/local/lib/libiodbc.a;/usr/local/lib/libiodbcinst.a;/usr/local/lib/libltdl.a;/usr/local/lib/libiodbcinst.a;/usr/local/lib/libltdl.a ODBC_INCLUDE_DIRECTORIES=/usr/local/include
../driver/attr.cpp:15 impl_SQLSetEnvAttr
../driver/attr.cpp:19 SetEnvAttr: 200
../driver/attr.cpp:39 Set ODBC version to 3
../driver/handles.cpp:59 SQLAllocHandle handle_type=2 input_handle=0x7f882958f8f0
../driver/handles.cpp:22 allocConnect environment=0x7f882958f8f0 out_connection=0x7f8829583978
../driver/attr.cpp:444 SQLSetConnectOptionW
../driver/attr.cpp:93 impl_SQLSetConnectAttr
../driver/attr.cpp:97 SetConnectAttr: 103 = 0x1e (8)
../driver/odbc.cpp:65 SQLDriverConnectW connection_str_in=0x7f882958db20 : -3 connection_str_out=0x7f882a0ac200 : 2048
../driver/connection.cpp:141 Parse DSN: key=server value=35.164.55.174
../driver/connection.cpp:141 Parse DSN: key=port value=9090
../driver/connection.cpp:141 Parse DSN: key=database value=connections
../driver/connection.cpp:141 Parse DSN: key=uid value=default
../driver/connection.cpp:141 Parse DSN: key=driver value={ClickHouse}
44793733536 [0x70000a104000] ../driver/escaping/../utils.h:29 Exception: wstring_convert: to_bytes error
44793733703 [0x70000a104000] ../driver/odbc.cpp:559 impl_SQLGetDiagRec handle_type: 2, record_number: 1, out_message_max_size: 2048
44793733738 [0x70000a104000] ../driver/odbc.cpp:559 impl_SQLGetDiagRec handle_type: 2, record_number: 2, out_message_max_size: 2048
44793734157 [0x70000a104000] ../driver/handles.cpp:90 SQLFreeHandle handleType=2 handle=0x7f882958dc70
44793734175 [0x70000a104000] ../driver/handles.cpp:90 SQLFreeHandle handleType=1 handle=0x7f882958f8f0
44793734182 [0x70000a104000] ../driver/environment.cpp:109 ========== ======== Driver stopped =====================

последний odbc под мак не взлетает

всем привет!

что-то никак не пойму, почему не могу создать MV типа AggregatingMergeTree никаким образом
CREATE MATERIALIZED VIEW tst_metrics.`seconds.mva`
ENGINE = AggregatingMergeTree() PARTITION BY toDate(received_at) ORDER BY (timestamp, resp, company_id,message_center_id) SETTINGS index_granularity = 8192
AS SELECT
multiply(intDiv(toUInt32(received_at), 15), 15000) as timestamp,
resp,
company_id,
message_center_id,
sumState(weight) as weight_sum
from stage1.adata
group by timestamp, resp, company_id,message_center_id
вылезает ошибка
Code: 47, e.displayText() = DB::Exception: Unknown identifier: received_at, context: required_names: 'received_at' source_tables: table_aliases: private_aliases: column_aliases: public_columns: masked_columns: array_join_columns: source_columns: , e.what() = DB::Exception
CREATE MATERIALIZED VIEW tst_metrics.`seconds.mva`
ENGINE = AggregatingMergeTree(toDate(received_at), (timestamp, resp, company_id, message_center_id), 8192)
AS SELECT
multiply(intDiv(toUInt32(received_at), 15), 15000) timestamp,
resp,
company_id,
message_center_id,
sumState(weight) weight_sum
from stage1.adata
group by timestamp, resp, company_id, message_center_id
а тут вылезает ошибка:
Code: 36, e.displayText() = DB::Exception: Date column name must be an unquoted string

MergeTree is a family of storage engines.
в чем подвох? КХ 19.1.6

У вас отдельно SELECT выполняется?

нет, не отдельно, а разве нет так описывается MV?

блин, я тугодум, да :)
конечно отдельно SELECT выполняется

Странно, заводите issue

так у вас в селекте нет колонки received_at, вот он и ругается

действительно прокатило, а как избежать этой колонки, мне надо аггрегировать по 15 секунд, а там каждую секунду приходит по 3к

сделайте ещё колонку toDate(received_at) as received_at_date и партиционируйте прямо по ней

сделайте = добавьте в select

спасибо огромное, попробую

круто! работает! 👍

Привет всем. Кто то работал в связке кликхаус и спарк? Интересует, как лучше сделать чтение/запись. Кликхаус выступает как data source для спарка

Я работаю. Кафка стриминг, кмк, лучший вариант в данном случае

Запись
Пишем из каждой partition через RowBinary callback. Знаем, сколько строк во всем DataFrame, который собираемся вставлять. После вставки посылаем запросы с select count() where ..., ожидая пока число строк совпадёт с тем, которое вставляли.

Чтение
В ThreadPool отправляем запросы на SELECT .... WHERE sharding_condition. Потом над результатами делаем UNION, получая итоговый DataFrame

а каскадные MV не работают?
kafka -> MV -> table -> AggrMV?

нет

Через Null-таблицу, но это на свой страх и риск

спасибо!

а планируется вообще добавить такую фичу?

Каскадные МВ как-то обсуждали, насколько помню решили делать

👍

Коллеги, а можно ли каким-то образом сохранить в clickhouse строку с символами "? Пробовал экранировать её, но всё равно не срабатывает

\\ ?

Друзья, подскажите, а как сжатие массивов происходит?
Т.е. как они на диске лежат, каждый элемент в отдельном файле или все строки в одном файле?

вся колонка в одном файле

хоть массив хоть не массив в ней

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

массив в два файла - отдельно уложенные значения массивов подряд и отдельно длины этих массивов

спасибо

А как переделать структуру "2 шарда, 1 реплика" в "1 шард, 2 реплики"? Как мне указать, на каком серваке данные стирать, а с какого брать?

Достаточно ли исправить конфиг на машинах, которые хочется затереть, перезапустить кликхаус и подождать, пока вторая нода скачает всё с первой? ну и потом исправить конфиг на ноде с данными и тоже перезапустить

Только оно как-то очень медленно синкается...

Создать новый кластер в конфиге, без рестарта, создать реплицированные таблицы, INSERT в_новую SELECT из_старой, создать новую Distributed-таблицу указывающую на новый кластер, старый кластер потом просто удалить из конфига

А если рестартовать можно, то есть процедура проще?

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

clickhouse-copier не сумеет?

INSERT SELECT не проще?

Для этого надо в код разработчиков лезть и смотреть, где что и как создавалось

Ребят, привет!

А в докере табикса есть возможность добавить свой sql запрос по умолчанию?

Заранее спасибо за ответ!

Там можно сохранять запросы в отдельной вкладке

Кстати, в копире нашелся баг:
clickhouse-copier copier --config zookeeper-servers.xml --base-dir /tmp --task-path /replicate_cluster
Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Not found: logger
При этом в хелпе об этом ничего нет.

Ребята, есть какие то особые паттерны для хранения в кликхаусе 1 ко многим?
Для примера есть пост, к нему от 0 до 1М комментариев, постов в свою очередь тоже много. Лить все комменты в одну табличку?

Звучит как кейс не для КХ

можно денормализовать 🙂

ну, денормализовать и (post_id, comment_seq_no)

но такое

Чем обычная нормализация не подходит? Да, придёться делать join, но в КХ есть способы оптимизовать: движко Join, словари

Такое по скорости будет?

Нормальное будет. Тот кортеж — ключ, если что

Комменты сажаем с отдельный тейбл и сортируем по ключу последовательности? В кортеж первичного можно будет посадить второй очередью timestamp?

Посоветуйте целесообразность использования КХ в следующем проекте: Приложением (.NETCore или . NET Framework) будут опрашиваться ежесекундно (1-3 сек.) приборы ADAM и количество параметров будет около 100-150 шт. В клиентском приложении необходимо показывать как текущие мгновенные значения (sic!) так и различные средние за час, день, месяц и др. Может вместо КХ что-то другое посоветуете? Спасибо!

Ответ зависит от того:
- чем не устраивает текущее решение и пробовали ли использоват mysql/postgre
- сколько данных

Проект пока в стадии концепции. Хотелось бы получить экспириенс с использованием Column-oriented субд...

И да. У меня получается вставка данных OLTP, что для КХ не есть хорошо?

Попробуйте решить в лоб, с КХ или нет - не так важно. У вас сейчас нет четких требований по данным, потому сложно что-то советовать

Что такое "вставка данных OLTP"?

Смотря какие запросы нужны. Если цель — забирать комменты по post_id, то достаточно иметь табличку Comment(post_id, timestamp, ....) с order key = (post_id, timestamp)

Хотел сказать - частая вставка данных небольшими порциями.

Да, запросы это только забирать коменты, их количество и средние по всем постам юзера. Без извращений)

А что за "средние по всем постам юзера"?

Среднее количество комментов к посту. За все время и аггрегированно по месяцам.

select count(), toYYYYMM(ts) as month WHERE post_id = ? GROUP BY month with totals

Да,спасибо. В моей неискушенной голове это примерно так и выглядело. Знакомые хвалили КХ, но сказали что надо майндсет менять чтобы с ним эффективно работать. У меня только с постгресом опыт)

В общем случае вставлять "большими" вставками не проблема. Просто у КХ есть специфика и без особой надобности нет смысла внедрять. А так - велкам

Да, пугает то, что в КХ нельзя часто вставлять данные мелкими порциями, например по 50-100 строк, как пройдет 1 цикл опроса приборов.

На самом деле можно. Каждая вставка создает парт на диск, что добавляет работу фоновому мерду и усложняет запрос на чтение свежих данных. Если вам прям нужно так часто вставлять - придёться подкручивать настройки фоновых мерджей. Иначе в дальнейшем будет деградация из-за большого кол-ва партов

Угу. Нужен агрегатор между КХ и вами.

Либо ещё можно не закрывать реквест с INSERT-ом долгое время, пока данные не накопятся, сервер забуферизует

Длинные коннекты я бы не советовал, а вот взять готовый батчер или написать свой - да

А что не так с длинными коннектами?

А зачем они нужны если как минимум есть готовые батчеры?

Например связь моргнёт между вами и ДЦ. И в батчерах есть сброс по таймауту - его руками писать не нужно

Затем, чтобы не использовать батчеры. С батчерами проблема, что нет обратной связи.

У нас перед записью в КХ "транзакционный" накопитель, кторый умеет на диск скидывать, если кх недоступен. Локально убиваются только те данные, по которым 200 вернулся из КХ с кворумной ставкой

В этом кейсе батчер понижает надёжность

А чем ваш транзакционный накопитель отличается от батчера?

Транзакционностью

+ если батчер за сетью, то надёжностью сети

Коллеги,не могу разобраться с ситуацией: есть распределенная таблица, которая смотрит на 3 шарда, данные на каждом шарде разные. Делаем SELECT из распределенной таблицы и каждый раз получаем разный результат(всего есть 2 записи, поочередно возвращается то одна,то две записи).
select * from table_2
where guidch = '0387d447-6fd4-4b9a-b226-a54a5b25e7f0'
В логах чисто, ошибок нет, версия clickhouse 19.1.6, конфиги тоже все перепроверил. Куда копать?

покажите конфиг кластера

и определения таблиц

<yandex>
<remote_servers>
<logs>
<shard>
<weight>1</weight>
<internal_replication>false</internal_replication>
<replica>
<host>kk-clickhouse-db02</host>
<port>9000</port>
</replica>
<replica>
<host>kk-clickhouse-db03</host>
<port>9000</port>
</replica>
</shard>
<shard>
<weight>1</weight>
<internal_replication>false</internal_replication>
<replica>
<host>kk-clickhouse-db04</host>
<port>9000</port>
</replica>
<replica>
<host>kk-clickhouse-db05</host>
<port>9000</port>
</replica>
</shard>
<shard>
<weight>1</weight>
<internal_replication>false</internal_replication>
<replica>
<host>kk-clickhouse-db06</host>
<port>9000</port>
</replica>
<replica>
<host>kk-clickhouse-db07</host>
<port>9000</port>
</replica>
</shard>
</logs>
</remote_servers>
</yandex>

реплики пересекаются? такое поведение может быть, если distributed-таблица выбирает из шардов 1,2,3 реплики, которые по факту содержат данные < 3 _разных_ шардов

как создана таблица?

Таблица в каждом узле кластера

CREATE TABLE gis.table_2 (
pguid String,
podguid String,
pebpp_id String,
pname String,
p_gun_guid String,
p_gun_pebpp_id String,
p_gun_name String,
regcode String,
regname String,
regtofk String,
regtofkcode String,
ptcode String,
has_indirect_members Int32,
aname String,
aabbreviation String,
guidch String,
guidpay String,
guidinc String,
guidsrv String,
bill_id String,
discount_value Float64,
reconcile_payments_status Int32,
reconcile_incomes_status Int32,
amount Float64,
amount_pat Float64,
amount_inc Float64,
register_date DateTime,
open_date DateTime,
close_date DateTime,
status Int32,
is_active Int32,
kbk String,
type Int32
) Engine = ReplicatedMergeTree('/ch/tables/{shard}/table_2', '{replica}')
PARTITION BY toDate(register_date)
ORDER BY guidch;

Распределенная таблица.

CREATE TABLE gis.table_2 (
pguid String,
podguid String,
pebpp_id String,
pname String,
p_gun_guid String,
p_gun_pebpp_id String,
p_gun_name String,
regcode String,
regname String,
regtofk String,
regtofkcode String,
ptcode String,
has_indirect_members Int32,
aname String,
aabbreviation String,
guidch String,
guidpay String,
guidinc String,
guidsrv String,
bill_id String,
discount_value Float64,
reconcile_payments_status Int32,
reconcile_incomes_status Int32,
amount Float64,
amount_pat Float64,
amount_inc Float64,
register_date DateTime,
open_date DateTime,
close_date DateTime,
status Int32,
is_active Int32,
kbk String,
type Int32
) Engine = Distributed(logs, gis, table_2, rand()) ;

А как это проверить?

кстати, а как это CREATE TABLE gis.table_2 и там, и там? одна распределенная таблица на отдельном хосте?

Да, распределенная таблица на отдельной ноде

а макросы правильно проставлены?

да, проверял

Добрый день! Подскажите, пожалуйста, есть запрос:

SELECT
SUM(sign) AS divisor,
if(toUInt8(divisor), SUM(amt * sign) / divisor, toDecimal128(0, 4)) AS result
FROM tmp

divisor = 0, amt типа Decimal128(4)

Получаю ошибку DB::Exception: Division by zero.

Как обойти?

where
value_with_zero != 0

или это так не работает хД ?

агрегат под WHERE?

топорно, но если деление идёт после агрегации то можно наверное вынести деление в следующий запрос и там проверить на 0
или в HAVING проверить

ребят, а кто-то знает как при таком инсерте заменить одно поле с date на текущую дату? желательно чтобы не перечислять все остальные поля, так как там их овердофига

INSERT INTO log_database.reports SELECT * FROM default.reports;

@ztlpn не подскажите?

для этого есть алтер апдейт

это как?

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

таблички идентичные

Можно писать одновременно какое-то поле и звёздочку, но тогда колонок больше, чем нужно. А убрать какую-то колонку из звёздочки вроде бы нельзя. Так что наверно всё-таки придётся перечислить все поля.

А как узнать, к кому старается подключиться КХ? В логах:
2019.03.06 14:34:51.698318 [ 45 ] {} <Error> ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer
2019.03.06 14:34:52.080308 [ 46 ] {} <Error> ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer
2019.03.06 14:35:17.058880 [ 47 ] {} <Error> ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer

https://clickhouse.yandex/docs/ru/query_language/alter/

ALTER TABLE [db.]table UPDATE column1 = expr1 [, ...] WHERE filter_expr
там будет вот про такую конструкцию

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

Мне нужно до вставки заменить

ClickHouse не умеет short-circuit условных выражений. То есть для if сначала вычисляются левая и правая ветки для всех строк, а потом склеиваются в зависимости от значения условия. Так проще и в большинстве случаев быстрее.

т.е. единственный выход только через подзапрос?

кривовато, но можно сделать, чтобы там, где divisor=0, он был бы равен например 1 :)

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

раскрывайте звёздочку

=)))

тогда если человеку лень могу предложить ему
сделать alter add и добавить колонку с дефолт датой нужной

https://github.com/yandex/ClickHouse/issues/4411

Всем привет!

Таблиц много. Полей ещё больше, не Охота

Ребята, не заводится стандартный Tabix

Include not found: networks
Пишет в статусе

поручите это какому-нибудь скрипту

Include not found: clickhouse_compression

вытащи из схемы таблицы все поля и регулярками в питоне или тырнетах или в саблайме подгони в инсерт, должно быть не трудно =)
ну и потом ручками одно поле заменить на нужную дату

SELECT
if(toUInt8(2),1/1,1/0) as text
подобный запрос выполняется, но для 0 он возвращает inf возможно нужно просто этот момент обработать ?

в этом запросе float а не decimal

ребят, как завести clickhouse

никак не получается

Нашли проблему, данные на нодах разные, отсюда и разные результаты.

Include not found: clickhouse_remote_servers

Что за ошибка?

кто знает?

Не настроены clickhouse_remote_servers, нет xml файла. Если нет репликации можно закоментировать

https://clickhouse.yandex/docs/ru/operations/server_settings/settings/#remote-servers

спасибо разобрался))

доброго времени дня,
загружаем в distributed ReplicatedMergeTree таблицу несколько сот файлов через cat file_XXX.tsv | clickhouse-client --query="INSERT INTO tmp.table FORMAT TSV" параллельно в несколько десятков потоков и получаем дубликаты, добавили в таблицу поле с именем файла и партиционировали по нему, видно что первые несколько десятков файлов загружаются нормально, а потом начинают появляться дубликаты, и концу - в почти во всех партициях есть дубли
никто с таким не сталкивался - как с этим бороться

добрый вечер. А подскажите пжл какой нибудь эффекивный способ удалить дубли, может готовыми командами КХ? очевидный вариант создать новую таблу без дублей, затем перелить, удалив - не оч красивое решение.

OPTIMIZE TABLE FINAL DEDUPLICATE; - не дает нужного результата

что вы делаете при ошибке в 'cat file_XXX.tsv | clickhouse-client --query=' ? повторяете? в КХ нет транзакций и атомарности.
distributed ReplicatedMergeTree -- у вас один шард и одна реплика?
партиционировали по нему -- что это значит? partition by filename ?

alter delete ?

>OPTIMIZE TABLE FINAL DEDUPLICATE; - не дает нужного результата
один шард? размер парта? таблица replacing ?

Оптимизация даст результат только конкретной таблицы и конкретной ноды. Если tbl - таблица на ноде, а tbls - дистрибуция, то оптимизировать нужно на каждой ноде конкретную таблицу, т.е. tbl.

нет - не повторяем, кластер - 4 машины, 2 шарды, 2 реплики, да partition by filename - чтобы можно было детачить и удалять в случае неуспеха

так и делаю. То есть для каждой локальной таблы, но ничего не меняется.

И ошибок нет, а у вас лог в режиме трейса?

так дубликаты у вас есть внутри 1-го шарда?

вообще ничего. Очень странная команда

OPTIMIZE TABLE t_local PARTITION 2019-03-05 FINAL DEDUPLICATE;

OPTIMIZE TABLE t_local PARTITION (2019 - 3) - 5 FINAL DEDUPLICATE

Ok.

0 rows in set. Elapsed: 0.009 sec.

и 0 эффекта

имя партиции смотрите в system.parts оно либо 20190305 либо '2019-03-05' либо 201903

да, верно. спс. но результат тот же, увы

OPTIMIZE TABLE t_local PARTITION 20190305 FINAL DEDUPLICATE

Ok.

0 rows in set. Elapsed: 0.049 sec.

все это странно, я бы поискал ошибку у себя в коде, залогировав cat file_XXX.tsv | clickhouse-client --query
потом попробовал лить прямо в ReplicatedMergeTree на одном шарде, возможно ошибка в описании кластера, но тяжело понять как так ошибится, чтобы дубликаты появлялись не сразу.

вопрос снят. Спасибо @BlackMerlinKR Как озказалось не работает для обычных mergeTree

спасибо - будем экспериментировать - кстати удачно в соседнем сообщении увидел слово DEDUPLICATE - выполнил с ним OPTIMIZE - как минимум дубли получается убрать - плохо что этого в документации нет
да - запросы логировали - в них в written_rows совпадает с кол-вом строк в файле, хотя счас нашел несколько дублированных инсертов

Нельзя же для параметра движка использовать DateTime, как нибудь так MergeTree(toDate(dateTime_colum),(ID,toDate(dateTime_colum)),8192) ?

формально это вообще не про дубли.

есть движок replacingmergetree , в нем есть понятие версии, новая версия записи в нем перетирает старую.
почитайте, и потренируйтесь [ select from table ] vs [ select from table final ]

OPTIMIZE TABLE FINAL вызывает процесс слияния который оставляет последнуюю версию (кроме случаев [длинный список] )

DEDUPLICATE-устаревшая фигня которая вообще ни на что не влияет.

в новом синтаксисе
create table aaaa (поля)
partition by toYYYYMMDD(some_datetime_column)

для месячных партиций (по старому)
partition by toYYYYMM(some_datetime_column)

Спасибо.А он же этот столбец всё равно создаст явно или не явно, то есть лучше новый столбец завести?

никто ничего не создаст, откуда такие фантазии?

where dateTime_colum >= будет исключать партиции из-за максимального и минимального значений (атрибутов партиции) поля dateTime_colum (по которому партиционировано)
индекс (order by) будет работать из-за монотонности? toYYYYMM(some_datetime_column) -> some_datetime_column

Спасибо, просто предположение, в импале если подобным методом создавать партиции, появляются новые столбцы. По итогу не заводить новый столбец под дату, а выводить для партицирования из тс - есть ок?

Да, ок

Окей, тогда спасибо

у нас и 2-я таблица с replacingmergetree есть - там тоже дубли появляются, но в ней OPTIMIZE ... FINAL дубли убирал, а на просто mergetree OPTIMIZE FINAL не проводил к дедупликации, а после добавления DEDUPLICATE - дубли исчезли (я прада пока только на одной партиции оппробовал) - чудеса, кликхаус 19.1.6

OK, это интересно, я думал что deduplicate атавизм для replacing , был момент когда оставались версии (дубли) если они были в одном (последнем) парте.

/stat

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

ALTER TABLE default.table MODIFY COLUMN username Nullable(FixedString(64))

не работает

Ошибка какая?

Code: 44, e.displayText() = DB::Exception: ALTER of key column username must be metadata-only

колонка в ключе? Покажи show create table

CREATE TABLE default.table (id Int32, username FixedString(8)) ENGINE = MergeTree PARTITION BY tuple()
ORDER BY
username SETTINGS index_granularity = 8192

Поле типа Nullable нельзя включать в индексы, а у вас tuple партицирование

Кроме того использование Nullable может снижать производительность

Можно добавить колонку с датой и сделать партицирование по ней?

Или принципиально нужна такая схема

не, все хорошо, спсибо

инсертить лучше массивом или по одной?

строке

https://clickhouse.yandex/docs/ru/query_language/insert_into/
Замечания о производительности¶
INSERT сортирует входящие данные по первичному ключу и разбивает их на партиции по месяцам. Если вы вставляете данные за разные месяцы вперемешку, то это может значительно снизить производительность запроса INSERT. Чтобы избежать этого:

Добавляйте данные достаточно большими пачками. Например, по 100 000 строк.
Группируйте данные по месацам самостоятельно перед загрузкой в ClickHouse.

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

А вот время экономится

Так что, если данных много, подбирайте пачку из диапазона 50к-200к строк

👍

А предсортировка всё ещё помогает ускорить импорт? Или в 19.3.6 не актуально?

При составном ключе партицирования