привет. внезапно прекратились мержи, в логах КХ ошибки типа:
2018.08.01 05:04:46.025443 [ 53 ] <Warning> local.clickstream_new (StorageReplicatedMergeTree, PartCheckThread): Found parts with the same min block and with the same max block as the missing part 201807-0_783_809_5. Hoping that it will eventually appear as a result of a merge.
в папке таблицы набралось много папок 201807-0_XXX_XXX_0.

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

куда смотреть?

scrape_uri - это адрес КХ (обычно 127.0.0.1), в прометеусе вы можете руками прописать адреса экспортеров, либо использовать консул и регать экспортеры там, если у вас окружение динамическое то лучше использовать консул и там регистрироваться, если нет то просто пропишите в него адреса экспортеров.

Добрый день!
Есть столбцы (string, hash): data1, data2, data3, и другие столбцы
Нужно делать поиск по data1 ИЛИ data2 ИЛИ data3
Как лучше организовать таблицу или таблицы, чтобы CH максимально хорошо и быстро искал нужные строки?

Добрый день, коллеги!
Делаю выборку:
select request_id
from my_table
where request_id = '59f911f179bea204f6890ea5'
Результат - одна строка.

Затем подставляю в селекте вместо request_id некоторую константу, но с тем же условием:
select 'new_request_id' as request_id
from my_table
where request_id = '59f911f179bea204f6890ea5'
Результат - пусто.

Что бы это могло быть?

Так работает?
select 'new_request_id' as request_id2
from my_table
where request_id = '59f911f179bea204f6890ea5'

Проще говоря он реплейсит request_id на new_request_id

Не делайте алиасы с названием колонок

Да, если присваивать другой алиас, то всё работает нормально.

Кто-нибудь использует кластер в который интенсивно пишут? Раз 50-100 в минуту я имею в виду.
Попробуйте стопануть одну реплику, у меня на второй прекражаються мержи и через 2-3-5 минут привет исключение о медленных мержах (притом такое поведение даже если все вьюхи убрать)

Может есть какая-то настройка чтобы оставшаяся в живых реплика не прекращала мержить?

Таблица причины почему мержи не идут полна такого
│ MetricsFree │ Not merging into part c1d05dd4c541bdc14737a222ad2b09b1_1147_1561_155 because part c1d05dd4c541bdc14737a222ad2b09b1_1147_1560_154 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused

и такого
│ Metrics │ Not merging into part babccf0c7ab1c3af920fb405ca79c901_36891_36895_1 because part babccf0c7ab1c3af920fb405ca79c901_36892_36892_0 is not ready yet (log entry for that part is being processed). │ Code: 234, e.displayText() = DB::Exception: No active replica has part babccf0c7ab1c3af920fb405ca79c901_36891_36895_1 or covering part, e.what() = DB::Exception │

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

А он поломан. Не критично?

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

Если insert_quorum поставлю в 2 (2 реплики) то перестанет писать сразу же как я остановлю 1 реплику, верно?

Подскажите, а имеет смысл вытаскивать в primary key поле eventDate если в WHERE оно фильтруется везде от начала месяца до конца? Будут ли использоваться оптимизации засечек при джоинах?

Да

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

А не будут проблемы при неудавшихся вставках? Да и много ресурсов на кросс-репликацию.

я обычно делаю что-то типа такого
SELECT
date,
...
FROM
(
SELECT toDate('2018-07-02') + number AS date
FROM system.numbers LIMIT 7
) ANY LEFT JOIN (
...тут запрос, в результате которого могут быть "дыры" в датах...
) USING date

О! Спасибо! Не знал про system.numbers, извращался с range()

Я тоже :)

SELECT
arrayJoin(aligned).1 AS ts,
arrayJoin(aligned).2
FROM
(
WITH
groupArray((ts, value)) AS series,
toDateTime('2018-01-01 00:00:00') AS zero_time,
range(4) AS range,
3600 AS step,
arraySort(arrayMap(pos -> (zero_time + (step * pos), arrayFirst(t -> (t.1 = (zero_time + (step * pos))), series).2), range)) AS aligned
SELECT aligned
FROM timeserie
GROUP BY metric
)

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

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

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

Чтобы отдельные большие значения не так сильно влияли на график

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

добрый день, скажите, возможно ли в будущем использовать удаление для distributed таблиц или иметь возможность на локальных таблицах делать ALTER TABLE DELETE ON CLUSTER test WHERE ...?

а что за where ?

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

так вы таблицу собираетесь удалять или что ?

например, у нас есть distributed таблица, которая размазанная на x серверов

не удалять

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

а удалять часть данных по критерию

в дистрибьютед таблице нет данных же

смотрите, например, мы неправильно залили первый месяц

да это вьюха на локальные таблицы

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

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

ну а зачем для этого нужна дистрибьютед , делайте онкластер на локальные

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

сейчас не поддерживается on cluster для удаления

ON CLUSTER для ALTER DELETE должен поддерживаться

Для альтер вроде поддерживается, по крайней мере все Альтеры я делаю он кластер

delete?

Ну и делете наверно мне кажется тоже

наверное синтаксис у меня неверный, спасибо

Привет всем. За неделю запутался, читая чат. У нас есть кластер из 2-х машин КХ и 3-х машин ZK. Есть ReplicatedMergeTree, на которую навесили MaterializedView с движком MergeTree. Если данные попали в ReplicatedMergeTree, есть ли гарантия, что они окажутся и в MaterializedView, если все машины живы? Я понимаю, что в случае вылета КХ или ZK последствия могут быть рандомными, но если без вылетов?

В MV данные попадут только на той машине где запись, делайте MV реплицируемыми

О. Кажется, именно это мы и продолбали. Спасибо. :)

Вот тут можно посмотреть про механику https://events.yandex.ru/lib/talks/5800/

Спасибо

как-то странно, когда сделали 5 машин вместо 2, но при выходе из строя одной последствия рандомные. получается менее устойчиво, нет?

Это не 5 вместо 2. Это 2 + 3. Даже при самой крутой и стабильной архитектуре вылет любого сервера может привести порою к рандому, если случится в "удачное" схождение звёзд.

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

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

На практике, конечно, это всё стоит проверить :))

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

На той, где их больше, насколько я понимаю

А репликация через replicated.... таблицы или детская?

Replicated

Зукипер есть?

Да

А как проверяли что не совпадает? Т.е. для всяких replacing и agregating резултат select count() может зависеть от того завершился merge или нет.

sum по основным столбцам

и заливка остановлена? реплика видит данные с задержкой, если запрос sum идет 10 сек., будут разные результаты

Ну там значительно отличается

Ничего не стопил пока

а что показывает select from system.parts про партции этой таблицы? на обоих репликах

Ну количество строк в таблице system.part разное

а replication_queue есть запросы на репликацию? странно это все

Вот тут куча строк и в поле last_exception connection timeout ошибки

Трабла со вчерашнего вопроса про dns, спасибо! Надо обновиться

Друг, спасибо тебе огромное!))))

ну значит реплика не может подключится к брату по http (9000) ?

Уже все)

можно мониторить типа :
'rep_future_parts')
sql="select sum(value) from (select sum(future_parts) as value from system.replicas union all select toUInt64(0) as value)"
;;

'rep_parts_to_check')
sql="select sum(value) from (select sum(parts_to_check) as value from system.replicas union all select toUInt64(0) as value)"
;;

'rep_stalled')
sql="select sum(value) from (select count(*) as value from system.replication_queue where num_tries > 100 union all select toUInt64(0) as value)"
;;

Ок, спасибо)

Здравствуйте.
Подскажите пожалуйста,
Если гаснет нода zk follower - то clickhouse (если он подключен именно к этой ноде) теряет один пакет и переподключается.
Если гаснет нода zk leader то таблицы переходят в readonly до сообщения в логе ZooKeeper session has expired. Switching to a new session. (60 секунд до этого момента проходит). Что яч делаю не правильно. Подскажите пожалуйста.

А что не так?

Не хочется 60 секундного ридонли

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

А имеет смысл уменьшать zookeeper_session_expiration_check_period ? И чем это грозит?

Нет, Зукиперы не сильно часто падают, а минута в RO тоже не так уж и много, легко дозалить данные которые накопились.

Попробовал "insert_quorum" как тут советовали.
В логах каждого сервера некоторое кол-во таких сообщении валится
2018.08.01 15:46:30.776377 [ 420 ] <Error> MetricsDistributed.Distributed.DirectoryMonitor: Code: 286, e.displayText() = DB::Exception: Received from 10.1.2.57:9000. DB::Exception: Quorum for previous write has not been satisfied yet. Status: version: 1
2018.08.01 15:47:21.476415 [ 421 ] <Error> MetricsDistributed.Distributed.DirectoryMonitor: Code: 286, e.displayText() = DB::Exception: Received from 10.1.1.183:9000. DB::Exception: Quorum for previous write has not been satisfied yet. Status: version: 1
2018.08.01 15:47:41.518425 [ 5462 ] <Error> executeQuery: Code: 286, e.displayText() = DB::Exception: Another quorum insert has been already started, e.what() = DB::Exception (from 10.1.1.249:52124) (in query: INSERT INTO MetricsDistributed FORMAT TabSeparated), Stack trace:
2018.08.01 15:47:41.578393 [ 5462 ] <Error> HTTPHandler: Code: 286, e.displayText() = DB::Exception: Another quorum insert has been already started, e.what() = DB::Exception, Stack trace:

И самое непоиятно что появились опять дуюликаты хотя вьюх нету

В коде нашел что транзакция откатывается но откуда тогда дубликаты?

else if (multi_code == ZooKeeperImpl::ZooKeeper::ZNODEEXISTS && failed_op_path == quorum_info.status_path)
{
transaction.rollback();

throw Exception("Another quorum insert has been already started", ErrorCodes::UNSATISFIED_QUORUM_FOR_PREVIOUS_WRITE);
}

Сообщения фиг с ними, задержки сети или еще что-нибудь в растпеделенной системе пусть будут
Но эти дубликаты в различной вариации меня немного измотали

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

Да, а как иначе если батч не прошел?
Replaced движок это борьба с последствиями

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

Скажите пожалуйста, а почему в документации нету описания arrayReduce?

Вылез нюанс что если писать асинхронно и стопануть одну из 2 реплик то перестает мержить

В свою очередь после Х немержей шард перестает отвечать и кластер полудоступен
Хотя вроде как потеря реплики не должна к такому приводить.

Ок, сделали синхронную запись, опять 25, при остановке реплики вылезли дубликаты (видимо не только нет атомарности между таблицей и вьюхой но и между репликами)

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

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

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

а я не понимаю, что у вас за ошибки при инсертах, из-за которых вы батчи повторяете?

>Да, а как иначе если батч не прошел?
>Replaced движок это борьба с последствиями
>Одна причина это вьюхи, от них со скрипом отказались и
>выкручиваемся без них
все это очень странно, у меня миллиард строк в день, все обвешено вьюхами, проблемы бывают ну раз в году может и то обычно я сам виноват.

ноду стопали?

постоянно и падают и стопаю, я правда не пользуюсь записью через distributed

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

я могу конечно и это еще попробовать, но мои ошибки которые я тут выкладываю вроде не намекают что это может быть корень проблем

тут и тут описал
https://github.com/yandex/ClickHouse/issues/2765
https://github.com/yandex/ClickHouse/issues/2755

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

так а что с:

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

Так я ответил что этот движок использовать не будем

это уже последствия, а не причина

Без вьюх дубликатов нет (они есть или с вьюхами или если insest_quorum выставить в 2 например, как я написал выше причина видимо одна, неатомарность вставки со вьюхами (это подтверждено разработикми) и с репликами видимо тоже атомарности нет и в одну проходит а в другую нет)

ну все ясно мне, я ни хера не понял.

Не совсем понимаю о какой причине речь идет, я не разработчик КХ, точно указать причину мне сложно.

Или вы намекаете что стопать ноду не надо и все будет хорошо? К сожалентю в реальности они постоянно ломаються (сервера я имею в виду)

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

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

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

давайте по пунктам напишу?

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

конечно

и вы вставляете второй раз теми же блоками, какими вставляли в первый?

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

Алексей мой код проверил

Вроде бы не нашел явных багов

Вставляем точно тот же кусок

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

и это работает но только если нет вьюх и нет синхронной репликации как выяснилось

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

Я не могу ответить на вопрос о корне проблем. Если бы я знал куда мы не помещаемся то я бы постарался это исправить

Вставок около 100 в минуту

по 40-50к строк

Как я понял с вьюхами проблема известная и она не в настройках и блоках

вы можете посмотреть, про какие 100 блоков знает КХ, они в Зукипере лежат.
Но при 100 вставках в минуту я бы не рассчитывала на дедупликацию в КХ

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

Пример
1. Вставка в осн таблицу прошла
2. Во вьюху упала
3. Вернули исключение на клиент
4. Клиент перевставил
5. В осн прошла вставка
Бинго у нас дубликаты

Мне то что я вам выше написал объяснили разработчики
Если это не так то давайте с вами попробуем понять причину и главно ечто делать

100 можно увеличить как-то до 1000 и проверить?

Вставка в таблицу и вью не атомарная, это факт, с этим надо жить.
Придумайте другой способ обработки ошибок, не вставляйте второй раз.

так я ж без понятия что и куда вставилось а что и куда нет
если в исключении например будет информация что 1-Т вставилось а Т-П не вставилось и куда (в какую вью или таблицу) то я с удовольствием обработаю
а без этой информации не представляю как.

при какой частоте вставки можно расчитывать по вашему? попробую повоевать в этом направлении

так то что я по пунктам написал ложное предполажение и дубликаты не из-за этого?

пролейте свет пожалуйста

Если вы вставляете раз в минуту, то КХ будет помнить про блок примерно 100 минут.
Если вы вставляете раз в секунду, то КХ будет помнить про блок примерно 100 секунд.
Как долго КХ должен помнить про блоки, чтобы вы с уверенностью могли повторять вставку?

идея понятно

спсб

помнит распределенная таблица или каждая локальная?

помнит нода в Зукипере, т.е. таблица RepilcatedMergeTree

но если вы вставляете в Distributed, как вы можете быть уверены, что у вас блоки одинаковые?

не знаю как ответить но мне пояснили что это не важно

(сейчас переделываю на вставку в локальную таблицу, как я понял вставка должна быть в одну и ту же RepilcatedMergeTree таблицу? есть разница на какую реплику? )

нет, у разных реплик одной таблицы нода в Зукипере одна и та же

спсб

Но я не могу представить, как могут получиться одинаковые блоки при вставке в Distributed таблицу, которая шардирует по rand()

судя по тому что нода в ЗК одна то и шарда не важна, тоесть можно переслать на любую ноду кластера
это облегчает

я тут некопенгаген ))

нода в ЗК - это первый параметр у ReplicatedMergeTree, по идее на разных шардах он разный должен быть

Вы перевстявляете в ту же шарду или все равно куда?

я не пользуюсь дедупликацией и вставкой в distibuted поэтому мне параллельно в какой шард и в какую реплику повторять вставку.

я вообще не понимаю откуда такие требования к точности в биг дата, вон дремель возращает результат с 99.7% шардов, ну и точность запроса будет 99.9%, да пофиг.

если надо 100%, храните в mysql

Вроде всё-таки big data не включает в себя потерю данных. Ну т.е. у меня, к примеру, ответное непонимание. Продолбать десять лямов записей? Пф, это же биг дата. :)

Спсб за совет. У всех разные кейсы
Я не вижу что хочу чего-то невероятного
Просто пытаюсь разобраться
Если вы уже разобрались я искренне рад
Мне пока до конца не удалось, перебираю варианты

Я тоже не могу себе позволить такого
Не всем везет

КХ не гарантирует целостность данных. Там нет Durability (в терминах ACID).
Поэтому потери гарантированы самим дизайном.

Если эти потери прям фактически гарантированы, стоило бы на главной странице рядом с "Не тормозит" большими буквами добавить "и не сохраняет", раз уж ACID так сурово не соблюдается. Но мне пока думается, что всё менее трагично и D теряется в кейсах, которых можно избежать. Правда, их описания в доке поди найди.

хм, а что какая-то буква из ACID соблюдается в КХ ?

кейс очень простой, делаем insert, видим OK, тут же посылаем kill -9 демону КХ, стартуем и не видим проинсерченного.

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

Емнип, неделю назад тут отвечали, что ответ 200 ОК означает таки сохранение на ноде.

Юзает кто-нибудь Tableau Server на линуксе в связке с ClickHouse?

У меня это говнище нивкакую не заводится

Я ОРУ!

yandex/ClickHouse was tagged: v18.6.0-stable
Link: https://github.com/yandex/ClickHouse/releases/tag/v18.6.0-stable
Release notes:
Auto version update to [18.6.0] [54401]

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

Господа, пытаюсь получить суммарную скорость чтения с дисков: http://paste.org.ru/?b8oeay
Либо я что-то не понимаю, либо runningDifference как-то странно работает.

Попробуйте в подзапросе сделать ORDER BY datetime, а уже над результатом подзапроса выполнить runningDifference

Хм... Так работает. Осталось сделать, чтоб ещё и для N хостов в IN сработало...

Привет, товарищи.

Вопрос: в каком случае КХ будет быстрее искать?

- поиск гуида в строке ( position("guid1,guid2,guid3", "guid2") )

- поиск гуида в массиве строк ( has(["guid1","guid2","guid3"], "guid2") )

Привет.
Есть 2 реплики с таблицей ReplicatedMergeTree.
Хочу выполнить удаление партиции: ALTER TABLE table ON CLUSTER cluster DROP PARTITION 'partition'.
Возвращается ошибка "Password required for user default".
Мне понятно что тот сервер, на котором я выполняю запрос не является лидером, но в конфигурации кластера я задал для каждой реплики user и password (к тому же user не называется default). В users.xml так же присутствует используемый пользователь.
Версия Clickhouse 1.1.54388.
Подскажите пожалуйста, в чем может быть проблема?

Мы в таком случае заменили гуиды на инты (есть отдельный словарь) и используем второй вариант с массивами

Тяжело от гуидов уйти к сожалению, все ими пронизано.

а в 2 uint64 преобразовать не получится?

Второй вариант лучше.

как вариант, другими словами 2 uint64 дешевле строкового гуида?

Я просто помню постулаты КХ - храните строками если надо, он справится

понял.
предложенные преобразования guid -> int коснутся объема данных точно, а производительность сильно улучшит?

я не знаю, надо проверять. преобразование-то не бесплатное будет.

спасибо! буду играться. Начну с 2 варианта, как Алексей предложил.

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

https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/

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

Спасибо большое, ребята!

Нет. А можно больше инфы что и где не заводится?

Подскажите в 18.6.0 можно сделать JOIN ON таблицы саму на себя?

SELECT
f.date,
s.date
FROM default.rep_price AS f
ANY LEFT JOIN default.rep_price AS s ON date = second.date

Received exception from server (version 18.6.0):
Code: 47. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Unknown identifier: second.date.

а почему second вместо s?

опечатка)

SELECT
f.date,
s.date
FROM default.rep_price AS f
ANY LEFT JOIN default.rep_price AS s ON date = s.date

Received exception from server (version 18.6.0):
Code: 47. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Unknown identifier: s.date.

SELECT *
FROM test1 AS f
ANY LEFT JOIN test2 AS s ON f.id = toUInt32(s.id + 1)

Exception on client:
Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, 127.0.0.1
А вот так вешается сервер - условие ON - заведомо не выполнимо

Привет, может кто-нибудь подсказать по подключению mongo-словаря?
В аттрибутах обязательно необходимо перечислить все колонки таблицы, и должен ли быть object_id частью ключа?

Не подскажите какой официальный способ уменьшить кластер?

Например с 8 шард до 6

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

с JOIN ON напортачил с движками таблиц, на MergeTree всё корректно работает. Будет ли работать для ReplicatedMergeTree?

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

Rename вроде был.

Вижу только для таблиц.
Для колонок нет. (или невнимательно смотрю)

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

Ок, спасибо большое

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

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

Я думал уже поправили это, у нас просто нет пароля для default и нет проблем )

Ребят, подскажите, диалект hibernate для КХ никто не пилит?

"Пропал дом"

Я бы попробовал 2 вещи:

1. Руками повставлять в remote таблицы на других серверах, пошардив самому при выборке как-нибудь
2. Попробовать clickhouse-copier, но я сам не пробовал 🙂

Уже на 2 нацелились
Попробуем в понедельник
В четверг что-то сцыкотно ))
Спсб

Перестать писать в 2-а шарда, а данные из него перекинуть через distributed таблицу (insert into distributed select from local) в оставшиеся

Всем привет! В system.parts есть два поля - "partition" и "partition_id", хотя в документации описано только первое, а второе вроде-как добавлено относительно недавно. Отсюда 2 вопроса: есть ли в этом скрытый смысл? Стоит ли ожидать, что "partition_id" будет со временем выпилено?

Вот тут в конце немного про разницу есть: https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/

Она становится важна при всяких экзотических выражениях партиционирования. Например партиционируете по строке, тогда partition это будет сама строка, а partition_id - её хэш. И в именах кусков будет именно partition_id.

Благодарю. Если я всё верно понял, что для alter table правильнее использовать значение "partition".

Можно и то и то, как удобнее. Если пишете например ALTER TABLE t DROP PARTITION expr, то expr это константное выражение, значение которого должно быть равно значению partition, которую вы хотите дропнуть. Или можно написать ALTER TABLE t DROP PARTITION ID 'id', если вы вытащили id из имён кусков.

а есть ли какая-то возможность, что у нас после insert into table ... values данные при селекте не видны, а в clickhouse-server.err.log все пусто на этот счет?

Доброго времени суток! Ребят можете подсказать не могу разобраться, с резервным копированием и восстановлением в КХ. Делаю по вот этой статье https://ruhighload.com/%D0%91%D0%B5%D0%BA%D0%B0%D0%BF+%D0%B8+%D0%B2%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5+%D0%B2+clickhouse. Не могу понять как сделать ATTACH партиций

Аттач партитион и дата партиции

А если у меня так выливается?

─partition─┬─table─────────────┬─database───┐
│ 201803 │ test │ production │
│ 201803 │ test │ production │
│ 201804 │ test │ production │
│ 201804 │ test │ production │
│ 201804 │ test │ production │
│ 201805 │ test │ production │
│ 201805 │ test │ production │
│ 201805 │ test │ production │
│ 201805 │ test │ production │
│ 201805 │ test │ production │
│ 201806 │ test │ production │
│ 201806 │ test │ production │
│ 201806 │ test │ production │
│ 201807 │ test │ production │
│ 201807 │ test │ production │
│ 201807 │ test │ production │
│ 201807 │ test │ production │
│ 201807 │ test │ production │
│ 201807 │ test │ production │
│ 201807 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201808 │ test │ production │
│ 201803 │ test_backup │ production │
│ 201804 │ test_backup │ production │
│ 201804 │ test_backup │ production │
│ 201805 │ test_backup │ production │
│ 201805 │ test_backup │ production │
│ 201806 │ test_backup │ production │
│ 201806 │ test_backup │ production │
│ 201806 │ test_backup │ production │
│ 201806 │ test_backup │ production │
│ 201806 │ test_backup │ production │

при таком запросе

SELECT partition, table, database FROM system.parts WHERE active AND database = 'production';

JFYI, в 18й есть регрессия, distinct в MV ломает результат.
https://github.com/yandex/ClickHouse/issues/2795

А что не так?

Я тут вроде разобрался

подскажите что-то поменялось в формате config-file для clickhouse-client?
старый config.xml файл с настройками перестал отрабатывать после обновления с 1.1.54385 на 18.6.54401, вернее <host>clickhouse-srv1</host> подхватывается а <user>|<password> похоже нет. пытается под default подключиться.

Привет.
В документации Settings сказано, что max_threads "By default, 8".
В исходнике Settings.h иначе — max_threads, 0, "The maximum number of threads to execute the request. By default, it is determined automatically."
В документации бага или таки на каком-то этапе max_threads становится 8 (правда, искал и не нашёл)?

SELECT *
FROM system.settings
WHERE name = 'max_threads'

Row 1:
──────
name: max_threads
value: 20
changed: 0
description: The maximum number of threads to execute the request. By default, it is determined automatically.

Ага, значит, документация.

host и password применяются из файла, а вот user нет.
так работает
clickhouse-client --config-file ./test-ch.xml --user user
а так не работает
clickhouse-client --config-file ./test-ch.xml
...... DB::Exception: Wrong password for user default.
что не так?

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

А то сейчас прикрутил словарь к тестовой таблице и понял что условия where надо либо через ид писать либо вызывать dictGetString на колонке и сравнивать

в общем случае никак. Для некоторых типов словарей можно сделать таблицу с Engine = Dictionary использовать как таблицу.
Если нужна скорость я бы сделал еще один словарь и там свапнул key -> value.

:( печаль.

А кому не нужна скорость :))) так бы и на постгрес можно остаться

а в чем проблема? В любом случае будет медленно

select *, getDict( , key, ) fx
from table
where fx = ....

что этак

select *
from table
where getDict( , key, ) = ....

что

select *
from table
where key = (select key from dicttable where = ...)

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

Flat

а ну тогда можно

CREATE TABLE dictTable ( поля) ENGINE = Dictionary('словарь');

мы просто базу создаем
create database dict Engine = Dictionary;
и там все словари будут как таблицы.

Может MV поверх словаря со свапом v->k?

подскажите, есть odbc датасорс, при помощи isql я к нему подключаюсь, пробую его подключить как словарь и кх его не видит, пишет
SQLSTATE = IM002
Native Error Code = 0
[unixODBC][Driver Manager]Data source name not found, and no default driver specified

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

есть подозрение что я упустил что-то в сетапе odbc

и да, ubuntu\postgres

а функция odbc ? а как dsn выглядит ?

[dsb]
Description = PostgreSQL connection
Driver = PostgreSQL
Servername = mypostgres.local
Port = 5432
UserName = pguser
Password = pgpass
Database = mybase
ReadOnly = True

через isql -n dsb подключаюсь, базу вижу

такое ощущение что именно кликхаус не видит odbc драйвер, или что-то в этом роде

https://github.com/yandex/ClickHouse/commit/e6be3df322f24ff3aa9ae9a97b9b01b2c88ab7b0

совпадение?

А как зафорсить кликхаус после падения зукиперов обращаться к зукиперам? Zookeeper восстановили, а кликхаус продолжает накапливать данные в distributed таблице.

Всем привет! вопрос. Сейчас более актуальная документация на английском языке или на русском? или 1:1

то есть в MergeTree не грузит - таблицы в read only, собственно как это поправить можно

пишут на русском, потом переводят на английский

а что в логах?
попробуйте SYSTEM DROP DNS CACHE
ну и рестарт всегда помогает

Всем привет!
пытаюсь заменить influxdb на CH с визуализацией в Grafana - и вот какой возник вопрос:
предположим, есть MergeTree таблица с TimeStamp (DateTime), EventDate (Date) и Millisec (UInt16)
я хочу визуализировать данные с миллисекундной гранулярностью запросом:

SELECT
$timeSeries + Millisec as t,
avg(MyMetricName)
FROM $table
WHERE $timeFilter
GROUP BY t
ORDER BY t

в испекторе получается вот что:

SELECT (intDiv(toUInt32(TimeStamp), 1) * 1) * 1000 + Millisec as t, avg(MyMetricName) FROM myDB.myTable WHERE EventDate BETWEEN toDate(1531719775) AND toDate(1531794372) AND TimeStamp BETWEEN toDateTime(1531719775) AND toDateTime(1531794372) GROUP BY t ORDER BY t

при zoom in в графане на более ччем часовой промежуток поинты пропадают - скорее всего это связано с "where" выражением - там TimeStamp в стандартном epoch timestamp

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

есть какие-нибудь workaround-ы?

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

А может с вершины опыта кто-то может подсказать: мы запустили кластер с шардируемой ReplicatedMergeTree таблицей, но реплика каждого шарда пока в единственном экземлпяре. Зукиперы тоже работают как задел на ближайшее будущее.
Можно ли будет потом подключить шардам реплики, чтобы они как бы стянули данные с шард и стали полными репликами? Какова процедура добавления реплик, когда была раньше всего одна?

Просто создать таблицу, правильно прописав путь в зукипере

Благодарю

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

сделайте zoomIN до проблемы и посмотри какой select генерируется, далее запустить руками в CH, если он ничего не отдает то вот и причина. Может вы попадаете в промежуток где графана ожидает данные, а и нет. например вы собираете данные данные раз в сутки а при zoomin у вас отфильтруется только 8 часов(как пример)

Привет всем!
Кто-то пользовался настройкой target-blacklist graphite-clickhouse ?

Спасибо, решено заменой на where TimeStamp BETWEEN $from AND $to

Данные статичные за июль 2018

Tatiana, мерси!

А почему, если не секрет, хотите уйти от influx?

Боттлнеки по цпу на больших выборках

Ну и СН видится мне пока более перспективным с точки зрения возможностей по агрегации/аналитике

Спасибо

Можно ли с ее помощью скрыть саму метрику из поиска?

Добрый день! Зарегистрировался на мероприятие. Должно ли прийти подтверждение?

Я недели две ждал апрува, иногда в самый последний день апрув прилетает.

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

Я сам с Питера и вот в Москву так ездил ) 50% на 50%. Апрув пришел за день до митапа, но в компании были наготове покупать билеты и согласовали командировку.

В той же ситуации, только из Мск ) Очень хотелось бы получить комментарии от сотрудников Яндекса

больше вопросов было только в анкете jug.ru для людей которые потратили по 50к чтобы получить свое видео

А нет вариантов как в Табиксе сделать окошко результа во внешнем окошке?

Коллеги, добрый день!
А у кого-то удавалось подключить внешний словарь в виде api через http?
Я прописал все конфиги, есть api, которая возвращает json. Делаю запрос к словарю и в итоге возвращается ошибка вида:

Code: 27. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Cannot parse input: expected { before: [{"publisher_id": 999, "id": 1}, {"publisher_id": 5, "id": 2}, {"publisher_id": 756, "id": 3}]: (at row 1)

Т.е. КХ видит api, получает из неё данные, но не может переварить результат. Я конфигах указывал и JSON и JSONEachRow. Ничего не помогает.

1) то что видно - это не JSONEachRow точно
2) дайте весь ответ от API и конфиг словаря

Запрос: select dictGetString('positions_publishers', 'publisher_id', toUInt64(2))
Ответ:
Received exception from server (version 1.1.54370):
Code: 85. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Format JSON is not suitable for input.

Конфиг:
<dictionary>
<name>positions_publishers</name>
<source>
<http>
<url>http://localhost:8000/campaigns/api/clickhouse/get_publishers</url>
<format>JSON</format>
</http>
</source>
<layout>
<flat/>
</layout>

<lifetime>
<min>3</min>
<max>7</max>
</lifetime>

<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>publisher_id</name>
<type>String</type>
<null_value>0</null_value>
</attribute>
</structure>
</dictionary>

Как минимум publisher_id у вас не String

Об это я споткнулся, когда подключал другой словарь из Postgres через ODBC. В источнике id'шник типа integer, ну и логично было указать в конфиге Int32. Прописал, сохранил, делаю запрос - ошибка на какое-то нессответствие типов. Пробовал разные варианты для этого атрибута: (U)Int16, (U)Int32, (U)Int64. Всё время была ошибка. Помогло только String. Хотя в источнике этот атрибут с типом integer.

DB::Exception: Format JSON is not suitable for input.

вам сервер намекает

что format JSON нельзя использовать для input

https://clickhouse.yandex/docs/ru/interfaces/formats/

ммм, так стало быть, КХ не сможет прочитать данные из API?

может, если API отдает данные в формате JSONEachRow

Cannot parse input: expected { before: [{"publisher_id": 999, "id": 1}, {"publisher_id": 5, "id": 2}, {"publisher_id": 756, "id": 3}]: (at row 1)

не должно быть [ вначале

и разделителем данных должен быть перенос строки

странные ограничения

да и вообще нет смысла отдавать весь массив, нужно отдавать один запрашиваемый элемент по ключу POST запроса

select dictGetString('positions_publishers', 'publisher_id', toUInt64(2)) -> {"publisher_id": 5, "id": 2}

В идеале хотелось бы весь словарь хранить в памяти (layout - flat). При схеме "один запрос к словарю"-"одно обращение к api", если я правильно понимаю, будет много ненужного обращения к api. Т.е. при вставке миллионов строк для обогащения атрибутом publisher_id будут сделаны миллионы запросов к api. Зачем, ведь словарь же можно и памяти хранить.

да, лучше все держать в памяти, если данных не сильно много то это вполне терпимо

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

он массив должен быть в одном из допустимых для input форматов

В общем, не получилось. Придётся брать данные по ODBC из самой postgres.
Буду признателен, если кто-нибудь поделется своим решением по поводу api и json.

а что конкретно не получилось?

Победить сообщение "Cannot parse input: expected { before:" при обращении к словарю.
Дальше после этого сообщения идёт содержимое ответа api, вот ведь оно, дошло сообщение api. Но я не понимаю почему КХ не может разобрать ответ.

Эта ошибка возникает при обращении к словарю или при релоаде словаря?

При обращении.

Всем привет! Прошу помощи!
Code: 47, e.displayText() = DB::Exception: Unknown identifier: createdAt, e.what() = DB::Exception
При SELECT * FROM coupons WHERE (couponCode = '0200000001') ORDER BY createdAt DESC FORMAT JSON
запрос кидаю черех smi2/phpClickHouse
Ошибка вылетает раз в 1-3 запроса, остальные отрабатывают норм, реплик нету, в чём проблема может быть?

говорит, что столбца createdAt нет в результате

точнее, в таблице coupons

Да, но он есть

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

Ну, оно раз в 3 запроса падает, я думаю оно бы тогда падало постоянно

Чекнул всё, всеравно падает иногда, через нативный клиент работает всё, через табикс тоже работает, а вот если с пыхи кидать - падает раз в 3

$client->verbose(); вам в помошь, можно попробовать просто через консольный curl

похоже, придётся дебажить пхп клиент

Запросы он кидает одинаковые всегда, дебажил, вот сам сервак возвращает разные ответы всегда

Просто это странно, раз в 2-3 запроса падает, остальные норм отдаёт

if (source.agent==php) suffer();

Было бы смешно, если бы не было так грустно)))

@milovidov_an Алексей, подскажите, в настройке словарей через odbc в версиях 18.1.хх что-то менялось? После обновления перестали работать словари - не может найти датасорс. Откатили на 1.1.54394 - все опять заработало

Видимо API все таки возвращает JSON, а не JSONEachRow.
Мы у себя добились JSONEachRow с помощью реализации кастомного форматтера для ответа из API.
Если ваш API возвращает все таки JSONEachRow - попробуйте сделать RELOAD словаря и посмотреть в системной таблице словарей последнюю ошибку.

Ну и в конфигурации словаря соответственно надо проверить, что указан формат JSONEachRow

Доброго дня всем!
Возникла ситуация: кончилось место на диске.
Этот факт был отмечен в логах clickhouse, в то время, как он сам перестал отвечать на попытки подключиться к нему.
Потом место мы освободили, сервер перезапустили, но clickhouse все равно на попытки подключиться отвечает:

ClickHouse client version 1.1.54236.
Connecting to localhost:9000.
Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1)

В чем может быть проблема?

вроде логичнее было бы просто json сделать

Проверьте DNS - что IP всегда сервера, и что database('name') - всегда указан, может есть еще база с такой таблицей
SELECT * FROM coupons.coupons WHERE (couponCode = '0200000001') ORDER BY createdAt
И самый простой вариант - это через простой Curl подергать CH без PHP

Смотрите что КХ пишет в логах, возможно он ещё не стартанул

Мне удалось буквально только что сделать так, что бы КХ понимал простой json. Т.е. API отдаёт {'publisher_id': '999', 'id': '1'} и запрос SELECT dictGetString('positions_publishers', 'publisher_id', toUInt64(1)) отрабатывает без ошибки и возвращает 999.
А если на стороне api формирую список словарей (python) и отдаю, то опять возникает ошибка "Cannot parse input: expected { before: ...".
Т.е., видимо, что-то на стороне api при конвертировании питоновского списка словарей не так.

Вот то, что клик пишет в лог при запуске

Я там ничего подозрительного не увидел

Попробуйте через Postman обратиться к своему API и посмотреть какие данные возвращаются. Если это список объектов, типа: [{...}, {...}, ...], то в этом и есть проблема, т.к. с этим форматом Clickhouse не работает. Надо избавляться от [] и использовать разделитель перенос строки, вместо запятой.

используйте TSV или CSV вместо json

select 999 publisher_id, 1 id
union all
select 5 publisher_id, 2 id
union all
select 756 publisher_id, 3 id
format JSONEachRow

вот что ожидает КХ
{"publisher_id":999,"id":1}
{"publisher_id":756,"id":3}
{"publisher_id":5,"id":2}

Обычный json слишком медленный для парсинга, видимо разработчики тратить время на него не хотят.

Получилось!

Ребят, а не было какой нить инструкции пошаговой, как dictionary подключить через odbc. Например файл с описанием внешнего словаря надо создать это я понял, а котом его где нибудь надо в config.xml прописывать? или он и так поймет?

то что сейчас есть https://clickhouse.yandex/docs/ru/operations/table_engines/dictionary/, не очевидно имхо. Я бы внес изменения даже как PR, но хотя бы понять куда копать.

Сейчас вышлю

Мой api в итоге отправляет такой ответ b'[{"publisher_id": "999", "id": "1"}, {"publisher_id": "5", "id": "2"}, {"publisher_id": "756", "id": "3"}]'

Надо было просто убрать квадратные скобки

Спасибо!

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

Прочекал всё, попробовал всё дропнуть и заново создать, теперь
Code: 49, e.displayText() = DB::Exception: Could not find a column of minimum size in MergeTree, part /var/lib/clickhouse/data/coupon/coupons/20180803_20180803_1_6_1/, e.what() = DB::Exception

Может знает кто в чём дело?

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

2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result.

Вот выдержка из лога по этому треду.

2018.08.03 16:56:02.352540 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merge sorted 118552713 rows, containing 166 columns (6 merged, 160 gathered) in 234.24 sec., 506113.87 rows/sec., 649.20 MB/sec.
2018.08.03 16:56:02.356438 [ 12 ] <Trace> SrcData.TTStatBase (Data): Renaming temporary part tmp_merge_201709_63076_64611_5 to 201709_63076_64611_5.
2018.08.03 16:56:02.356510 [ 12 ] <Trace> SrcData.TTStatBase (MergerMutator): Merged 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4
2018.08.03 16:56:02.583501 [ 12 ] <Debug> SrcData.TTStatBase (Data): Undoing transaction. Removing parts: 201709_63076_64611_5.
2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result.
2018.08.03 16:56:02.583670 [ 12 ] <Debug> MemoryTracker: Peak memory usage: 39.87 MiB.
2018.08.03 16:56:02.753503 [ 12 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Part 201709_63076_64611_5 (state Outdated) should be deleted after previous attempt before fetch
2018.08.03 16:56:02.753556 [ 12 ] <Trace> SrcData.TTStatBase (StorageReplicatedMergeTree): Executing log entry to merge parts 201709_63076_63675_4, 201709_63676_64196_4, 201709_64197_64611_4 to 201709_63076_64611_5
2018.08.03 16:56:02.753587 [ 22 ] <Trace> SrcData.TTStatBase (Data): Found 1 old parts to remove.
2018.08.03 16:56:02.753614 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merging 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 into tmp_merge_201709_63076_64611_5
2018.08.03 16:56:02.753622 [ 22 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Removing 1 old parts from ZooKeeper
2018.08.03 16:56:02.755014 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Selected MergeAlgorithm: Vertical
2018.08.03 16:56:02.755235 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_63076_63675_4, approx. 46530560 rows starting from 0

2018.08.03 16:56:02.755405 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_63676_64196_4, approx. 40615936 rows starting from 0
2018.08.03 16:56:02.755483 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_64197_64611_4, approx. 31416320 rows starting from 0

Seems like the problem was 2 instances of clickhouse-server running at the same time. Not sure how I got to this scenario...
https://groups.google.com/forum/#!topic/clickhouse/chYoOYgcxoQ
тут чате тоже есть про Could not find a column of minimum size

Что с этим можно сделать? Рестарт CH не помогает. Версии CH на репликах сейчас идентичны, но в процессе апдейта некоторое время были разными, конечно.

Спасибо. Да, тут гораздо больше надо действий чем написано в доке.

Подтверждения присылаются не сразу, а периодически - сразу пачкой.

а в течение какого периода можно ожидать?

Да, в 18.6.0 попали изменения с фильтрацией connection string. Поставьте пока 18.5.1.

До 15 августа.

спасибо

спасибо

Кто-нибудь использует alias для JOIN?

Возвращает не совсем то, что ожидается

При этом если указать так
SELECT
*, d.*, d.values

Тогда d.values вернёт то что нужно. Выглядит как баг

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

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

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

Не может быть)

Мне создать issue?

Еще раз всем привет, я пока не смог решить проблему, но обнаружил интересный эффект. Если я залезу в /var/lib/clickhouse/data и перенесу папку с данными самой активно пользуемой базы куда-нибудь, то проблем при запуске не возникает и в логе появляются строки:

2013.05.15 04:02:00.275454 [ 1 ] <Information> Application: Listening http://[::0.0.0.0]:8123
2013.05.15 04:02:00.275647 [ 1 ] <Information> Application: Listening tcp: [::0.0.0.0]:9000
2013.05.15 04:02:00.275825 [ 1 ] <Information> Application: Listening interserver: [::0.0.0.0]:9009
2013.05.15 04:02:00.276018 [ 1 ] <Information> Application: Ready for connections.

Если вернуть на место, проблемы возвращаются. Что это может значить?

Вот очень похожее https://github.com/yandex/ClickHouse/issues/2786 и там даже PR предложили.

А в логе больше ничего нет, кроме того, что ты приложил?

Нет

На этом месте он задумываетсяя (если запускать клик из консли) и при попытке остановить его (ctrl+c) пишет в лог

<Information> Application: Received termination signal (Interrupt)

И не останавливается. При повторном нажатии пишет

2013.05.15 04:08:22.359170 [ 5 ] <Information> Application: Received termination signal (Interrupt)
2013.05.15 04:08:22.359205 [ 5 ] <Information> Application: Received second signal Interrupt. Immediately terminate.

И после этого уже умирает

Это поведение ожидаемо. Но конечно без gdb'ы/strace'a тут сложно понять, почему он задумывается и что он там делает.

Спасибо, помогло

Самая нагруженная таблица - energomonitor

И при таком трейсе ничего в логах?!

Лог с того момента, как я использовал strace

Не считая сообщений о том. как я его в конце "убивал"

А почему версия, которой уже почти 1.5 года? Если честно, с такой древностью разбираться сложно совсем.

fsck делали?

что sar -d 1 100
показывает в момент старта КХ?

Хм, это странно. Вопрос тогда снимается, пока мы версию не обновим.

Сделаем

Это где, я не нашел такого

это команда/софтина в юниксе, показывает нагрузку, в данном случае -d диски

я подозреваю что вы просто не дожидаетесь пока КХ прочитает с диска файлы, или с дисками проблемы и будут запредельные числа в столбиках svctm и await
15:24:40 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
15:24:40 dev8-0 0.00 0.00 0.00 0.00 0.40 0.00 0.00 40.00
15:24:40 dev8-16 0.00 0.00 0.00 0.00 0.40 0.00 0.00 40.00

Я понял, возможно. Хорошо, спасибо, это тоже проверим.

Впринципе да, последняя запись в логе, что он как раз начинает грузить табличку. На текущей версии там идёт логирование, которое как-то описывает процесс, было бы более наглядно.

и fsck надо сделать, потому что там возможно получились бесконечные файлы из нулей в конце.

Вопрос по нативному протоколу и пакету Data. В клиенте в Connection::receiveData есть readStringBinary(external_table_name, *in). Но на сервере TCPHandler::sendData туда пишет пустую строку: writeStringBinary("", *out).
Есть ли в этом какой-то смысл? Или остаток непригодившейся фичи?

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

Кэшируются ли такие словари?

Подскажите пожалуйста, а как сделать что-то вроде emptyArrayTuple() ?

select cast([] as Array(Tuple(Int8)))

В зависимости от типа — cached/hashed

спасибо

с файлом? в смысле словарь vs КХ таблица?
словарь быстрее для рандомного доступа

Ок, спасибо.

А есть возможность попросить о фиче в новый табикс? Очень не хватает возможности выносить окощке результата в другое окно, чтобы былоа как в хроме, когда дебаггер и страница в разных окнах. Ну или показывать его справа, как предпросмотр сейчас сделан.
Не хватает высоты окна редактирования :(

Нарисуйте issue сделаю)

спасибо

А альфа уже юзабельная ?

Нет((

ПОдскажите как сделать запрос с like вида
SELECT
Time, OpenTime, CloseTime
FROM db.test
Where Time LIKE('2018-08-01%’)
ORDER BY (Time, TimeMillisecond) DESC

Как-то так)
SELECT
Time, OpenTime, CloseTime
FROM db.test
Where Time LIKE '2018-08-01%’
ORDER BY (Time, TimeMillisecond) DESC

вот это поворот

получаю - Error running query: Code: 43, e.displayText() = DB::Exception: Illegal type DateTime of argument of function like, e.what() = DB::Exception

Он ругается на тип колонки Time. Можно кастануть ее в строку:
where toString(Time) like '2018-08-01 %'

спасибо!

это удар по перфомансу.

Time between '2018-08-01 00:00:00' and '2018-08-01 23:59:59'
или
toYYYYMMDD(Time) = '2018-08-01'

вот-вот, как раз хотел спросить, какой тип у колонки Time

>toYYYYMMDD(Time) = '2018-08-01'
и удивительно, КХ единственная известная мне БД, где такой вариант заооптимизирован, остальные субд не парятся разворотом хешфункций.

Если судить по названию, кажется, что функция должна вернуть '20180801')
Я такой, честно говоря, даже не знал и гонял between

toDate(Time)

а ну правильно, а toYYYYMMDD видимо для кастомного партиционирования сделали

select * from (select toDateTime('2018-01-01 01:01:01') a)
where
toYYYYMMDD(a) = 20180101 and
toDate(a) = '2018-01-01'

я тоже везде пишу between, но вообще-то индекс работает с toYYYYMMDD и с toDate

отбрасывание партиций еще страннее, партиционировали скажем по floor(x/100), у каждой партиции есть атрибуты max(x) и min(x), поэтому в запросе для оптимизации выбора партиции пишем where x=5, вместо привычных мне floor(x/100)= floor(5/100), это взрывает мне мозг.

Пришлось много менять в UI/ux, все переделывать - но мне кажется лучше получается, "подразню" скином сравнением https://monosnap.com/file/1kn68QAl34wPAc2Jl3mWMi4i0IMIZw

👍

Робяты, если у меня в dictionary внешнем (Postgres через ODBC) есть поле Timestamp, которое так же может быть NULL. Как его правильно оформить в <attribute></attribute> что бы не ругался? Ну и видимо конвертация нужна. Использовать <expression></expression> или есть какой то другой идиоматический способ?

<null_value>0000-00-00 00:00:00</null_value>

Спасибо, попробую

Посмотрите также expression:
https://clickhouse.yandex/docs/ru/single/#_115

Может быть можно подставить COALESCE(Timestamp, ...)

Он скорее как бэкэнд для чего то что можно назвать tsdb. А так на Вики вообще мало баз самих больше 50 только в opensource

Добрый день.
Столкнулся с ошибкой и не понимаю куда рыть дальше. Помогите пожалуйста понять:
Создаю вьюху
CREATE MATERIALIZED VIEW IF NOT EXISTS db1.r_test_transactions ON CLUSTER comparatio_cloud
ENGINE = ReplicatedReplacingMergeTree('/clickhouse/db1/tables/r_test_transactions', '{replica}', DATE, (ED1_ID, CO1_ID), 8192, ED1_UPLOAD_TIMESTAMP) AS
SELECT *
FROM db1.rtest_transactions

┌─host────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
│ ch-srv1 │ 9000 │ 0 │ │ 1 │ 0 │
│ ch-srv2 │ 9000 │ 0 │ │ 0 │ 0 │
└─────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘

2 rows in set. Elapsed: 0.108 sec.

Вставляю данные
ip-172-31-16-11.us-west-2.compute.internal :) insert into db1.rtest_transactions select * from db1.rtest_transactions;

INSERT INTO db1.rtest_transactions SELECT *
FROM db1.rtest_transactions

Ok.

0 rows in set. Elapsed: 0.001 sec.

на втором сервере делаю ip-172-31-16-10.us-west-2.compute.internal :) optimize table db1.r_test_transactions;

OPTIMIZE TABLE db1.r_test_transactions

Received exception from server (version 18.6.0):
Code: 194. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Received from ch-srv2:9000, 172.31.16.11. DB::Exception: Password required for user default.

0 rows in set. Elapsed: 0.079 sec.

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

Добрый вечер! У меня в Зукипере, с которым работает только КХ, накопилось уже 11 лог-файлов, хотя в конфиге зукипера указано ротировать по 10 (autopurge.snapRetainCount).

root@east-dwarf-zk1:/var/zookeeper/logs/version-2# ls -lh
total 19G
-rw-r--r-- 1 zookeeper zookeeper 1.2G Aug 3 09:43 log.10019933c
-rw-r--r-- 1 zookeeper zookeeper 1.7G Aug 3 15:51 log.10030917f
-rw-r--r-- 1 zookeeper zookeeper 2.1G Aug 3 23:25 log.100519d74
-rw-r--r-- 1 zookeeper zookeeper 2.3G Aug 4 03:52 log.1007ad569
-rw-r--r-- 1 zookeeper zookeeper 2.3G Aug 4 07:40 log.100a742c0
-rw-r--r-- 1 zookeeper zookeeper 1.7G Aug 4 10:07 log.100d4c983
-rw-r--r-- 1 zookeeper zookeeper 2.3G Aug 4 12:43 log.100f41aa2
-rw-r--r-- 1 zookeeper zookeeper 1.3G Aug 4 14:52 log.10120bd50
-rw-r--r-- 1 zookeeper zookeeper 1.7G Aug 4 17:30 log.10139afc5
-rw-r--r-- 1 zookeeper zookeeper 1.3G Aug 4 19:28 log.1015a31d4
-rw-r--r-- 1 zookeeper zookeeper 1.9G Aug 4 22:12 log.10173df82

root@east-dwarf-zk1:/var/zookeeper/logs/version-2# cat /opt/zookeeper/conf/zoo.cfg
autopurge.purgeInterval=1
maxSessionTimeout=60000000
dataDir=/var/zookeeper/data
4lw.commands.whitelist=*
syncLimit=10
dataLogDir=/var/zookeeper/logs
reconfigEnabled=true
leaderServes=yes
standaloneEnabled=false
skipACL=yes
autopurge.snapRetainCount=10
tickTime=2000
initLimit=30000
snapCount=3000000
preAllocSize=131072
maxClientCnxns=2000
dynamicConfigFile=/opt/zookeeper/conf/zoo.cfg.dynamic.100000000

Подскажите, плиз, нормальная ли это ситуация? Зукиперы запускались с такими конфигами, ничего после запуска не дописывалось, т.е. всё по идее должно быть применено.

О, только что создался и начал писаться 12 файл лога =)

Снепшоты и логи не одно и тоже.

При этом зукипер видит настройки. Версия 3.5.3.

2018-08-02 23:06:05,104 [myid:1] - INFO [main:DatadirCleanupManager@78] - autopurge.snapRetainCount set to 10
2018-08-02 23:06:05,112 [myid:1] - INFO [main:DatadirCleanupManager@79] - autopurge.purgeInterval set to 1

Это уже что-то) Так логи можно просто > logfile занулять, или даже просто удалять?

Коллеги, подскажите: хочу подключить коллекцию mongodb как внешний словарь. В коллекции есть поле-массив строк, но, как я понял, поддержка Array() во внешних словарях не реализована. В целом, меня бы устроило записывать конкатенацию строк, но возможно ли это реализовать? Через expression? Не нашел в каком виде они задаются.

# systemctl status zookeeper
● zookeeper.service - ZooKeeper Service
Loaded: loaded (/etc/systemd/system/zookeeper.service; enabled)
Active: active (running) since Thu 2018-08-02 23:45:43 MSK; 1 day 22h ago
Docs: http://zookeeper.apache.org
Main PID: 13115 (java)
CGroup: /system.slice/zookeeper.service
└─13115 /usr/bin/java -cp $ZOOCFGDIR:/opt/zookeeper/zookeeper-3.5.3-beta.jar:/opt/zookeeper/lib:/opt/zookeeper/lib/slf4j-log4j12-1.7.5.jar:/opt/zookeeper/lib/slf4j-api-1.7.5.jar:/opt/zookeep...

Aug 04 15:45:44 east-dwarf-zk1: java[13115]: Removing file: 2 авг. 2018 г., 23:45:44 /var/zookeeper/data/version-2/snapshot.0
Aug 04 17:45:43 east-dwarf-zk1: java[13115]: Removing file: 2 авг. 2018 г., 23:45:44 /var/zookeeper/data/version-2/snapshot.100000000
Aug 04 19:45:43 east-dwarf-zk1: java[13115]: Removing file: 3 авг. 2018 г., 5:15:13 /var/zookeeper/logs/version-2/log.100000001
Aug 04 19:45:44 east-dwarf-zk1: java[13115]: Removing file: 3 авг. 2018 г., 5:15:13 /var/zookeeper/data/version-2/snapshot.10019933a

а он, похоже, всё же что-то удаляет. помониторю ещё.

Нет, expression в Mongo словарях не поддерживается.

Я думаю, это несложно добавить. Надо смотреть в MongoDBDictionarySource.cpp,
функция createCursor.

Для этого нужен человек, который чуть-чуть знает C++ (может пересобирать, перезапускать ClickHouse с mongo словарём).

благодарю

ура, ложная тревога, всё ротируется) только что процесс прошёл. будет +1 файл, то есть если

autopurge.snapRetainCount=10
то будет 11 файлов всегда, где 11 - в который сейчас пишется

cat /var/log/zookeeper-logger/zookeeper.log | grep -i Removing
2018-08-04 15:45:44,676 [myid:1] - INFO [PurgeTask:PurgeTxnLog@154] - Removing file: 2 авг. 2018 г., 23:45:44 /var/zookeeper/data/version-2/snapshot.0
2018-08-04 17:45:43,994 [myid:1] - INFO [PurgeTask:PurgeTxnLog@154] - Removing file: 2 авг. 2018 г., 23:45:44 /var/zookeeper/data/version-2/snapshot.100000000
2018-08-04 19:45:43,994 [myid:1] - INFO [PurgeTask:PurgeTxnLog@154] - Removing file: 3 авг. 2018 г., 5:15:13 /var/zookeeper/logs/version-2/log.100000001
2018-08-04 19:45:44,038 [myid:1] - INFO [PurgeTask:PurgeTxnLog@154] - Removing file: 3 авг. 2018 г., 5:15:13 /var/zookeeper/data/version-2/snapshot.10019933a
2018-08-04 22:45:44,012 [myid:1] - INFO [PurgeTask:PurgeTxnLog@154] - Removing file: 3 авг. 2018 г., 9:43:06 /var/zookeeper/logs/version-2/log.10019933c
2018-08-04 22:45:44,042 [myid:1] - INFO [PurgeTask:PurgeTxnLog@154] - Removing file: 3 авг. 2018 г., 9:43:06 /var/zookeeper/data/version-2/snapshot.10030916a

Для default пароль не задавайте, это поведение нужно поправить, считайте что пока это фича такая.

Здравствуйте! Есть где-нибудь детальное описание, как хранятся данные внутри MergeTree?
Как лежат на диске, как в памяти, используется ли кодирование столбцов, какой минимальный размер блока и т.п.?

https://youtu.be/PLMSA_gDdyM

@fediq , наверно вот тут для базового понимания.

Спасибо!

Всем привет. Возник вопрос при select ... where text like %localhost%. Вот так работает. А вот так уже нет. ....where text like %Localhost%. Заранее спасибо.

LIKE case sensitive: https://clickhouse.yandex/docs/en/query_language/functions/string_search_functions/#likehaystack-pattern-haystack-like-pattern-operator

Собсно, кейс там во всех функциях важен, учитывайте это.

Что скажете по поводу lower(text) like ...?

Я предпочитаю регулярками разруливать. Но разумнее попробовать как так, так и эдак, выбрать то, что подходит.

Спасибо

Спасибо! да, все получилось!

Ребят, а еще такой вопрос. У меня справочники, которые надо в JOIN по всякому использовать. Их структура чуть сложнее чем (id, name). Если я их как TinyLog буду хранить, это ведь нормально? Меня просто в документации смутило - жирным "Индексы не поддерживаются. ". Это ведь не страшно? значения колонок ведь тоже хранятся на диске в отсортированном виде? И доступ к данным в такой таблице быстрый?

можно как-то дропнуть таблицы по маске имени?

то есть вот так я их могу выбрать
select name FROM system.tables WHERE name like '%__tmp%'

а как дроп прикрутить?

может выгрузить названия таблиц в файл через 'DROP TABLE ' || tablename; его потом запустить через параметр в clickhouse-client

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

Ну и еще один вопрос. Если у меня есть таблица-полу-справочник (больше 1 млн записей), в которых регулярно происходят обновления атрибутов. Я ее объявляю таким образом.
CREATE TABLE runner_catalog
(
selection_id UInt64,
runner_name String,
handicap UInt64,
sort_priority UInt8,
version UInt64
)
ENGINE = ReplacingMergeTree(version)
PARTITION BY intHash64(selection_id)
ORDER BY (selection_id, runner_name);
Я все правильно делаю? В качестве первичного ключа исползьую selection_id. Но из документации, не совсем понял зачем указывать ORDER BY.

Меня смущает, что в документации написано, что слияние происходит в фоне. Значит ли это, что можно столкнуться с ситуацией, когда в таблице runner_catalog будет больше одной записи с одинаковым selection_id?

Секция partition by - это не первичный ключ, это ключ разбиения на секции. В случае со словарем подозреваю, что вам не нужен партишионинг

А то, что вы называете первичным ключем - это секция order by (при этом это все же не совсем первичный ключ, это ключ сортировки)

да, не нужен. Спасибо.

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

Спасибо. Получилось так.

create table runner_catalog (
selection_id UInt64,
runner_name String,
handicap UInt64,
sort_priority UInt8,
version UInt64)
Engine = ReplacingMergeTree(version)
ORDER BY (selection_id);

А есть следующий уровень? =)

У меня нездоровый, можно даже сказать, академический, интерес к представлению данных.
На 10:55 Алексей рассказывает "Как работает индекс". Он упоминает файлы индекса (primary.idx), засечек (.mrk) и данных (.bin). С кем можно обсудить формат этих файлов?

https://www.youtube.com/watch?v=PLMSA_gDdyM&t=655

@fediq , исходники?

Обсуждать с исходниками - это когда тебя совсем никто не любит. =(

зато они никогда не введут в заблуждение, даже невольно

@fediq https://events.yandex.ru/lib/talks/5800/
Вот хороший обзор внутренностей MergeTree движка

Уже определили сумму которую готовы выложить за прекрасные новые знания?

open ! = free

Тоже вариант. В ПМ?

Спасибо! Посмотрю.

Спасибо! Помогло. Только жаль, что это нигде в документации не описано...

Добрый день.
Может еще кто то знает еще одна ошибка
Очистка Materialized View работает только на том сервере, где была создана, на любых других выходит ошибка:
ip-172-31-16-10.us-west-2.compute.internal :) truncate table db1.r_test_transactions;

TRUNCATE TABLE db1.r_test_transactions

Received exception from server (version 18.6.0):
Code: 48. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Can't proxy this query. Unsupported query type.

0 rows in set. Elapsed: 0.080 sec.

А тут Materialized View была создана и все работает:
ip-172-31-16-11.us-west-2.compute.internal :) truncate table db1.r_test_transactions
:-] ;

TRUNCATE TABLE db1.r_test_transactions

Ok.

0 rows in set. Elapsed: 0.047 sec.
Это ошибка CH или я опять где-то что то не так делаю?

Подскажите пожалуйста, ClickHouse не позволяет создавать таблицы с одинаковыми наименованием столбцов? engine = log, Хотела создать таблицу, которая имеет пару одинаковых наименования полей как в ранее созданных таблиц, тогда выдает ошибку DB::Exception: Column ID already exists.

Это из за того что движок LOG или в целом clickhouse не позволяет повторение наименование столбцов

новичок в ClickHouse, подскажите плиз не моге найти инфу

одинаковые столбцы это как?
Это вообще законно?

А какая бд позволяет?

У меня ранее скажем создана таблица "A" с колонками (id Int32, Name String) engine = log, и скажем я пытаюсь создать таблицу "B" с колонками ( id Int32, City String) engine = log

и тогда у меня возникает ошибка DB::Exception: Column ID already exists.

Это простой пример

Кажется я поняла в чем причина

Gulya, в чем? Тоже интересно стало.

А это "фича" и её нужно поправить

Плюсую интерес к причине.

Народ

такая штука select one, 2 as one from (select 1 as one, 2 as two)

в результате будет 2 2, а не 1 2

это баг или фича ?

А если select one, select 2 as ne_one...?

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

получается что при таком запросе insert into table (id, name) select 2 as id, 'test' as name, from table where id = 1

выбирается на запись с id = 1, а запись с id 2

Здравствуйте

Кто-то сталкивался с подобной проблемой: "Poco::Exception. Code: 1000 ... Malformed message: Field value too long/no CRLF found"?

Отправляю external_data через curl. Передаю список. Если длинной менее 1000, все ок. Больше - ошибка

Через клиент все работает без проблем.

привет всем, а у кого-то есть пример как залить сsv в кликхаус на golang?

А почему бы просто через хттп запрос не лить?

зачем голанг, если есть cli?

???)

clickhouse-client умеет csv закидывать на серввер

я знаю, спасибо) Просто странный вопрос от вас)

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

Пост запрос в теле цсв а урл "/query=insert into TABLENANE format csv"

👍

через cli:
clickhouse-client --host=... --query="INSERT INTO ... FORMAT CSV" < /path/to/data.csv

/stat@combot

Всем доброго дня! Ребят подскажите или киньте ссылочку где можно почитать, каким способом кроме пересоздания таблицы можно изменить параметры внутри Engine? Есть таблица с типом SummingMergeTree с явным указанием колонок для суммирования, нужно добавить еще одну колонку в таблицу и включить её в колонки для суммирования! Спасибо!

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

никак

Спасибо!

Не то что поменять движок, даже набор колонок в ПК нельзя поменять

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

кстати, рендерер md->html не работает с картинками, кажется

в md на гитхабе все в порядке

Можно добавляеть если не меняется сортировка для ПК (т.е. в ключ добаляются поля с дефалтовыми значениями) и работает только для MergeTree.

Привет!
Увидел в тикете на github (https://github.com/yandex/ClickHouse/issues/1178) такую конструкцию: OPTIMIZE TABLE tablename [FINAL] DEDUPLICATE;

Про DEDUPLICATE в документации ничего не нашел. Кто нибудь знает что именно делает DEDUPLICATE и работает ли это вообще?

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

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

WITH expr AS ident SELECT ...

Если бы еще табикс можно как-то приучить нормально форматировать такие выборки :)

Это не попадает во вложенные селекты и юнионы же

Всем привет! Подскажите, пожалуйста, как использовать IPv4StringToNum в JDBC

Пытаюсь sendRowBinaryStream stream.writeString("IPv4StringToNum(" + lfadto.getIp4() + ")") , строка вставляется, но что-то явно идет не так. Переписываются другие поля

Подскажите пожалуйста, как использовать кликхаус в качестве backend'а в проекте django?

Вам только для чтения нужно?

Да только чтение

Ну тогда использование orm неоправданно. Просто обращайтесь к вашим ch-табличкам через http интерфейс.

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

а можно ли в tsv поставить значение today() в поле типа Date?

нельзя: ERROR: Date must be in YYYY-MM-DD format.

У нас Kafka, но кворум победить не смогли. Задолбало ловить рандомно конфликты нод ZooKeeper, волево вырубили кворум.

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

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

Что тогда посоветуете?

Ничего. :) На деле кворум и Кафка — это разные штуки. Мы об кворум бились при разных источниках данных. Возможно, выкрутитесь через "не получил 200, попробуй записать ещё раз", но, емнип, тут мы уже огребали с дедупликацией, но толком уже не помню.
А Кафка норм, как накопитель вполне. Тут ещё несколько человек её так используют.

Блин, не на то ответил. С ORM и ClickHouse пока толком ничего нет, кажется.

Да и зачем? Сила евойная в аналитике, которую можно спихнуть на базу и она не крякнет. Аналитику сию делать на таблицах с большим количеством колонок. Соответственно, у вас и модели раздутые будут. А полезные запросы всё равно вне ORM писать. Если вам всё-таки тут прям очень нужен ORM, кажется, проще наваять своё ровно под свои задачи.

алхимию пользуем в связке с кх, особо не жалуемся

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

О. А сколько колонок в таблицах?

+1

не помню, штук 50 что ли. а какое это имеет значение?

в разрезе данного вопроса :)

Интересует размер моделей в смысле "это наш класс клика, у него три сотни полей".

Ну т.е. я раньше прикидывал кейсы использования КХ и у меня получалось, что либо ORM не нужен, либо КХ используется как простобаза. Видимо, что-то пропустил.

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

у неё есть core часть и orm часть, которая обертка над первой

Да, но объём кода и работы не тот же, что без Алхимии?

вторую использовать никто не заставляет

не пробовал без неё)

ну в целом разница будет не велика

select([func.toMonday(table.x.time), func.count(), func.groupUniq(table.c.user_id)]).where(table.c.time >= X).group_by(func.toMonday(table.x.time))

вот пример запроса

думаю, можно представить, сколько он будет занимать на raw sql

Такой же, что и в raw, собсно.

в целом да

только табличку описать надо будет :)

но структурированней получается эт точно

А нафига тогда? :) Привычка?

крайне полезно при генерации запросов

на ходу

ну и да, привычка

Понятно. Спасибо. :)

оверхеда почти нет, так что почему бы и нет

А как работает alter колонок? UInt64-> Int64, UInt32 -> UInt64, Float32 -> Int32, при мердже меняет или на лету (во время select)?

create table x (a Float32) engine=MergeTree partition by tuple() order by tuple();
insert into x values (-1000), (4.3), (3.14), (3000), (-100400.4);
alter table x modify column a Int32;

Преобразует сразу - во время ALTER.

т.е. на колонке размером 1 TБ, придется ждать?

Да.

ОК, Спасибо.

А кстати insert в этот момент, пока alter идет, в каком типе делать?

А никто не проверял, реальный perforamce String vs Fixed String. Есть строка, размер которой от 1 до 1024, что реально быстрее? Вроде как fixed string должен быть, а как на самом деле?

FixedString имеет смысл использовать, когда размер действительно фиксированный. То есть, не от 1 до 1024, а всегда 32, например.

В остальных случаях лучше предпочитать String.

Спасибо

/stat@combot

О, кстати, Алексей, хотел спросить, насколько плохая идея вместо fat width таблицы использовать много, объединенных по индексу FixedString(32)?

А какой в этом смысл (какое преимущество)?

То есть, сам по себе memcmp для 32х байт - это довольно быстро, но там растет число джоинов

Да никакого - расширял схему, добавляя таблицы и не ломая совместимость

В принципе, у меня момент, когда я могу все кардинально поломать

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

Много JOIN-ов плохо работает - как по удобству (сейчас более одного JOIN-а в запросе писать трудно), так и по скорости (для JOIN правая часть сохраняется в хэш-таблицу и по ней делаются lookup-ы).

То есть, лучше сделать колбасу без возможности миграции?

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

Хотя я сам склоняюсь к такому варианту - я слишком думал о flexibility, забывая, что ch - это не мускуль с row oriented идеологией

У меня толстые массивы

Колонок там будет точно меньше тысячи

Ок. В зависимости от толщины массивов может быть разумно уменьшить index_granularity а также размер пачки при вставке.

Я думаю, у меня в почтах именно размеры вставки не такие впечатляющие, как в кликах пользователей. Там будут жырные инсерты по тысяче записей - каждая на 2 килобайта текста, скажем, раз в 10 секунд

А вот медленный селект - это проблема, да

Это Ок.

господа а как долго может продлится стадия Starting up tables. ?

чот уже 20 минут в логе это последняя запись

данных не скзать что много. чуть больше 1t. но по ресурсам не видно что бы что то потреблялось. просто висим и всё

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

Также он выводит, какие именно таблицы он загружает.

сам себе отвечу. 30 минут.

увы нет

Наверное вы переключили логгирование в information.
2018.08.06 22:45:31.162028 [ 2 ] <Debug> default.hits_1000m (Data): Loading data parts

да конечно в information

А может быть 30 минут - это таймаут для источника словаря, как написано в логе?

на трассе слишком много информации. я бы и инфо наверное бы хотел избавить от <Information> HTTPHandler: Done processing query

нее. монги там давно нету. чистый http

Наверное для соединения с этим словарём такой таймаут.

хм. проверю. спасибо

/stat@combot

подскажите, как посмотреть подробности, в чем именно ошибка

текст ошибки такой
[ClickHouse SQL] Code: 36, e.displayText() = DB::Exception: Sampling expression must be present in the primary key, e.what() = DB::Exception

это был запрос на создание таблицы

А вы писали на какой-то одной реплике, или пытались на многих (в то смысле, что это проблема именно Кафка<->кворум, или параллельность<->кворум)? Я так понимаю, если запустить четко один поток записи на одной реплике, через MV например, и кворум, то должно быть ок, кворум не любит только параллельную запись.

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

Это точно не проблема Кафки, т.к. конфликт кворума возникал в основном без неё, когда мы интенсивно скриптом мигрировали данные из Эластика в КХ.

Смирились. :) На носу придумывание и раскатка мастер-базы — поднимем какой-нибудь MySQL / PostgreSQL, раз в час будем сверять с КХ количество строк в таблицах, если что, дольём.

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

баг:
1. таблица id, str, int
2. строка значений: 1, 'some text \\', 0
3. при выгрузке в csv получаем строку 1,"some text \",0
4. при этом получается экранированная слэшом кавычка, что не даёт правильно распарсить csv штатными средствами

А хотелось бы чтобы там осталось \\?

ну, конечно

версия 1.1.54390

т.е. даже не так: там должно быть \\\\, чтобы обратно эта строка в кавычках разбиралась как \\

Подскажите, наиболее быстрый способ загрузки данных в КХ. Данных очень много. И еще вопрос целесообразно ли использовать kafka?

csv, можно в несколько потоков загружать

csv

Например, сейчас у меня из мускуля 1 час экспортится 50гигов csv.
В КХ импортится все это минут за 6-7

Порядка 300-400 гб в час в csv файлах

распараллель

Лей напрямую в stdin

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

https://stackoverflow.com/questions/47708424/importing-from-mysql-dump-to-clickhouse

Писал еще давненько. Лучше способа не нашел

А есть библиотека, которая обращается к client и напрямую льет данные в stdin?

А чем cat не устроил?

У меня не один файл, а несколько тысяч и новые выпадают раз в 5-10 секунд. Просто плохо представляю как это сделать через cat. Могли бы вы поподробнее объяснить.

cat * |

лучше уж тогда tail -f *|

* выдаст файлы на момент запуска.

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

вы правы, для обновлемых по имени файлов не подойдет

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

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

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

И? В чём проблема?

У ch есть два интерфейса для этого - http и tcp

В конце-концов, можно поставить клиента на удалённой машине

Я ссылку для кого кидал ?

/me на части хостов вообще через curl грузит...

Какая библиотека ? Из консоли все делается

/me

Ну почему же? Есть и библиотеки для питонов всяких...

Это из других чатов

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

по кр мере, проще

А вот это уже очень интересно. Можно рассказать подробнее

ээээ

proc = subprocess.Popen(
[
'clickhouse-client',
'--database=<>',
'--query=' + ins_stmt,
...
],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
)

output, err = proc.communicate(input=bytes(YOUR_CUTE_DATA, 'utf-8'))

чот типа такого, наверное?

Спасибо большое, добрый человек! Обязательно попробую так сделать)

@milovidov_an Доброго дня, Вы под алпайн кликхаус не собираете?

Привет, товарищи.
Скажите, SummingMergeTree гарантирует полное схлопывание строк или нет?
Наблюдаю частичное суммирование, часть строк остались отдельно жить.

┌─adv_id─┬─price─┬─event_date─┬─event_type─┬─event_count─┬──────event_datetime─┐
│ 1 │ 100 │ 2018-08-07 │ publish │ 1 │ 2018-08-07 15:09:47 │
│ 1 │ 100 │ 2018-08-07 │ publish │ 1 │ 2018-08-07 15:09:47 │
│ 1 │ 100 │ 2018-08-07 │ publish │ 1 │ 2018-08-07 15:09:47 │
│ 1 │ 100 │ 2018-08-07 │ publish │ 21 │ 2018-08-07 15:09:25 │
└────────┴───────┴────────────┴────────────┴─────────────┴─────────────────────┘

Нет. Применяйте OPTIMIZE ... FINAL , но и это не даст 100% гарантии.

спасибо

хм. дало эффект однако

КХ сам по себе не мало весит и смысла брать алпайн нет, больше проблем с созданием под него пакетов, в официальном ubuntu-minimal, который тоже не сильно большой.

Ну и хорошо :) Но обычно доагрегируем уже в SELECT-е, главное что SummingMergeTree сделает за вас 99% работы, и как правило на порядки ускорит агрегацию результата.

господа, а ни у кого нет рабочей связки logstash-clickhouse?

https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse

оно не особо работает нынче

а какие вы логи хотите лить в КХ?

версия logstash-mixin-http_client (<6.0.0) конфликтует с той, что поставляется с логстешем 6.2

небольшое кол-во логов приложения

а у приложения нет возможности конфигурировать log format?

я лью в КХ аксес логи nginx

приложение не хочется учить само ходить в КХ

так не надо, его учить ходить в КХ

пусть оно и дальше пишет в файл, который ротируется и прочее, а filebeat + logstash пишут в кх

а куда его писать?

я сделал все банально просто: в nginx сформировал access log в json формате, и повесил на крон баш скрипт, которые раз в 5 минут ротирует лог файл и льет данные в КХ

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

это немного топорно, ага

да, топорно, но мне ничего более и не надо

Привет. Подскажите пжлст такой момент.

У меня таблица
SummingMergeTree(event_date, (adv_id, price, event_type), 8192, event_count)

где я собираю события публикации/снятия с публикации объектов.

Специфика такая, что юзеры могут перепубликовывать (без снятия) много раз объявления для:
- актуализации даты
- для изменения цены

Такие события схлопываются успешно и суммируются в event_count

Все ок. Но дальше юзер снимает с публикации объявление.
А через пару дней - снова публикует.
И эта публикация начинает схлопываться снова.

А делать этого мне нельзя, так как это не последовательно идущие публикации.
Последовательность разрывается событием UNPUBLISH.

Средствами движка можно как то реализовать схлопывание только последовательно идущих одинаковых значений первичного ключа (adv_id, price, event_type) ?

Нет, не собираем.

При unpublish версию документа меняйте и запихайте её в ПК

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

[1,2,4,5] -> 1_2_4_5

это на ReplacingMergeTree значит переходить надо? там версии указываются

спасибо

arrayStringConcat(arrayMap(x -> toString(x), [1, 2, 3, 4]), '_')

arrayStringConcat

SELECT arrayStringConcat(['a', 'b', 'c'], '_')

┌─arrayStringConcat(['a', 'b', 'c'], '_')─┐
│ a_b_c │
└─────────────────────────────────────────┘

Спсб большое в доках не нашел - плохо искал

понял мысль. спасибо, можно и на прежнем двиге остаться

First argument for function arrayStringConcat must be array of strings..

A если целые то какая магия?

привести к строке?

ага

arrayMap

Спсб

Чувствую летать будет ))

@milovidov_an Подскажи, другие алгоритмы джоинов помимо hash join не планируются?

Планируем сделать merge join.
Также уже сейчас есть nested loops (для cross join).

merge join - это отлично. Смешно ) я вообще не знал, что есть cross join, ведь в доке он не описан. Хотелось бы возможно выбора nested loops для всего, потому что:
1) Не всегда весь набор таблиц, участвующих в join, влезает в память
2)Часто нужен джоин не только на равенство колонок

@milovidov_an я попробовал 18.1 и сразу наступил на https://github.com/yandex/ClickHouse/issues/2795
и я не могу понять почему это вообще сломалось (читая readme и комиты) и вот теперь уже страшно вообще тестить 18-ю, там вообще много затронуто и что могло сломаться еще?

Разработчики КХ, это просто песня, спасибо вам)

Я помню на митапе в Берлине обсуждался вопрос отсутствия английского слогана для кх. Как на счёт "Clickhouse - performance full house" ?)

Нет правда мы не КХ написали корпоративный мессенджер =) действильно fullhouse

ClickHouse does not lag?

да просто написать Clickhouse -- ne tormozit.
со спатником и перестройкой прокатило.

Is ClickHouse slow? Nyet

clickhouse never slow down

Даун можно опустить

clickhouse - no chaos

не катит, если читать правильно(

А где бы почитать об этом? :(

Я тоже (пока) не знаю, каким образом это сломалось. Ошибка для нас новая; сами уже используем версию 18.5.1 в продакшене. Сейчас будем разбираться.

По количеству изменений, не смотря на изменение схемы версионирования, разница между версиями 1.1.54394 и 18.1.0 такая же как при других релизах.

У нас в настоящее время идёт работа по JOIN. Один из пунктов - поддержка варианта записи, в котором таблицы перечисляются через запятую, а условия приводятся в WHERE. Такой вариант преобразуется в INNER JOIN путём переноса максимального возможного количества условий в ON, но если таких нет - получится CROSS JOIN.

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

ClickHouse - performance first 🤘🏻

*niet

А потом еще добавить "(+)"-синтаксис из оракла для outer join и вообще огонь! :)

Привет всем!
Кто подскажет, что необходимо сделать после изменения схемы хранения, чтобы КХ перезста смердживать данные до 1 минуты, конфиг такой:
<pattern>
<regexp>^DevOps\.clickhouse\.test\.</regexp>
<function>avg</function>
<retention>
<age>0</age>
<precision>5</precision>
</retention>
</pattern>
а данные:
SELECT
Timestamp,
Value
FROM graphite
WHERE Path = 'DevOps.clickhouse.test.testval'
ORDER BY Timestamp ASC

┌──Timestamp─┬──────────────Value─┐
│ 1533703153 │ 6 │
│ 1533703199 │ 13.5 │
│ 1533703259 │ 34.333333333333336 │
│ 1533703269 │ 43.5 │
│ 1533703319 │ 90.5 │
│ 1533703342 │ 116.16666666666667 │
│ 1533703439 │ 163.64285714285714 │
│ 1533703492 │ 219 │
│ 1533703619 │ 257 │
│ 1533703679 │ 321.5 │
│ 1533703739 │ 375 │
│ 1533703784 │ 415.5263157894737 │
│ 1533703799 │ 433 │
│ 1533703859 │ 492 │
│ 1533703919 │ 522 │
│ 1533703979 │ 577.5 │
│ 1533704039 │ 640.5 │
│ 1533704099 │ 694.5 │
│ 1533704119 │ 714 │
│ 1533704219 │ 746.5 │
│ 1533704246 │ 767.0357142857143 │
│ 1533704279 │ 801 │
│ 1533704339 │ 856.90625 │
│ 1533704395 │ 911.5 │
│ 1533704459 │ 922 │
│ 1533704519 │ 981.5 │
│ 1533704579 │ 1036.5 │
│ 1533704623 │ 1078.1818181818182 │
│ 1533704639 │ 1092.5 │
│ 1533704642 │ 1102 │
│ 1533704663 │ 1113.5 │
│ 1533704679 │ 1131.5 │
└────────────┴────────────────────┘
шлю каждую секунду

инкрементальный счетчик

+1. Очень ждем. И ещё бы разобраться с поведением звездочки и алиасов https://github.com/yandex/ClickHouse/issues/2786

Подскажите пожалуйста по поводу рабочей практики бекапа данных КХ. Кто как делает?

Настройки в отжельном xml-файле. Он просто не действует. Как заставить КХ брать настройки хранения из отдельного файла?
пробовал его и <include_from> и складывать в conf.d рядом с config.xml

мы пишем в 2 кластера

даже, если мы представим, что мы сняли бекап в ~30ТБ, то время восстановления будет неприемлимо

А каким образом в два кластера? Вы имеете в виду шардирование? Или каким-то определенным образом данные перегоняете?

я имею ввиду 2 кластера отдельных

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

Доброго времени суток! Господа кто нибудь связывал 1с и кх? Кх как бэкэнд в замену постгри

Т.е по сути вы просто дублируете данные?

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

КХ для этого не предназначен, ИМХО.

да