Добрый день, насколько странная затея делать MV поверх distributed table, я так понял что MV срабатывает строго на insert, данных из таблицы не читает, тоесть если на нескольких машинах будет такая MV + distributed table, то на каждой из них в MV попадет только то что пытались записать в distributed table на этой ноде

Для упрощения представим что под distributed table - tables with null engine

Я выполняю на определённой ноде запрос insert from select который пишет в распределенную таблицу

Данные попадут только в MV на этой ноде ?

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

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

Дружится на раз рисуется быстро примеры есть. Стоит один раз разобраться

ну вот например https://i.tk-chel.ru/denisio/sharex/20190501_132949.png

не могу понять как объяснить графане что t это ось X всё таки

тоесть запрос выполняется, возвращает там несколько пару тыщ записей, с корректным значением unix time (как на play.grafana.org) но чот график не строица, хотя я добавил уже series одну, указал прямо как в примере

если переключить в histogram -оно показывает гистограмму https://i.tk-chel.ru/denisio/sharex/20190501_133120.png

но если вернуть обратно ось в time то пустой график

Включите отображение точек. Либо null as zero.

я уже всё что можно включил

если мышкой водить по графику то оно показывает неверную дату-время https://i.tk-chel.ru/denisio/sharex/20190501_133743.png

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

Остальное - требует сильного допиливания

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

причем по всей площади графика эта дата-время и это значение...

и это последнее значение в наборе данных

1823

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

Подозреваю, что, точно не в районе 1556700178

Можно каким нибудь запросом узнать тип partitionBy expression таблицы? Нужен workaround для https://github.com/yandex/ClickHouse/issues/4735

В настройках панели прямо над текстом запроса есть же выбор «что считать временным рядом», не помогает?

я уже там выбрал

последняя версия?

да

именно такие

а диапазон дат в графане какой установлен?

Странно, так то кликхаус с графаной дружится на раз и работает, на мой вкус приятнее графаны +инфлюкса, я для графиков Jmeter делал панели, если нужны примеры, они опубликованы

я в запрос воткнул захардкоженый диапазон

А графана в курсе?

графане я поставил ваще 5 последних лет

тоесть заведомо больший

DT - точно таймштамп секунд от 1970 года, а не какой-нибудь счётчик?

уже ищу

Да просто SELECT DT с тем же условием и LIMIT 10

ща

графана генерит что-то типа:
SELECT (intDiv(toUInt32(datetime), 300) * 300) * 1000 as t,

здесь 300 - это шаг в секундах

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

datetime тут - именно datetime кх

https://i.tk-chel.ru/denisio/sharex/20190501_135625.png

блядь и правда.

?

*1000

Ну... Вот!

видимо мало было кофе.

как я так затупил

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

Подскажите пожалуйста, можно удалить партицию, не делая предварительно detach?

alter table ... drop partition 'partname'

вроде работает

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

С датасорсом. Там же все просто делается через встроенные переменные и не надо мудрить с расчётом datetime

Я больше думал про rm ;) можно им удалять?

это выглядит как ожидаемое поведение в любой друго SQL DBMS, но мы же с вами знаем что КХ особенный. Это точно работает в КХ ?

Ну так и удаляет партицию с указанным именем. Место освобождается.

Да

Да. Проверить это занимает минуты 3. В чем затруднение?

В кх есть тестовый кластер из локалхоста можно на одной ноде тестить https://github.com/yandex/ClickHouse/issues/5142

Откуда в query_log может быть ненулевой result_bytes в INSERT запросе?

Ещё вопрос: что значит ненулевой read_rows/bytes в INSERT запросе?

Просто пишу в две таблицы каждые 30с, в одну по ~8к записей, в другую по ~500 записей.
— Записи в query_log для большой таблицы показывают дикие тайминги (по 20сек), нулевые read_* и НЕнулевые result_*
— Записи в query_log для малой таблицы показывают до 10мс, НЕнулевые read_* и нулевые result_*

Куда можно покопать?

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

Почему тогда нет его для insert-а в малую таблицу?

Причём это повторяется каждый insert

таблицы одинаковые distributed / replicated ?

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

советую протестить весь лайфсайкл долго и упорно

Без репликации

Таблицы только кол-ом столбцов отличаются

А есть воркэраунд для?

select arrayFilter( x -> x = 'a' , arL) from (select cast (['a','b'] as Array(LowCardinality(String))) arL)
Expression for function arrayFilter must return UInt8, found LowCardinality(UInt8).

18.14.18 (мне тупо идею протестить (я понимаю что пофикшено уже).

Зря обновились… :(

2019.05.01 21:05:07.159247 [ 76 ] {cb6d722a-9140-4d1a-a875-2a34a1411af0} <Error> executeQuery: Code: 44, e.displayText() = DB::Exception: Cannot insert column samplingKey, because it is MATERIALIZED column.

Кастить в массив обычных типов перед лямбдой

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

Интересно можно ли сделать в памяти словарь LC на миллион элементов (у меня 2 млрд. String, а уникальных 1млн.).
Если сделать вручную на cityHash64, то памяти уходит в 3 раза меньше, чем с LC

create table memh (v String, h UInt64) Engine = Memory;
insert into memh
select v, cityHash64(v) h

Можно класть на диск LC, но для лямбд надо кастить обратно в 18.14

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

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

SELECT
used_time,
$timeSeries as t

FROM $table
WHERE $timeFilter
group by t
order by t

вылезает ошибка
ERROR:Code: 215, e.displayText() = DB::Exception: Column used_time is not under aggregate functi

единственное что нагуглил - надо used_time запихнуть в group by, но из-за этого перестает работать отображение, показывает будто нет поинтов
что можно сделать?

used_time это метрика? тогда должно быть sum(used_time) или avg(used_time) или max/min ...

спасибо большое, все заработало

А если у меня работают джойны в матвьюхах?

Ну как повезет. https://github.com/yandex/ClickHouse/issues/5142
Но тут вопрос еще осмысленности join в mv, если правая таблица маленькая то лучше сделать словарь ( словари работают в тысячи раз быстрее ) если таблица большая то join вообще нереально медленно и есть шанс сломать заливку при вылете по памяти.

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

Есть способ узнать, на что именно тратится время в запросе? В логах executeQuery, потом через 10с Done processing query

/report

!report

@valyala а есть какой-то способ в chproxy не кешировать на per-request-основе? в основном ведь запросы отправляются с уже установленных соединений, а соединения сами инициализируются с user/password, то есть несколько пользователей в одном приложении держать накладно, а иногда есть запросы, которые, например, делают выборку не count, а просто колонок, и такие кеширвоать уже не хотелось бы

привет

упс, no_cache

Только что узнал про chproxy, день прожит не зря

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

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

Привет 😁

По поводу гошного драйвера ещё актуально, или это что то старое ?

посмотрел документацию и https://github.com/yandex/ClickHouse/blob/master/dbms/src/Core/Settings.h , но не нашёл ничего подходящего по смыслу.

длинные строки? Наверное max_block_size может влиять. Т.е. кх решает помержить 25 кусков в один, берет и читает из 25 кусков 25*65к

Ну само mv никак на селекты не влияет. Запросы выполняются к обычной таблице в которую mv запихнуло данные.

Нет ли, случайно, в данных, длинных строк?

длинные строки есть. в одной таблице 2кб, в другой ещё больше.

а максимальное количество кусков как ограничить?

Ну это небольшие, в 5 гб должен мерж помещаться.

А что в system.merges когда мерж идет?

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

тогда тоже не нашел как ограничить память мержей, но искал не очень долго

странно то, что есть у меня одна "неправильная" таблица с очень большими строками и index_granularity=128 . Так там нет проблем с мержами почему-то.

У меня просто виртуалка с 2 гигами памяти. А настройки CХ дефолтные, и я пока не разобрался, как его настроить, чтобы он влезал в свободные полтора гига. Пока своп-файл добавил огромный, но мне это не нравится. Надо СХ настроить конечно.

оно так быстро проходит, что ничего.

в логе ошибок вот такое было, пока своп не добавил:
0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x73fd046]
1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x22) [0x377e942]
2. /usr/bin/clickhouse-server(DB::throwFromErrno(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int)+0x171) [0x73e4811]
3. /usr/bin/clickhouse-server(Allocator<false>::realloc(void*, unsigned long, unsigned long, unsigned long)+0x2bb) [0x73e129b]
4. /usr/bin/clickhouse-server() [0x6a27917]
5. /usr/bin/clickhouse-server(DB::ColumnVector<unsigned char>::insertRangeFrom(DB::IColumn const&, unsigned long, unsigned long)+0xbc) [0x6a3efcc]
6. /usr/bin/clickhouse-server(DB::ColumnArray::insertFrom(DB::IColumn const&, unsigned long)+0x36) [0x69e37b6]
7. /usr/bin/clickhouse-server(DB::ReplacingSortedBlockInputStream::insertRow(std::vector<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn>, std::allocator<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn> > >&, unsigned long&)+0x1b9) [0x6d539a9]
8. /usr/bin/clickhouse-server(DB::ReplacingSortedBlockInputStream::merge(std::vector<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn>, std::allocator<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn> > >&, std::priority_queue<DB::SortCursor, std::vector<DB::SortCursor, std::allocator<DB::SortCursor> >, std::less<DB::SortCursor> >&)+0x743) [0x6d54283]
9. /usr/bin/clickhouse-server(DB::ReplacingSortedBlockInputStream::readImpl()+0xeb) [0x6d551eb]
10. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x178) [0x677baf8]
11. /usr/bin/clickhouse-server(DB::MergeTreeDataMergerMutator::mergePartsToTemporaryPart(DB::FutureMergedMutatedPart const&, DB::MergeListEntry&, long, DB::DiskSpaceMonitor::Reservation*, bool)+0x1f16) [0x6b6c0b6]
12. /usr/bin/clickhouse-server(DB::StorageMergeTree::merge(bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)+0x3c5) [0x6ab67d5]
13. /usr/bin/clickhouse-server(DB::StorageMergeTree::backgroundTask()+0x19f) [0x6ab8b8f]
14. /usr/bin/clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x44e) [0x6b1d7fe]
15. /usr/bin/clickhouse-server() [0x6b1e279]
16. /usr/bin/clickhouse-server(ThreadPoolImpl<std::thread>::worker(std::_List_iterator<std::thread>)+0x1ab) [0x7402fdb]
17. /usr/bin/clickhouse-server() [0xb27522f]
18. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7fea58e836db]
19. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fea5840288f]
(version 19.5.3.8 (official build))

Ну два гига это ни о чем. Там кеш марков по дефолту 5 гб кушает, надо все резать. Сколько клолонок в таблицах? Вертикальные мержи активируются если 11 колонок.

Знаю, что мало памяти. Но пока так.
посмотрел, во всех таблицах менее 11 колонок.

ну тогда можно попробовать vertical_merge_algorithm_min_columns_to_activate=5

а как они работают?

алгоритмы

https://t.me/clickhouse_ru/65094

Всем привет!

У нас КХ после неверной конфигурации репликации переименовал все парты в ignored_bla_bla

как их правильно обратно приаттачить к таблицам?

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

все ноды были неверно сконфигурированы

все реплики ушли в детач

переименовать и https://clickhouse.yandex/docs/en/query_language/alter/#alter_attach-partition

ОК, пасиб!

спасибо.

через ALTER TABLE это никак не поменять?

при чем тут table вообще? У вас что за проблема?

выше же обсуждали: проблема в малом количестве оперативки. КХ доступно всего полтора гига памяти.

в чем проблема с прописать в конфиге кх этот параметр?

А можно?

точно! прочитал коммент:
/** Settings for the MergeTree family of engines.
* Could be loaded from config or from a CREATE TABLE query (SETTINGS clause).
*/

<?xml version="1.0"?>
<yandex>
<merge_tree>
<vertical_merge_algorithm_min_columns_to_activate>5</vertical_merge_algorithm_min_columns_to_activate>
</merge_tree>
</yandex>

+рестарт

да, я разобрался, как опцию прописать.

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

большинство применяются без рестарта, но не merge_tree

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

а, или через SET ?

ничего не надо делать, сразу и само применяется.

круто!

@alexanderzaitsev митап 4 числа в СФ территориально где будет?

Где-то между Сан-Франциско и Сан-Хосе. Мы пока выбираем место.

ну как бы да, очевидно что в Бей Эрия. Просто тяжело РСВПшиться пока не понятно куда ехать =)

Ну там все близко. В ближайшие пару недель определимся с местом. Месяц впереди

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

Скорее всего в южной части, ближе к Сан-Хосе

Привет. Может быть кто-то может подсказать про нюансы работы планировщика

Делаю запрос
SELECT
country,
count()
FROM clicks
GROUP BY country

Получаю
Code: 158. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Limit for rows to read exceeded: 540719824896 rows read (or to read), maximum: 30000000000.

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

SELECT
country,
count()
FROM clicks
WHERE 1 = 0
GROUP BY country

Ok.

0 rows in set. Elapsed: 0.523 sec.

- результат тоже ок. Я ожидал, что планировщик такой запрос вообще не будет отдавать на выполнение но куда тогда делись 523мс?

Добрый день!
Подскажите, пожалуйста, какой драйвер Вы используете для работы с Clickhouse на python3? Или все используют http ?

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

если воспроизводится и можете сделать семпл не зависящий от данных (например, берущий данные из system.numbers), прицепите сюда https://github.com/yandex/ClickHouse/issues/4242

1. Оптимизации order by нет. Будут отсортированы все строки.

2. Clicks это distributed таблица?

компресии сетевого трафмка? Она есть.
Pooling? Chproxy

> 2. Clicks это distributed таблица?

Да

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

Нет, кластер не очень большой и в одном ДЦ

set send_logs_level='trace'
будет видно что происходит

и версия кх?

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

18.14.19

Ничего не понял. Компресия трафика есть. Какой протокол/api используется?

https://github.com/kshvakov/clickhouse
tcp

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

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

пока не тестили

ну в плане, нам бы сильнее сжатие :))

400 мегабит отъедать на экспорте очень жестко

можете по UDP их гнать, напишите воркер который их будет принимать и в КХ пачками укладывать

мы сейчас планируем просто на отдельном интерфейсе экспорт настроить

`2019.05.03 12:16:41.717247 [ 24 ] {cfcefc07-82b5-418b-8f5e-e8e51719f702} <Error> executeQuery: Code: 241, e.displayText() = DB::Exception: Memory limit (for query) exceeded: would use 128.00 TiB (attemp
t to allocate chunk of 140737488355328 bytes), maximum: 9.31 GiB (version 19.5.3.1) (from 127.0.0.1:58126) (in query: show tables), Stack trace:` - интересно, а что это такое?

Здраствуйте. Хотел уточнить по внешнему словарю Mysql. Реально ли сделать так чтобы он запрашивал из многомиллионой таблицы, только те которые изменились, а не все сразу? Я читал про invalidate_query, но выглядит так что он просто не будет обновлять записи в словаре, но запрос будет как всегда

Вроде бы была возможность проверки по updated полю

И выкачивания только изменившихся, соответственно

вот пример бы)

update_field нужно указать в конфиге

Чёт доку щас порыл, не нашёл, кстати

а где конкретно?

https://t.me/clickhouse_ru/81465

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

А он и так на диске их выполняет)))

Это превышено потребление памяти по умолчанию. Смотрите настройку max_memory_usage

У меня запрос, который не помещается в памяти. Хочу сделать в external, но max_bytes_before_external_group_by не очень помогает =/

В запросе делается groupArray… и там в массиве для многих ключей группировки очень много значений 10000+. А потом я разворачиваю это в пары
arrayJoin(arrayMap(i -> [stages[i], stages[(i + 1)]], arrayEnumerate(arraySlice(stages, 1, -1)))) AS pairs
Всё это на 1.2 Млрдах строк.. Так что ClickHouse вываливается в OOM, но посчитать всё же хочется.
Если принудительно ограничить цепочки stages определённой длиной, например, 1000, то более менее отрабатывает

ага, для show tables - никак без 128Tb памяти такой запрос, конечно, не выполнить

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

in query: show tables. Не заметил, сорри

SELECT count() FROM system.tables

А тут что?

max_bytes_before_external_sort max_bytes_before_external_group_by
https://clickhouse.yandex/docs/en/query_language/select/#order-by-clause

Спасибо. max_bytes_before_external_sort покручу

ну баг скорее всего в вычислялке

https://github.com/yandex/ClickHouse/issues/5105#issuecomment-486470614
это из-за arrayEnumerate и скорее всего можно без него переписать

create table X(stages Array(String)) engine = Memory;
insert into X select arrayMap(x->toString (x) , range(1000)) from numbers(1000);

select arrayJoin(arrayMap(i -> [stages[i], stages[(i + 1)]], arrayEnumerate(arraySlice(stages, 1, -1)))) AS pairs
from X limit 3 Format Null
Peak memory usage (for query): 20.06 GiB.

select arrayJoin(arrayMap( x, y -> [x,y], arrayPopBack(stages), arrayPopFront(stages))) as pairs
from X limit 3 Format Null
Peak memory usage (for query): 57.02 MiB.

Благодарю

а да, еще

Elapsed: 4.752 sec.
vs
Elapsed: 0.021 sec.

По какому принципу происходит мёрж в AggregatingMergeTree для агрегатов, которые не -State? Просто берётся последняя строка? Любая?

любая

Спасибо

А где код этой логики посмотреть можно? MergeTree и ReplacingMergeTree нашёл, а Aggregating не вижу (

Подскажите, а chproxy нужен только когда несколько серверов, для балансировки нагрузки? А когда 1 сервер он ни к чему

вроде как для https

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

Что значит изменить партиции? Изменить данные или схему таблицы?

Нет партиций нет данных

видимо я как-то не правильно выражаюсь

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

ибо слишком дофига партиций получается

Ну сделайте по месяцам и перелейте данные

Зачем было изначально менять дефолт то

Всем привет!
Кто-то работал с https://github.com/the-tinderbox/ClickhouseBuilder ?
никак не могу понять как сделать join без использования using, обычными условиями через ON
Поделитесь опытом кто знает?

Привет. Никак) Пока ещё не реализовали

Можно хаком попробовать через
->from(raw('table any left join table2....'))

Понял, спасибо

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

Через R из КХ доступно почти все. Только ставьте серверный вариант чтоб рядом с КХ стоял. Работает отлично.

@den_crane тут спамец

спасибо. Попробую

немного поэкспериментировали с моделями catboost в ch.

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

Дай пример

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

Да, group by + with totals

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

Через countIf ещё можно, если group by не подходит

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

спасибо, подошло

От чего может быть такая ошибка? https://pastebin.com/zv1NySzT

2019.05.05 18:16:25.127737 [ 36 ] {} <Error> BaseDaemon: (version 19.6.1.251) (from thread 30) Received signal Segmentation fault (11).
2019.05.05 18:16:25.127755 [ 36 ] {} <Error> BaseDaemon: Address: 0x10
2019.05.05 18:16:25.127761 [ 36 ] {} <Error> BaseDaemon: Access: read.
2019.05.05 18:16:25.127767 [ 36 ] {} <Error> BaseDaemon: Address not mapped to object.
......

баньте сразу, бот рекламный

> from thread 30
в логе надо найти что делал тред [ 30 ]

Привет! А строки с датами раньше начала Юникс-эпохи можно как-то в даты преобразовать?
SELECT toDate('1964-11-25')
┌─toDate('1964-11-25')─┐
│ 0000-00-00 │
└──────────────────────┘

Нельзя. Можно лишь хранить даты либо год отдельно, либо в виде числа timestamp-а

Жаль. Спасибо!

Добрый день!
Я хочу держать в Clickhouse события одним из атрибутов которых является tags множество String значений. Для этих целей пытаюсь использовать тип Array(String). Необходимо уметь делать запросы вида where has(tags, '<tag>'). Но в этом случае время выполнения запроса увеличивается в сотни раз. В другой DB подобные вещи делаются с помощь multivalue dimensions, и время запроса наоборот уменьшается.
Подскажите, пожалуйста, можно ли средставими Clickhouse улучшить производительность запросов такого типа?

arrayJoin() используй, мне помогало

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

Дело в том что есть и другие атрибуты по которым нужно уметь фильтровать. И не во всех запросах нужно фильтровать по tags.

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

Покажите сколько в среднем значений в массиве строк. Может у вас там милионые массивы. И в логе КХ есть что-то типа плана выполнения - тоже полезно

максимум 60 значений, в среднем 30

Тогда странно. Попробуйте ещё array Count - может в оптимизации has что-то сломано

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

событие выглядит так дата, id пользователя, домен, tags. Первичный ключ id пользователя. Tags содержит в среднем 30 строковых значений. Таких событий несколько милиардов. У каждого события есть несколько метрик, которые нужно складывать при группировке

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

различных значений тэгов может быть до 2000.

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

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

select name, formatReadableSize(data) as size from (select name, sum(data_compressed_bytes) as data from system.columns where table = 'YOUR_TABLE_NAME' group by name order by data desc )

ну, можно еще их сделать enum-ами, переведя в int
но если различных значений 2000, а тегов максимум 60, то у вас максимум 60 колонок, в которые можно теги всегда все записать
tag_1, tag_2 ... tag_60 ?

максимум 60 это не из-за ограничений, а только по статистике

Да, я понимаю. Будет ли эффективен ключ для запросов с where has, если в него добавить поле Array?

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

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

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

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

Комбинации тегов можно попробовать свести к единому енуму.

кажется что количество таких комбинаций очень большое

строка длиной 2000 из 0 и 1 ?

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

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

ну, вообще, если вы пишете У каждого события несколько десятков тегов. то сделайте с запасом 150 колонок...
или есть вероятность что у вас могут прийти все 2000 тегов?

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

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

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

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

ОК. У вас есть 1кк событий, у каждого есть теги. Допустим уникальных комбинаций ([A, B], [A, C]...) ~ 1000. Вы ищите все события с тегом A, сколько из этой 100 комбинаций вы найдете? Например 20, значит вам нужно вытащить события в котоорых есть полное соответствие этих комбинаций. Теги (Array(String)) штука тяжелая и уникальные комбинации можно хранить в виде хэша, это может сильно помочь, но, нужно будет делать 2-а запроса, один для поиска комбинаций, второй для выборки событий и вот тут уже нужно смотреть насколько будет эффективен первый и, возможно, искать это даже не в КХ, а в КХ только фильтровать по хэшам

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

всем спасибо за идеи, вынужден отойти от компа

Ещё можно матвью сделать с ключом по tag.

С скип индексами можно попробовать покрутиться.
Например, minmax индекс на min из значений в tags или на максимум. Но сейчас вроде только один индекс может использоваться

create table user_likes (
user_id UInt32,
item_id UInt32,
liked UInt8,
year UInt16,
likeDate Date
)
engine MergeTree(likeDate, (year, likeDate), 8192)

INSERT INTO user_likes (user_id,item_id,liked) VALUES
(1,1,1),(1,2,1),(1,3,1),(1,4,0),(1,5,0),
(2,1,1),(2,2,1),(2,3,1),(2,4,1),(2,5,1),
(3,1,1),(3,2,0),(3,3,0),(3,4,0),(3,5,0),
(4,1,1),(4,2,1),(4,3,1),(4,4,0),(4,5,0),
(5,1,0),(5,2,0),(5,3,0),(5,4,1),(5,5,1),
(6,1,1),(6,2,1),(6,3,1),(6,5,0);

помогите составить запрос, чтобы получить как в таблице, это что-то типа коллаборативной фильтрации user-based

Коллеги, добрый день!
Подскажите, как именно работает параметр max_rows_to_group_by.

Пытаюсь с его помощью + group_by_overflow_mode='any' ограничить количество данных в выдаче.

В доке про max_rows_to_group_by написано: "Максимальное количество уникальных ключей, получаемых в процессе агрегации. Позволяет ограничить потребление оперативки при агрегации." и выглядит так, что указав значение 100, то и в результате я буду получать примерно столько записей, но их приходит несколько тысяч.

SELECT last_access
FROM ****
WHERE ****
ORDER BY last_access ASC

┌─────────last_access─┐
│ 2018-01-18 14:46:16 │
│ 2018-12-12 02:03:46 │
│ 2019-04-10 13:37:40 │
│ 2019-04-21 15:42:16 │
│ 1970-01-01 06:28:16 │
└─────────────────────┘

что с сортировкой такое?

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

Можно делать OPTIMIZE FINAL по партициям. Суммарно это дольше. но позволяет "размазать" нагрузку

Отличная идея, спасибо. Я сам до этого как-то не додумался 😉

Надо смотреть что там в toInt32 скорее всего так 2106 год показывается.

Увеличивается в сотни раз по сравнению с чем? Возможно where и prewhere надо вручную выбрать.

По сравнению с запросом без has

А что в клиенте Elapsed: xxx. Processed xxx в первом и во втором случае, можно всю строчку целиком

а если вручную все предикаты кроме has в prewhere а has в where?

Про prewhere не знал. Спасибо. Попробую

Посмотрю. Сейчас не помню

┌─────────last_access─┬─toInt64(last_access)─┐
│ 2018-01-18 14:46:16 │ 1516275976 │
│ 2018-12-12 02:03:46 │ 1544569426 │
│ 2019-04-10 13:37:40 │ 1554892660 │
│ 2019-04-21 15:42:16 │ 1555850536 │
│ 1970-01-01 06:28:16 │ 4294956496 │
└─────────────────────┴──────────────────────┘

бабка переполнилась

бабка?)

т.е. это реально 10799 секунд, где-то с отрицательными числами что-то не так

toDateTime(1): 1970-01-01 03:00:01
toDateTime(0): 0000-00-00 00:00:00
toDateTime(-1): 1970-01-01 09:28:15
toDateTime(-10799): 1970-01-01 06:28:17
toDateTime(-10800): 1970-01-01 06:28:16
toDateTime(-100000): 2106-02-06 05:41:36

магия таймзон🤔

а в чем магия-то?

в непоследовательности

1970-01-01 06:28:16 -- https://github.com/yandex/ClickHouse/issues?utf8=%E2%9C%93&q=is%3Aissue+1970-01-01+06%3A28%3A16

спасибо)

я лицензированный телепат 8-го уровня, но не осилил
>что-то типа коллаборативной фильтрации user-based

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

к сожалению prewhere никак не повлиял

20 rows in set. Elapsed: 0.514 sec. Processed 31.65 million rows, 2.34 GB (61.61 million rows/s., 4.56 GB/s.)

20 rows in set. Elapsed: 248.682 sec. Processed 31.65 million rows, 82.15 GB (127.25 thousand rows/s., 330.34 MB/s.)

Программисты на GO, подскажите пжл, если получать данные из КХ уже в json (select .... format JSON)
то как обойтись без row.scan и сразу получить json в виде одной строки из запроса, что бы его дальше отправить на клиент?

http.Client.Get и пайпнуть response.Body через io,Copy, но с таким же успехом можно в КХ сходить

У вас колонка с тегами весит неприлично много, с этим придется что-то делать

20 rows in set. Elapsed: 0.514 sec. Processed 31.65 million rows, 2.34 GB (61.61 million rows/s., 4.56 GB/s.)
20 rows in set. Elapsed: 248.682 sec. Processed 31.65 million rows, 82.15 GB (127.25 thousand rows/s., 330.34 MB/s.)

странно, надо смотреть план.

А если where tag вынести во внешний запрос что тогда?
select * from(
select tag ..... from ..... prewhere ....
) where tag has

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

Можете попробовать интовый массив UInt16, будет побыстрее. Ну и сделать словарь, например, чтобы по инту вытягивать название tags.

Коллеги, очень нужен ваш совет по этому вопросу.

set max_rows_to_group_by = 10000
select number from numbers(1000000) group by number format Null;
65536 rows in set.

вы по-моему пытаетесь лечить головную боль шуруповертом.

set max_rows_to_group_by = 100000
select number from numbers(1000000) group by number format Null;
131072 rows in set.

и где тут связь между 10000 и 65536?

вам точно это надо?

set max_rows_to_group_by = 100
set max_block_size=100
200 rows in set.

Есть жирный запрос с множественными группировками, который съедает пару десятков ГБ оперативы. Чтобы избежать сильной нагрузки на КХ выбор пал на солюшен с max_rows_to_group_by + group_by_overflow_mode='any', однако количество возвращаемых строк никак не коррелирует со значением max_rows_to_group_by, хотя хотелось бы

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

результат неверный при group_by_overflow_mode='any', какая разница сколько там строк возвращается.

https://clickhouse.yandex/docs/ru/query_language/select/#select-group-by-in-external-memory

т.е. бага на стороне КХ, раз результат неверный?

при чем тут бага, у вас в результате запроса должно вернуться один набор, а вы стреляете в ногу c group_by_overflow_mode и говорите верни что-нибудь, любые 100, ну возвращается вам любых 65тыс, потому что проверка делается на другом уровне пайплайна, какая разница-то, 100 и 65536.

Тогда вопрос, почему оба эти параметра в доке стоят рядом и логично их использовать вместе. А тут про разные уровни выясняется🤔

мммм. КХ обрабатывает запрос блоками, max_block_size задает размер блока, ну проверяется max_rows_to_group_by где-то наверху ну какая разница-то? Может вы семплинг хотите из говна и палок сделать? Так он есть уже встроенный.

Спасибо что попробовали)

Попробую на stackoverflow

Разницы бы не было, если бы все работало как заявлено в доке :)

ок исправлю, напишу что max_rows_to_group_by это target

Всем привет. ClickHouse умеет преобразовывать такой формат даты: 2019-05-06T10:17:45.749Z
в обычный DateTime?

если нет, то как сделать чтобы смог?)

при вставке или при селекте? date_time_input_format=best_effort / parseDateTimeBestEffort

это в материализед вью, когда данные селектятся из таблицы кафки

parseDateTimeBestEffort

спасибо

Господа, доброго дня. Подскажите, пожалуйста, ответ возможно на очевидный или уже ни раз разжеванный вопрос. Только изучаю CH и поглядываю на Kafka. Может ли случиться так, что при чтении напрямую в CH из Kafka средствами materialized view, первый будет не успевать разгребать очередь из второго. И если да, то как это решается не выходя за пределы этой связки?

взять 2,3,8 сервера КХ и натравить на один топик кафки.

А несколько materialized view создать на одну и ту же очередь в одну и ту же таблицу нельзя или это абсурдно?

узкое место это не materialized view , узким местом станет вставка в таблицу (мержи (дисковый i/o)). Т.е. берите топовые NVME, делайте из них raid0 и кафка станет узким местом.

Вас понял, спасибо большое!

Привет сообщество, все же немного не хватает мне документации и окружения, что бы понять одну ситуацию.
1) Использую API метрики для получения хитов (Logs API), хранятся в табличке hits_all
2) Есть табличка page_all и в ней урлы и собственно нужные мне колонки

Вопрос
Как правильней организовать логику получения кол-ва хитов в hits_all (за месяц/неделю) по урлу из page_all (используя like(URL, concat(URL, %)) при условии что в page_all на запрос может быть ~2к урлов и каждый нужно проверить в hits_all
Как можно оптимизировать эту ситуацию?

Что есть сейчас
Вполне рабочее решение, но выполняется ~20-30минут на доастаточно мощной ВМ. Как и описал в в поросе. Фильтруется по параметрам page_all, берется каждый урл и считается кол-во совпадений в hits_all.

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

Мне ключ добавлять при заполнении таблицы из metrics api?

если возможно, тут как бы непонятно для чего еще используется hits_all, поэтому трудно сказать. Может вообще все возможно посчитать априори на этапе ETL и положить готовые результы в ексель.

А почему в документации нет про авторизацию через X-ClickHouse-User ничего? Это устарело?

Вообще из hits_all строится несколько отчетов. Количество просмотров (включая частичные совпадения), источники,

Ведь в числовом хэше строка example.com/path и example.com/path/?ref и sub.example.com/path/ - будут сильно разными, а еще бывают варианты yandex.ru/turbo/url=example.com/path и это ведь жесть. в цифрах будет хаос.

ну естественно нужна очистка

А очистка лишит возможность разделить эти источники

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

А как думаешь, если я буду с помощью либы https://github.com/yndx-metrika/logs_api_integration получать логи метрики (посуточно) и после получения перебирать лог, разбирать/считать урлы и складывать в одельную табличку (Merge) паралельно очищая лог метрики

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

28 275 981 - до группировки
1 382 108 - после группировки (это 5% от сырых данных)

а если это делать еще и ежедневно, то объем сократится с ~1 000 000 до ~50 000 строк

Правильно мыслю?

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

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

Понял, спасибо. Пойду разбивать урл и переписывать все с Log в Merge

ClickHouse на море :)

Доклад будет? )

5 будет, но завтра

блин надо было ехать на кипр на эту конфу

Расскажите в 2 словах зачем использовать материализованную вьюху и в чем ее преимущество перед таблицей

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

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

https://gist.github.com/den-crane/6eff375752a236a456e1b3dc2ca7db62

все вышеперечисленное, а еще как insert trigger для аггрегации

Так я же могу и в таблицу предагрегировать?

с mat view оно "само" будет аггрегироваться при вставке в src таблицу

можете, а теперь представьте что вам предагрегировать в 8 разных агрегатов, сгруппировав по разным дименшинам и еще и факты оставить в изначльном виде.

Так вьюха занимает место как таблица? Изменяет агрегированные данные при вставке в таблицу?

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

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

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

Яндекс.Метрика поди :)

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

ну это понятно
но что за проект?
яндекс метрика?

не знаю что такое метрика, обычная контора с оптимизацией трафика в кали (если очень хочется найти название, то есть ссылка из моего гитхаба)

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

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

И все же чем будет отличаться создание таблицы в AggregatingMergeTree от view? кроме того что необходимо хранить изначальную таблицу фактов?

3 rows in set. Elapsed: 3.265 sec. Processed 300.00 million rows
VS
3 rows in set. Elapsed: 0.024 sec.

https://gist.github.com/den-crane/32cac4f069f4227b35ab86553bbc649b

Вы там сравниваете с MergeTree, а я вопрос задал про AggregatingMergeTree . Или на этой схеме нельзя создавать таблицы?

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

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

CREATE MATERIALIZED VIEW mvz1 ENGINE = AggregatingMergeTree order by (d) settings index_granularity = 8
as select d, uniqState(u) as us from z group by d;

и получу данные в новом агрегате (по дням)

Вы сейчас описали обычную вьюху например SQL Server. А как я понимаю в ch она реально существует, как и таблица, только обновляется при вставке в таблицу.

MV это такой триггер на инсерт (с неудачным названием), который чем-то издалека похож на materialed view из другх субд (оракл).

Почти во всех СУБД этого класса существуют и вьюхи, и матвьюхи. Первая — это шорткат для селекта, вторая — это физическая таблица, которая обновляется по триггеру или по расписанию

Спасибо за пояснения!

Просто я использую sql server и там нет такого понятия

гугль говорит что они в msql называются indexed-views

да, именно так

Ну скорее всего, они больше всего на это похожи

Кажется вам должен помочь фичер под названием roaring bitmap, появившийся в 19.4. Нужно перемаповать эти строки в числа, а потом на них сделать roaring bitmap. После чего всякие вхождения элемента или пересечения /объединения должны сделаться очень дешёвыми операциями.

См. https://github.com/yandex/ClickHouse/pull/4207/files

Сначала маппинг строк в числа (лучше autoincrement с 1). Потом из таблицы числовых тэгов делаете bitmapBuild. Потом можно сделать битмап с искомыми элементами и считать размер пересечения. Довольно замысловато, и фичер пока сильно экспериментальный. Но по идее как раз ваш кейс хорошо в него должен укладываться.

Подскажите тогда. У меня есть таблица в которой есть несколько столбцов. Поиск происходит по различным столбцам, и для повышения производительности мне приходится делать несколько одинаковых таблиц с разными индексами. Что не очень удобно. Может есть смысл не заливать данные в несколько таблиц, а сделать одну таблицу и к ней создать несколько materialized view? Какой подход будет правильнее?

Матвью в такую же таблицу с другим индексом - нормальное решение. Так делают, все должно работать.

в принципе особой разницы нет (я пользуюсь и тем и этим подходом одновременно), но MV позволит сделать один insert.

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

То есть нельзя будет дропнуть секцию?

таблица получает буфер с новыми строками в момент инсерта, и пушит этот буфер во все свои MV.
Таблица может вообще не хранить данные (engine=Null). Все независимо, можете дропать, удалять, апдейтить по отдельности, таблица и таблицы хранящие данные MV никак не связаны. MV никогда не читает из таблицы (только в момент populate)

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

создавайте таблицу явно (более того можете взять уже существующую) и создавайте MV to...
https://gist.github.com/den-crane/f7382cd4f1f859ff6ac46afe7dc9925a
так проще изменять вью (через drop /create)

Если честно не уловил идею. Чем этот пример отличается от простого создание матвьюхи над таблицей? Зачем таблица temp и store?

это пример более широкий, идея вот в чем

create table mv_z_store(a date, max_b AggregateFunction(MAX,Int64)) ENGINE = AggregatingMergeTree Partition by toYYYYMM(a) order by a;
create MATERIALIZED VIEW mv_z to mv_z_store AS SELECT a, maxState(b) AS max_b FROM some_fact_table GROUP BY a;

это позволяет обращаться к таблице которая хранит данные по нормальному имени mv_z_store, вместо .inner.mv_z

плюс это позволяет проще делать alter

например добавлять поля

делаем drop mv_z, alter mv_z_store , create mv_z с новым запросом

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

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

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

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

Официальный образ? Спасибо за ответ :) Внушает надежду.

У нас есть такой сервер. Смысла в докере нет никакого, больше неудобств, но оно работает.

У нас работает на проде в докере. Образ официальный. С нового года где-то. Полёт нормальный.

Подскажите. Можно ли сделать хэш партиции? Например, чтобы было 32 партиции

В оракле есть такая штука. Может и в КХ есть

Спасибо всем. Буду пробовать.

Смысл такой , что призодят запросы со стоковыми айди пользователя в условии where. Таблица большая. Надо партиции сделать , но что бы в одну партиции было много пользователей

Можно, в PARTITION BY пишите условие

пример
CREATE TABLE test_part_hash
(
`date` Date,
`user_id` Int32
)
ENGINE = MergeTree
PARTITION BY (user_id % 32, date)

Спасибо. А как проверить , что он подхватывает нужную партиции в запросе ? В оракле я бы план запроса построил , а в КХ как ?

insert into test_part_hash select today(), number from numbers(2000);
SET send_logs_level = 'trace'
SELECT count() FROM test_part_hash WHERE user_id = 8

Будет видно в Selected parts

Спасибо

Пример не точный, нужно не user_id в PARTITION BY, a hash_id от user_id и его же в запрос SELECT * FROM t WHERE user_id = 42 AND hash_id = user_id %32

Вообще интересный результат получается :)

Он и так походе, что читает только когда одну .

В твоём первом варианте. У меня старый Кх. В нем нет этой настройки с логом, но в логе видно, что при условии where = нету union

А если сделать , например +0 = значение , то union по всем партам есть. Колонка +0 = значение.

Круть ! Спасибо

Вот так правильно

CREATE TABLE test_part_hash
(
date Date
, user_id Int32
, hash_id Int32 MATERIALIZED (user_id % 32)
)
ENGINE = MergeTree
PARTITION BY (hash_id, date)
ORDER BY (hash_id)

insert into test_part_hash select today(), number from numbers(1000000);

SELECT count() FROM test_part_hash WHERE user_id = 8 AND hash_id = 8 % 32

У меня первый вариант тоже работает !

Добрый день, после некорректного выключения базы получил такую ошибку:
2019.05.07 11:30:37.660141 [ 1 ] {} <Error> Application: DB::Exception: Cannot create table from metadata file /var/lib/clickhouse/metadata/ххх/table_yyy.sql, error: Coordination::Exception: All connection tries failed while connecting to ZooKeeper. Addresses: xxx.xxx.xxx.xxx:2181, xxx.xxx.xxx.xxx:2181, xxx.xxx.xxx.xxx:2181

- sudo -u flags/force_restore_data
- zk_client: create /clickhouse/tables/table_yyy/replicas/my_host/flags/force_restore_data test
- rm metadata/ххх/table_yyy.sql + rmr /clickhouse/tables/table_yyy/replicas/my_host
не помогло. Первые два совсем не помогли, последний пропустил table_yyy и перешел к следующей таблице по списку и выдал такую же ошибку (и так для всех таблиц)

Пока не понимаю почему база не запускается и что она хочет сделать

Зукипер поднят и доступен для кх?

с zookeper-м ничего не делали, другие хосты с ClickHouse работают корректно

А зачем вы это делаете если у вас в логе н написано что не доступен ни один зукипер

̶о̶н̶ ̶д̶о̶с̶т̶у̶п̶е̶н̶,̶ ̶с̶е̶й̶ч̶а̶с̶ ̶п̶о̶п̶р̶о̶б̶о̶в̶а̶л̶ ̶с̶ ̶с̶е̶р̶в̶е̶р̶а̶ ̶п̶о̶с̶т̶у̶ч̶а̶т̶ь̶с̶я̶ ̶к̶ ̶н̶е̶м̶у̶

ping до сервера с zookeper - ок
telnet на порт - fail
telnet на порт c другого хоста- ok

А раньше?

Ну вот и ответ

Доброе утро всем любителям шарад и загадок 🙂
Памагите с запросом, ибо не хватает познаний во встроенных агрегирующих функциях 🙁

дано: 3 таблицы:
1) traffic - траффик с фаервола с разобранными по типам пакетами и количеством отправленных/полученных Bytes + ip-адреса
2) dns - сопоставление ip-адреса и dns-имени
3) windows_security - логи windows с логинами пользователей и dns-именами компьютеров
само-собой в каждой таблице имеется EventTime

нужно: отобразить таблицу с логинами пользователей, что запускали torrent-ы в выбранный промежуток времени ( конечная цель - grafana )

предполагаемый порядок действий следующий:
1) выбрать логины пользователей за указаный промежуток времени ( поля Login + ComputerName )
2) добавление в выборку к ComputerName информации о ip-адресе компьютера поле IP ( из таблицы dns )
3) добавление к выборке по полю IP из таблицы traffic информации о наличии трафика по протоколу torrent
но, данный порядок затрагивает лишь доменные windows компьютеры , а по факту может оказаться, что torrent запускались на условно серверах, что не прописаны в dns.
поэтому, есть второй порядок действий, который частично уже работает:
1) выбрать информацию о наличии torrent траффика c полями ip-адрес MegaBytesSent MegaBytesReceived MegaBytes
2) добавление в выборку к ip-адресу информации ComputerName ( из таблицы dns )
3) выбрать логины пользователей за указаный промежуток времени что пользовали torrent

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

SELECT
IP,
ComputerName,
MegaBytesSent,
MegaBytesReceived,
MegaBytes,
TargetUserName
FROM
(
SELECT
IP,
ComputerName,
MegaBytesSent,
MegaBytesReceived,
MegaBytes
FROM
(
SELECT
IP,
(sum(Bytes) / 1000000) AS MegaBytes,
(sum(BytesSent) / 1000000) AS MegaBytesSent,
(sum(BytesReceived) / 1000000) AS MegaBytesReceived,
FROM
traffic
WHERE
EventDate BETWEEN today() - 2 AND today()
AND Application = 'torrent'
AND IP LIKE '192.%'
GROUP BY
IP
HAVING
MegaBytes > 10
) ANY
LEFT JOIN (
SELECT
IP,
ComputerName
FROM
dns
) USING (IP)
) ANY
INNER JOIN (
SELECT
EventTime,
ComputerName,
TargetUserName
FROM
windows_security
WHERE
EventDate BETWEEN today() - 2 AND today()
AND EventID = 4624
AND (
LogonType = '7'
OR LogonType = '2'
)
) USING ComputerName

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

черт, искал не то и не там. Просто так совпало и искал ошибку в своих действиях. Благодарю!

Всем привет. Можно ли в таблице сделать поле с именем @timestamp?

и как потом с ним работать?

А что за логика с materialuzed view? Я создал materialized view as select count() из таблицы . И там строки добавляются, а я бы ожидал ,что при каждой вставке в мастер таблицу идёт сначала truncate materialized view, а потом инскрт

CREATE TABLE reserved_word_table (index UInt8) ENGINE = MergeTree ORDER BY index;

ой, скушалось

https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00933_reserved_word.sql

спасибо

Привет, подскажите как быть с now()
1. Добавил в табличку колонку с текущим временем:
ALTER TABLE table_name
ADD COLUMN update_time DateTime DEFAULT now();
2. Сделал инсерт нескольких строк
3. Селекчу - для крайней записи всегда отрабатывает now() и возвращает текущее время вместо времени инсерта
Это ожидаемое поведение? Можно как-то сделать, чтобы now() отрабатывал только при инсерте и сохранял это значение?

У MV правильная логика, у вас нет

Может быть. Но эта логика не как в оракле. В оракле или рефреш по времени ( с выполнением dekete or truncate ) или при вставке, но тогда уже есть ограничения на текст mv

Вы сделали MV с обычным движком, он и будет на каждую вставку в таблицу - добавлять записи.
Вам нужно было посмотреть в сторону https://clickhouse.yandex/docs/ru/operations/table_engines/aggregatingmergetree/, а не просто MergeTree.

Кликхаус это вообще не оракл, никто и не обещал, что он будет на него похож.
[тут место для цитаты о том, что КХ вообще делался не для вас, а для яндекс-метрики, но я что-то найти не могу]

текущее для записей которые уже были в таблице до alter . Нужен optimize чтобы перемржить старое и записать на диск колонку.

https://gist.github.com/den-crane/6eff375752a236a456e1b3dc2ca7db62

Вам нужен aggregating и countstate
Или summingmergetree и sum(1)

https://t.me/clickhouse_ru/99951

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

В документации написано:
Полученные сообщения из кафки группируются в блоки размера max_insert_block_size. Если блок не удалось сформировать за stream_flush_interval_ms миллисекунд, то данные будут сброшены в таблицу независимо от полноты блока.
Но я вижу что данные вбрасываются блоками по 65536 штук и собираются явно больше 7.5 секунд. То есть она использует какие то другие пораметры?

max_insert_block_size Значение по умолчанию: 1,048,576

stream_flush_interval_ms по умолчанию 7500

никто не знает про это?

Зависит от версии кх и в кафке многое сломано после 19.6.
кафка движок читает по 65536 (kafka_max_block_size) и ждет пока все не прочитает, а затем уже пишет по 1млн или 7.5с.
Это все уже переделано и в след. релизе будет.

https://github.com/yandex/ClickHouse/issues/4890
А потом опять будет переделано https://github.com/yandex/ClickHouse/issues/5100

Спасибо

А то уже думал что опять все сломал)

По хорошему надо все это собрать в одну таблицу еще до КХ (на этапе ETL).
А так, надо сначало сджойнить, а потом уже считать sum (группировать). Для джойна по несовпадающим промежуткам времени можно округлять (например до часа) или использовать ASOF JOIN.

Всем привет. Подскажите пожалуйста, или дайте ссылку где почитать (в официальной документации не нашла). http://joxi.ru/bmobVZ4c3QdJer интересует, что за параметры, обведенные красными рамками 1 и 2? Заранее благодарю

Это старый синтаксис создания таблиц
Вот тут https://clickhouse.yandex/docs/en/operations/table_engines/replication/#creating-replicated-tables есть пример (Example in deprecated syntax)

Соответственно, в новом стиле ваш пример соответствует
PARTITION BY toYYYYMM(date)
ORDER BY (asc, date)

ага, большое спасибо!

Привет. Подскажите , что делать если висит drop table уже 6 дней и не убивается kill query. Можно ли пофиксить не рестартуя КХ?

Всем привет. А есть какие-нибудь встроенные простые функции типа melt / dcast?
По сути перевод из длинного в широкий и обратно.

а есть другие запросы которые тоже к этой таблице висят, select/alter ? таблица distributed?

select groupArray(a.k), groupArray(a.v) from (
select a.k, a.v from (select ['a','b','c'] `a.k`, [1,2,3] `a.v`) Array Join a)

Нету. Это engine = Kafka

это баг, какая версия КХ? Скорее всего придется выключить КХ и удалить .sql файл вручную

Спс

Добрый день. после обновления с 18.16 на 19.5 Кликхаус просто сам завершает работу при выполнение запросов. oom киллер не приходил, в dmesg сообщения о core-dump не вижу. выглядит это примерно так

↗️ Progress: 86.03 million rows, 682.50 MB (36.59 million rows/s., 290.32 MB/s.) ████████████████████████████████████▎ 32%[chbi1] 2019.05.07 13:56:23.638435 [ 203 ] <Debug> MemoryTracker: Current memory usage: 1.00 GiB.
↗️ Progress: 99.25 million rows, 1.20 GB (25.09 million rows/s., 302.91 MB/s.) ███████████████████████████████▋ 27%Cannot load data for command line suggestions: Code: 32, e.displayText() = DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, 127.0.0.1 (version 19.5.3.1)

Exception on client:
Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, 127.0.0.1

Connecting to database etl_city_import at localhost:9000 as user default.
Code: 210. DB::NetException: Connection refused (localhost:9000, 127.0.0.1)

в perf top смотрел, ну кроме AGregate еще
6.16% clickhouse [.] 0x0000000005cbb1a3
5.04% clickhouse [.] 0x0000000005ccdfcb

откатывать на 18.16 уже не хочется, что можно предпринять ?

DB::Exception: Attempt to read after eof:

Очень часто встречается ошибка у нас, кстати, до сих пор не можем понять её причины, иногда кластер тупо перестаёт принимать любые запросы от клиентов (и на чтение и на вставку) с клиентскими ошибками в логах (eof, client closed connection и так далее), даже коннекты не принимает, пока все клиенты не перезапустишь. Одна особенность - это происходит после одновременно большого кол-ва запросов 10-20 со стороны chproxy (в конфиге ограничение на 30 concurrent queries). Да и в истории чата частенько эта ошибка проскакивает. Такие дела.

да. все верною. используется chproxy, и да, это возникает когда много запрос паралельно. Все верно. при этом с этой же базой и с этими же запросами на 18.16 проблем не было )

запускать клиент как clickhouse-client -A
https://github.com/yandex/ClickHouse/issues/5066

смотреть в лог, если там клеточки - #####

Листаю issues на гитхабе, но их дофига, и некоторые читаю не по своему вопросу, для кругозора. Может, здесь кто подскажет быстрее. Это нормально, что условие из запроса на view, на столбец, который является ключом для исходной таблицы, не оптимизируется?

Table metrics_raw
(
itemid Int64,
clock DateTime,
value Decimal64(4)
)
ENGINE = ReplicatedMergeTree( ... )
PARTITION BY toYYYYMMDD(clock)
ORDER BY (itemid, clock);

Table metrics_hour_state
(
itemid Int64,
clock DateTime,
value AggregateFunction(avg, Decimal64(4))
)
ENGINE = ReplicatedAggregatingMergeTree( ... )
PARTITION BY toYYYYMMDD(clock)
ORDER BY (itemid, clock);

MV aggregator_hour
TO metrics_hour_state AS
SELECT
itemid,
toStartOfHour(clock) clock,
avgState(value) value
FROM metrics_raw
GROUP BY itemid, clock;

View metrics_hour
AS
SELECT itemid, clock, avgMerge(value) value
FROM metrics_hour_state
GROUP BY itemid, clock;

Запрос
select itemid, clock, value from metrics_hour where itemid = 54321
Приводит к полному сканированию metrics_hour_state.

у нас это на 18.12.17, проскакивает 1-2 раза в месяц, никакой логики найти не можем, количество запросов при нормальной работе может и 30 быть одновременно

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

SELECT itemid, clock, avgMerge(value) value
FROM metrics_hour_state
WHERE itemid = 54321
GROUP BY itemid, clock

разница по потреблению памяти между ними огромная, 1536 МБ против 32 МБ (примерно)

А что это значит?

если сервер упал - в логе будет
<Error> BaseDaemon: ########################################
<Error> BaseDaemon: (from thread 1) Received signal Segmentation fault (11).
и полезный трейс

https://t.me/clickhouse_ru/73647

Будет где-нибудь запись митапа в Лимассоле?

Или слайды

Подскажите, если я создаю матвью с агрегатом countState(), то почему при запросе из нее, чтобы получить значение count необходимо использовать countMerge и снова группировать по остальным полям. Как то это не логично

Видео записывается. Будет ли доступно скажу чуть позже.

Спасибо! Было бы хорошо, если бы было

если вам нужен count без группировки вы можете не группировать и в матвью не группировать

countMerge необходим потому что в таблице лежат состояния, их надо финализировать.
Представьте вы бы использовали summingmergetree и считали бы sum(1), каждый инстерт бы вставлял строку с числом = кол-ву строк которое вставилось с этим инсертом, затем summingmergetree постепенно бы мержил и суммировал, до в любой момент времени оно еще не смерженно в одну запись, поэтому вам бы приходилось считать sum() -- финализировать.

Если вам нужен select count where =1, можно взять эту цифру из system.parts

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

вот например я сделал матвью group by user, date, site
это дает мне возможность выбрать например group by date
ну и вообще так больше похоже на стандартный sql

Вот я и не понимая, если я уже сделал group by user, date, site, то зачем мне делать эту же группировку чтобы получить типа уже сгруппированные данные

так бог велел.

Давно бы так, а то все со своими объяснениями 👌🏻

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

То есть я все правильно делаю? Просто я думал, вдруг где-то косячу.

Будет

да, все правильно

Да. действительно. не было в syslog sigfault. в лог даже не полез грепать
2019.05.07 15:23:28.384770 [ 214 ] {} <Error> BaseDaemon: (version 19.5.3.1) (from thread 205) Received signal Segmentation fault (11).
2019.05.07 15:23:28.384783 [ 214 ] {} <Error> BaseDaemon: Address: NULL pointer.
2019.05.07 15:23:28.384790 [ 214 ] {} <Error> BaseDaemon: Access: read.
2019.05.07 15:23:28.384796 [ 214 ] {} <Error> BaseDaemon: Address not mapped to object.

включать коры и присылать ?

что делал from thread 205, обратным поиском [ 205 ]

там после этих строк тред [ 214 ] написал свой стектрейс, для начала его посмотреть бы

./clickhouse-server.log:2019.05.07 15:17:47.741120 [ 205 ] {} <Trace> Aggregator: Merging aggregated data
./clickhouse-server.log:2019.05.07 15:19:47.574810 [ 205 ] {} <Trace> Aggregator: Aggregating
./clickhouse-server.log:2019.05.07 15:19:47.574948 [ 205 ] {} <Trace> Aggregator: Aggregation method: without_key
./clickhouse-server.log:2019.05.07 15:19:47.574968 [ 205 ] {} <Trace> Aggregator: Aggregated. 0 to 1 rows (from 0.000 MiB) in 0.000 sec. (0.000 rows/sec., 0.000 MiB/sec.)
./clickhouse-server.log:2019.05.07 15:19:47.574974 [ 205 ] {} <Trace> Aggregator: Merging aggregated data
./clickhouse-server.log:2019.05.07 15:21:38.747664 [ 205 ] {} <Trace> Aggregator: Aggregation method: key16

./clickhouse-server.log:2019.05.07 15:23:28.384728 [ 214 ] {} <Error> BaseDaemon: ########################################
./clickhouse-server.log:2019.05.07 15:23:28.384770 [ 214 ] {} <Error> BaseDaemon: (version 19.5.3.1) (from thread 205) Received signal Segmentation fault (11).
./clickhouse-server.log:2019.05.07 15:23:28.384783 [ 214 ] {} <Error> BaseDaemon: Address: NULL pointer.
./clickhouse-server.log:2019.05.07 15:23:28.384790 [ 214 ] {} <Error> BaseDaemon: Access: read.
./clickhouse-server.log:2019.05.07 15:23:28.384796 [ 214 ] {} <Error> BaseDaemon: Address not mapped to object.
./clickhouse-server.log:2019.05.07 15:23:28.453060 [ 214 ] {} <Error> BaseDaemon: 0. /usr/bin/clickhouse-server(tcache_bin_flush_small+0x26a) [0x6c4d39a]
./clickhouse-server.log:2019.05.07 15:23:28.453087 [ 214 ] {} <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(tcache_event_hard+0x5a) [0x6c4df6a]
./clickhouse-server.log:2019.05.07 15:23:28.453098 [ 214 ] {} <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(__libc_free+0x25b) [0x6c2bf8b]
./clickhouse-server.log:2019.05.07 15:23:28.453111 [ 214 ] {} <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::ColumnsBlockInputStream::readImpl()+0xb83) [0x5ec5273]
./clickhouse-server.log:2019.05.07 15:23:28.453119 [ 214 ] {} <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453126 [ 214 ] {} <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x65b6b5d]
./clickhouse-server.log:2019.05.07 15:23:28.453133 [ 214 ] {} <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453140 [ 214 ] {} <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::DistinctBlockInputStream::readImpl()+0x91) [0x65df041]
./clickhouse-server.log:2019.05.07 15:23:28.453155 [ 214 ] {} <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453162 [ 214 ] {} <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x65b6b5d]
./clickhouse-server.log:2019.05.07 15:23:28.453169 [ 214 ] {} <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453176 [ 214 ] {} <Error> BaseDaemon: 11. /usr/bin/clickhouse-server(DB::LimitBlockInputStream::readImpl()+0x384) [0x5f68f84]
./clickhouse-server.log:2019.05.07 15:23:28.453183 [ 214 ] {} <Error> BaseDaemon: 12. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453190 [ 214 ] {} <Error> BaseDaemon: 13. /usr/bin/clickhouse-server(DB::ConvertingBlockInputStream::readImpl()+0x3d) [0x65ad0dd]
./clickhouse-server.log:2019.05.07 15:23:28.453197 [ 214 ] {} <Error> BaseDaemon: 14. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453204 [ 214 ] {} <Error> BaseDaemon: 15. /usr/bin/clickhouse-server(DB::FilterBlockInputStream::readImpl()+0xaa) [0x65c25aa]
./clickhouse-server.log:2019.05.07 15:23:28.453210 [ 214 ] {} <Error> BaseDaemon: 16. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453217 [ 214 ] {} <Error> BaseDaemon: 17. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x65b6b5d]
./clickhouse-server.log:2019.05.07 15:23:28.453224 [ 214 ] {} <Error> BaseDaemon: 18. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.453235 [ 214 ] {} <Error> BaseDaemon: 19. /usr/bin/clickhouse-server(DB::DistinctBlockInputStream::readImpl()+0x91) [0x65df041]
./clickhouse-server.log:2019.05.07 15:23:28.453243 [ 214 ] {} <Error> BaseDaemon: 20. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]

./clickhouse-server.log:2019.05.07 15:23:28.453266 [ 214 ] {} <Error> BaseDaemon: 21. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::loop(unsigned long)+0xfb) [0x604bc5b]
./clickhouse-server.log:2019.05.07 15:23:28.453278 [ 214 ] {} <Error> BaseDaemon: 22. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::thread(std::shared_ptr<DB::ThreadGroupStatus>, unsigned long)+0x1f4) [0x604c2f4]
./clickhouse-server.log:2019.05.07 15:23:28.453302 [ 214 ] {} <Error> BaseDaemon: 23. /usr/bin/clickhouse-server(ThreadFromGlobalPool::ThreadFromGlobalPool<DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::process()::{lambda()#1}>(DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::process()::{lambda()#1}&&)::{lambda()#1}::operator()() const+0x67) [0x604cbc7]
./clickhouse-server.log:2019.05.07 15:23:28.453312 [ 214 ] {} <Error> BaseDaemon: 24. /usr/bin/clickhouse-server(ThreadPoolImpl<std::thread>::worker(std::_List_iterator<std::thread>)+0x1cc) [0x6b8b2ac]
./clickhouse-server.log:2019.05.07 15:23:28.453319 [ 214 ] {} <Error> BaseDaemon: 25. /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xbd57f) [0x7f2fcda0557f]
./clickhouse-server.log:2019.05.07 15:23:28.453325 [ 214 ] {} <Error> BaseDaemon: 26. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f2fce0e76ba]
./clickhouse-server.log:2019.05.07 15:23:28.453338 [ 214 ] {} <Error> BaseDaemon: ########################################
./clickhouse-server.log:2019.05.07 15:23:28.453349 [ 214 ] {} <Error> BaseDaemon: (version 19.5.3.1) (from thread 206) Received signal Segmentation fault (11).
./clickhouse-server.log:2019.05.07 15:23:28.453354 [ 214 ] {} <Error> BaseDaemon: Address: NULL pointer.
./clickhouse-server.log:2019.05.07 15:23:28.453360 [ 214 ] {} <Error> BaseDaemon: Access: read.
./clickhouse-server.log:2019.05.07 15:23:28.453366 [ 214 ] {} <Error> BaseDaemon: Unknown si_code.
./clickhouse-server.log:2019.05.07 15:23:28.516622 [ 214 ] {} <Error> BaseDaemon: 0. /usr/bin/clickhouse-server(DB::TablesBlockInputStream::readImpl()+0x3f3) [0x5ee28a3]
./clickhouse-server.log:2019.05.07 15:23:28.516671 [ 214 ] {} <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516681 [ 214 ] {} <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x65b6b5d]
./clickhouse-server.log:2019.05.07 15:23:28.516688 [ 214 ] {} <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516710 [ 214 ] {} <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::DistinctBlockInputStream::readImpl()+0x91) [0x65df041]
./clickhouse-server.log:2019.05.07 15:23:28.516718 [ 214 ] {} <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516725 [ 214 ] {} <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x65b6b5d]
./clickhouse-server.log:2019.05.07 15:23:28.516733 [ 214 ] {} <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516740 [ 214 ] {} <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::LimitBlockInputStream::readImpl()+0x384) [0x5f68f84]
./clickhouse-server.log:2019.05.07 15:23:28.516748 [ 214 ] {} <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516755 [ 214 ] {} <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::ConvertingBlockInputStream::readImpl()+0x3d) [0x65ad0dd]
./clickhouse-server.log:2019.05.07 15:23:28.516763 [ 214 ] {} <Error> BaseDaemon: 11. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]

./clickhouse-server.log:2019.05.07 15:23:28.516770 [ 214 ] {} <Error> BaseDaemon: 12. /usr/bin/clickhouse-server(DB::FilterBlockInputStream::readImpl()+0xaa) [0x65c25aa]
./clickhouse-server.log:2019.05.07 15:23:28.516778 [ 214 ] {} <Error> BaseDaemon: 13. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516785 [ 214 ] {} <Error> BaseDaemon: 14. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x65b6b5d]
./clickhouse-server.log:2019.05.07 15:23:28.516797 [ 214 ] {} <Error> BaseDaemon: 15. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516804 [ 214 ] {} <Error> BaseDaemon: 16. /usr/bin/clickhouse-server(DB::DistinctBlockInputStream::readImpl()+0x91) [0x65df041]
./clickhouse-server.log:2019.05.07 15:23:28.516812 [ 214 ] {} <Error> BaseDaemon: 17. /usr/bin/clickhouse-server(DB::IBlockInputStream::read()+0x258) [0x5f66b08]
./clickhouse-server.log:2019.05.07 15:23:28.516822 [ 214 ] {} <Error> BaseDaemon: 18. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::loop(unsigned long)+0xfb) [0x604bc5b]
./clickhouse-server.log:2019.05.07 15:23:28.516832 [ 214 ] {} <Error> BaseDaemon: 19. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::thread(std::shared_ptr<DB::ThreadGroupStatus>, unsigned long)+0x1f4) [0x604c2f4]
./clickhouse-server.log:2019.05.07 15:23:28.516851 [ 214 ] {} <Error> BaseDaemon: 20. /usr/bin/clickhouse-server(ThreadFromGlobalPool::ThreadFromGlobalPool<DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::process()::{lambda()#1}>(DB::ParallelInputsProcessor<DB::UnionBlockInputStream::Handler>::process()::{lambda()#1}&&)::{lambda()#1}::operator()() const+0x67) [0x604cbc7]
./clickhouse-server.log:2019.05.07 15:23:28.516861 [ 214 ] {} <Error> BaseDaemon: 21. /usr/bin/clickhouse-server(ThreadPoolImpl<std::thread>::worker(std::_List_iterator<std::thread>)+0x1cc) [0x6b8b2ac]
./clickhouse-server.log:2019.05.07 15:23:28.516869 [ 214 ] {} <Error> BaseDaemon: 22. /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xbd57f) [0x7f2fcda0557f]
./clickhouse-server.log:2019.05.07 15:23:28.516876 [ 214 ] {} <Error> BaseDaemon: 23. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f2fce0e76ba]

похоже тоже самое что и https://github.com/yandex/ClickHouse/issues/5141

фикса пока нет

Добрового времени. Подскажите как можно обойти ошибку при insert большого кол-ва данных из mysql

запрос выглядит подобным образом
INSERT INTO clickhouse_table (...) SELECT ... FROM mysql(?, 'db_name', 'mysql_table', ?, ?) mt
данный запрос работал до определённого момента

после стал падать с ошибкой
HttpCode:500 ; ;Poco::Exception. Code: 1000, e.code() = 2013, e.displayText() = mysqlxx::Exception: Lost connection to MySQL server during query (remote-host.ru:3306) (version 19.5.3.8 (official build))

таймаутов в мускуле может не хватает?

падение воспроизводится на определенных запросах?

непонятно что это вообще,
возможно вот это тоже самое https://github.com/yandex/ClickHouse/issues/5197
и оно уже пофикшено в v19.7.1.403-testing, можно попробовать, я ее тестил в стейдже, никаких проблем не нашел

mysql забанил ip кликхауза? https://dev.mysql.com/doc/refman/5.5/en/flush.html#flush-hosts

Алексей докладывает : кликхауз не тормозит

Видео будет опубликовано.

Ура!

Привет. А какой content-type надо передавать в Header'е в http интерфесе кликхауса? Или это вообще не нужно?

application/x-www-form-urlencoded; charset=UTF-8

а если из js то ещо в query string add_http_cors_header=1

Продолжает митап Александр из Altinity

Надо выжимки в пару строк)

Всем доброе утро

Извиняюсь за групый вопрос, если так и есть

в clickhouse есть тригеры?

Что-то не смог найти упоминания в документации

Вроде Material View этим заведуют. Правда не совсем полноценно, но всеж таки.

Про них тоже конечно не густо в документации написано

Но спасибо, буду копать

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

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

Докладов с highload очень много с юз кейсами (от Altinity, Badoo и других классных ребят), в ютубе можно найти. Я бы начал с этого.
У Altinity есть хороший блог:
https://www.altinity.com/blog

Из интересных статей, которые я помню:
https://dou.ua/lenta/articles/experience-with-clickhouse/
Но их очень много, гуглятся по ‘опыт перехода на clickhouse’

Ну и еще этот чат) Мне кажется, что тут любую типовую задачу уже можно найти, тут уже столько наспрашивали и наотвечали. Так что в любой непонятной ситуации я сначала пользуюсь поиском в этом чатике 🙂

Шикарно! Спасибо

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

начинаю собирать. сейчас накатим фикс наш (функцич geoToH3) протестирую, отпишусь

А почему в ключах (ORDER BY, PARTITION BY) нельзя использовать алиасы? С чем связано это ограничение?

Вопрос по Mysql Engine.
В документации написано:
The MySQL engine does not support the Nullable data type, so when reading data from MySQL tables, NULL is converted to default values for the specified column type (usually 0 or an empty string).

Существует ли известный обход этого правила? Допустим, чтобы брались дефолтные значения не ТИПА, а дефолтное значение из MYSQL?

В релизе 19.3.3
https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#clickhouse-release-1933-2019-02-13
"Добавлена поддержка Nullable типов в табличной функции mysql"
Насколько хорошо работает - не скажу, пробуйте

Спасибо

Коллеги, добрый день, подскажите пожалуйста нюанс по воронкам windowFunnel

Есть запрос на 9 этапов воронки

SELECT level, COUNT() AS Count
FROM (SELECT UserId, windowFunnel(86400)
(EventDateTime,
EventId = 'BSE' AND Param1 = '0045fc6b-95db-4be1-b728-b387b6ed34cd',
EventId = 'BCE' AND Param1 = '0045fc6b-95db-4be1-b728-b387b6ed34cd',
EventId = 'CTO', EventId = 'GCO' OR EventId = 'GCOP', EventId = 'ATB',
EventId = 'BK1', EventId = 'BKD', EventId = 'BKP', EventId = 'ORC') AS level
FROM statdb.events
WHERE EventDate = '2019-05-07'
AND ApplicationType = 1
AND EventId in ('BSE', 'BCE', 'CTO', 'GCO', 'GCOP', 'ATB', 'BK1', 'BKD', 'BKP', 'ORC')
GROUP BY UserId)
GROUP BY level

воронка говорит что событий 'BSE' 250 тысяч

если делать отдельный запрос на данный этап (а он первый в воронке)

SELECT EventId, count()
FROM statdb.events
WHERE EventDate = '2019-05-07'
And EventId = 'BSE'
AND ApplicationType = 1
AND Param1 = '0045fc6b-95db-4be1-b728-b387b6ed34cd'
GROUP BY EventId

то получается 1 млн, событий,
если делать запрос через count(distinct(UserId))
то выходит 250 тысяч,

windowFunnel только уникальных юзеров считает получается?
есть возможность считать от всех юзеров?

Всем привет! Столкнулись с интересной ошибкой. В таблице есть колонка ratedAt, я делаю вот такой запрос:

SELECT rate, `courseId` FROM `cursometr`.`rate_history_distributed` PREWHERE `courseId` IN 93 WHERE `rate` > 0 AND `isCourse` = 1 ORDER BY `ratedAt` DESC, `rate` DESC LIMIT 1 BY `learnerId`

И вижу ошибку Not found column ratedAt in block. There are only columns: courseId, learnerId, rate.. Хотя если явно добавить эту колонку в select, то все ок. Версия: 19.5.3.8

Это как-то лечится настройками? В чейджлоге не нашел пока ничего.

Причем если убрать LIMIT 1 BY learnerId, то все ок работает.

Работает. Только нужно изменить тип поля: Int64 —> Nullable(Int64)

Есть данные в таблице
┌───────────────────t─┬──────doldids_object─┬──────lin─┬──────lout─┐
│ 2019-05-07 18:29:20 │ 8943830673763257145 │ 11207831 │ 218605070 │
│ 2019-05-07 18:29:38 │ 2071505660187816938 │ 17172263 │ 227922573 │
│ 2019-05-07 18:34:20 │ 8943830673763257145 │ 12023280 │ 245116349 │
│ 2019-05-07 18:34:39 │ 2071505660187816938 │ 14227229 │ 227032367 │
│ 2019-05-07 18:39:20 │ 8943830673763257145 │ 14895851 │ 281474903 │
│ 2019-05-07 18:39:37 │ 2071505660187816938 │ 16141559 │ 272949789 │
Подскажите пожалуйста как суммировать пойты по 10 минут?

select (toMinute(d) % 10) * 10 as t1 ... group by t1

не?

Плиз, подскажите, как этим бороться?

Code: 102. Unexpected packet from server clickhouse-cl:9000 (expected Hello or Exception, got Unknown packet)

server version 19.5.3 revision 54417

SELECT t-t%600 AS t10, doldids_object, SUM(lin), SUM(lout) GROUP BY t10, doldids_object

Оно
Спасибо!

Ммм
Сработало, только графана не может работать с такими данными, потому как колонка t меняется

графана замечательно отображает данные, возвращаемые как графит-метрики

Графана отлично работает, проблема с точками

Ну так возвращайте ей t, обернув запрос в ещё один select, если внутри запроса не получается выдать нужное

эм…

Есть кстати toStartOfTenMinutes toStartOfInterval

графана хочет время в формате unixtime*1000

Всегда? Иногда? Для определнного запроса? Раньше работало? Докер?

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

будет что-то вроде:
SELECT toUInt32(toStartOfTenMinutes(datetime)) * 1000 as t, sum(data) as dsum FROM $table WHERE ... GROUP BY t

┌───────────────────t─┬──────doldids_object─┬──────lin─┬──────lout─┐
│ 2019-05-07 18:29:20 │ 8943830673763257145 │ 11207831 │ 218605070 │
│ 2019-05-07 18:29:38 │ 2071505660187816938 │ 17172263 │ 227922573 │
│ 2019-05-07 18:34:20 │ 8943830673763257145 │ 12023280 │ 245116349 │
│ 2019-05-07 18:34:39 │ 2071505660187816938 │ 14227229 │ 227032367 │
│ 2019-05-07 18:39:20 │ 8943830673763257145 │ 14895851 │ 281474903 │
│ 2019-05-07 18:39:37 │ 2071505660187816938 │ 16141559 │ 272949789 │
dev1 8943830673763257145
dev2 2071505660187816938

@den_crane - спасибо. Добавили новый апп клиент и взяли некорректный haproxy конфиг. В нем не было. mode tcp

backend clickhouse-cl
mode tcp
...

Ошибка пропала.

А в чём, собственно, проблема? Требуется агрегировать без учёта устройства или что?

да

И в чём именно тут проблема?

Хотя... Тип данных там какой?

uint

Не в этом смысле. Нарастающий итог или просто значение с датчика?

И что именно требуется сагрегировать?

lin и lout

разница между точками 30 сек

если аггрегировать по 10 минут, думаю должно нормально получится

сбор со всех устройств каждые 5 минут

Переформулирую вопрос: результат агрегации - это что?

это сумма значений lin(lout)

Просто сумма, без учёта предыдущих периодов?

Требуется только для графаны?

да

Сейчас покажу аналог

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

Всем привет. Подскажите, пожалуйста… Если на одном хосте из 30 стабильно по таймауту валятся все DDL операции ON CLUSTER, но при локальном выполнении (без ON CLUSTER) всё проходит нормально, как это лечить?

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

см. запрос в графане и опции запроса типа "Step"

У меня на примере - значения берутся на интервале 5 минут.

а зачем деление?

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

тебе не требуется

концепт понятн
спасибо
step как-то искажает данные

он влияет на t и только на t

Задаёт шаг. Рекомендую ещё поиграться с Round, кстати. Чтоб начало шага было детерминированным

Кстати, так выглядит графики с двух устройств. Все красиво

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

День добрый. Подскажите бест практис по именованию колонок и таблиц? Камелкейс или снейккейс? Или такогового не имеется?

как угодно, лишь бы везде одинаково.

Спасибо

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

у меня 18.16.1

К тому же только на 1 хосте

В chproxy? В кх нет кеширования результата

т.е надо системно менять найстроки кликхауса?

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

Если хотете почитать мимо кэша ОС

SET min_bytes_to_use_direct_io=1, merge_tree_uniform_read_distribution=0

о

пасиба!

system drop mark cache;
sync; echo 2 > /proc/sys/vm/drop_caches

А DDLWorker вообще хоть что-нибудь пишет в лог на том хосте?
Типа <Debug> DDLWorker: Cleaning queue

есть специалисты по hyperscan? интересует группировка похожих строк в ch. Все что накопал в доках CH это
https://clickhouse.yandex/docs/ru/query_language/functions/string_search_functions/#ngramdistance-haystack-needle

Кирилл, а подскажите при использовании TO одинаковые данные хранятся и во вьюхе и в таблице? То есть дублируются? И при создании матвьюхи функции агрегирования нужно использовать без state?

при to вьюха тупо хранит данные в таблице указанной в to вместо неявной .inner таблицы

detach table MV;
alter table `.inner.MV` add column NEWCOL String;

ATTACH MATERIALIZED VIEW MV
....
as select , NEWCOL ....

А почему тогда нужно агрегировать по count , а не countState.

?????

а есть какой-нибудь оператор для пустого условия Where ?
что-то вроде
where Date = today() and (1 = 1)
мб есть что-нибудь получше? а то 1=1 выглядит костыльно

where 1

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

У меня выдало ошибку когда я пытался занести данные в матвью, которая была создана как select col1, countState(). Как я понимаю из за того что колонка в таблице типа UInt64 не соответствует countState, или в таблице нужно использовать другой тип?

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

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

2019.05.08 14:45:03.418293 [ 1276114 ] {3a071405-b760-4431-9a20-1601b337f1a0} <Error> executeQuery: Code: 159, e.displayText()
= DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000018900 is executing longer than distributed_ddl_task_timeou
t (=180) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in backgro
und, e.what() = DB::Exception (from ….) (in query: DROP TABLE IF EXISTS me_dump.user_d1 ON CLUSTER 'product_ana
lytics'), Stack trace:

0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x9c778f6]
1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > c
onst&, int)+0x22) [0x32b6342]
2. clickhouse-server(DB::DDLQueryStatusInputSream::readImpl()+0x132c) [0x6e8048c]
3. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x6d6ac6a]
4. clickhouse-server(DB::AsynchronousBlockInputStream::calculate()+0x56) [0x6d5fe96]
5. clickhouse-server() [0x6d60300]
6. clickhouse-server(ThreadPool::worker()+0x19e) [0x9f3779e]
7. clickhouse-server() [0xa94e40f]
8. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f9d48f60494]
9. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f9d48592acf]

примеры

https://gist.github.com/den-crane/bc5256cb3f64ed3789819d40c11bda84
https://gist.github.com/den-crane/048ce66bc59f5577d56e42d76934682e
https://gist.github.com/den-crane/d03524eadbbce0bafa528101afa8f794
https://gist.github.com/den-crane/49ce2ae3a688651b9c2dd85ee592cb15
https://gist.github.com/den-crane/f7382cd4f1f859ff6ac46afe7dc9925a
https://gist.github.com/den-crane/a72614fbe6d23eb9c2f1bce40c66893f

В том и вопрос куда туда? С каким типом создавать колонку?

ну, матвью пушит данные в таблицу
о структуре этой таблицы речь и идёт. Создавайте с целочисленным типом.
И примеры от @den_crane обычно отвечают на множество вопросов, которые ещё могут возникнуть по ходу. Посмотрите.

Понял

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

Я в processlist смотрел в момент выполнения (висения) - там была пустота.

Значит я опять не понимаю где нужно использовать count, а где countState?

А DDLWorker вообще хоть что-нибудь пишет в лог на том хосте?
Типа <Debug> DDLWorker: Cleaning queue
за последние 7 дней?

Если таблица aggregating to countState (тип поля AggregateFunction(count))

Спасибо, а что плохого если таблица agregating, а я создал поле Uint64 и матвьюху с count?

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

Фигово, придется переделывать ((

/var/log/clickhouse-server/clickhouse-server.log.5.gz:DDLQueryStatusInputSream
/var/log/clickhouse-server/clickhouse-server.log.5.gz:2019.05.08 14:45:03.418293 [ 1276114 ] {3a071405-b760-4431-9a20-1601b337f1a0} <Error> executeQuery: Code: 159, e.displayText() = DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000018900 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in background, e.what() = DB::Exception (from 10.156.2.232:54534) (in query: DROP TABLE IF EXISTS me_dump.user_d1 ON CLUSTER 'product_analytics'), Stack trace:
/var/log/clickhouse-server/clickhouse-server.log.5.gz:2. clickhouse-server(DB::DDLQueryStatusInputSream::readImpl()+0x132c) [0x6e8048c]
/var/log/clickhouse-server/clickhouse-server.log.6.gz:DDLQueryStatusInputSream
/var/log/clickhouse-server/clickhouse-server.log.6.gz:DDLQueryStatusInputSream
/var/log/clickhouse-server/clickhouse-server.log.6.gz:2. clickhouse-server(DB::DDLQueryStatusInputSream::readImpl()+0xb5b) [0x6e7fcbb]
/var/log/clickhouse-server/clickhouse-server.log.6.gz:DDLQueryStatusInputSream

Это всё, что есть

про DDL

похоже там упал DDLWorker. Я бы рестартанул тот хост и посмотрел что будет в логе при загрузке.

ребят, а что за ошибка в логах?
2019.05.08 18:57:07.025857 [ 11 ] {} <Error> rum.delta_lr (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received

или реплика не ответила за таймаут, или баг https://github.com/yandex/ClickHouse/issues/4047#issuecomment-478101442

Рестартанули…
019.05.08 19:14:45.768547 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018871: There is no a local address in host list
2019.05.08 19:14:45.769685 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018872: There is no a local address in host list
2019.05.08 19:14:45.770716 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018873: There is no a local address in host list
2019.05.08 19:14:45.771817 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018874: There is no a local address in host list
2019.05.08 19:14:45.772944 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018875: There is no a local address in host list
2019.05.08 19:14:45.774123 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018876: There is no a local address in host list
2019.05.08 19:14:45.775122 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018877: There is no a local address in host list
2019.05.08 19:14:45.776202 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018878: There is no a local address in host list
2019.05.08 19:14:45.777249 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018879: There is no a local address in host list
2019.05.08 19:14:45.778297 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018880: There is no a local address in host list
2019.05.08 19:14:45.779329 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018881: There is no a local address in host list
2019.05.08 19:14:45.780380 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018882: There is no a local address in host list
2019.05.08 19:14:45.781391 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018883: There is no a local address in host list
2019.05.08 19:14:45.782466 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018884: There is no a local address in host list
2019.05.08 19:14:45.784674 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018885: There is no a local address in host list
2019.05.08 19:14:45.785785 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018886: There is no a local address in host list
2019.05.08 19:14:45.786776 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018887: There is no a local address in host list
2019.05.08 19:14:45.789096 [ 50 ] {f9ffe958-b537-4c8f-9bb0-e898b1f5469d} <Debug> DDLWorker: Will not execute task query-0000018888: There is no a local address in host list

Ну после рестарта ATTACH ON CLUSTER прошёл успешно по крайней мере

адрес сменился у хоста поди ?

не знаю, но теперь рассинхрон с ZK и пропала таблица)) Видимо, DDL отработали, которые могли

подскажите, плиз, когда появится видео запись митапа вчерашнего в Лимассоле?

надо было ехать!

В течение недели

👍

Подскажите пожалуйста про AggregatingMergeTree:
Насколько вероятно получить при выборке некорректные результаты, если Мердж не успел отработать после вставки?

0-вая, мерж вообще не влияет на результат select from AggregatingMergeTree (в смысле без group by делать запросы туда бессмысленно, мерж может вообще не случится уже никогда).

Спасибо!

Запустил alter delete, он закончился, кроме двух партов (system.mutations) parts_to_do = 2 / is_done 0, причем в этих партах удалять нечего.
Но у этих двух партов размер чуть больше 200ГБ (max_bytes_to_merge_at_max_space_in_pool=200) (свободно на диске >ТБ).
Причем таблица в старом формате, поэтому settings туда в sql не подпихнуть (чтобы обойтись без рестарта). Печаль.
И в логах ни слова об этом, фиг догадаешься что почему застряло.

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

Аналогичная проблема может и с TTL случиться

Логичней сделать какую-нибудь настройку чтобы проверялось max_bytes_to_merge_at_max_space_in_pool + {10%} например, потому что при мутации размер не особо увеличивается, да и предсказать насколько увеличится нельзя, может апдейт там шире строки сделает в два раза.

господа, а чем вы мигрируете схему? А то в доке ссылок нет, а в github только одно решение на php, в непонятном состоянии

ну и тупой, как палка golang-migrate/migrate

Подскажите плиз. Хочу из кх запроса достучаться через odbc('DSN=..', 'table') до посгре. Но не могу найти clickhouse-odbc-bridge. Где он лежит?

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

все нашел его. не туда смотрел.
другой вопрос, я создал таблицу в ch ODBC(...) которая ходит в pg. В pg большая таблица. Я делаю
SELEC * FROM big_table_odbc LIMIT 1

Но запрос выполняется оченьь долго. Правильно я понимаю что limit 1 не в pg исполняется?

Привет! А возможно ли, что при записи в ReplacingMergeTree уникальных данных, при очередном селекте попадаются одинаковые строки (при этом вставляли эту строку только 1 раз) ?

без реплик

то есть вставленная 1 раз строка внезапно в select * 2 раза видна

Нет, что записали то и читаем. Если это так, то это как минимум былабы awful error #2. Читаете пишете в обычную не distributed таблицу?

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

Есть простая merge tree таблица на 10 ярдов строчек. Сделал materialized view для неё. Не подскажите, как теперь наполнить (materialized view) ?

Оно наполняется само инсертами.

А через какое время, не подскажите?

Мне нужно, чтобы эти все 10 ярдов наполнились

Дык только новые записи появятся. Мат вью работает как триггер на вставку в классическом sql.

Понятно, спасибо. А старые наверное нужно перезаливать - только так старые вставятся

Другого нет пути?

тупо заинсертить в MV тем же селектом что и в MV

Спасибо

а я не могу делать вставки из ch через odbc?
insert into test_odbc VALUES(100,'odbc')

INSERT INTO test_odbc VALUES

Received exception from server (version 19.8.1):
Code: 86. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received error from remote server /. HTTP status code: 500 Internal Server Error, body: No 'query' in request body

Можешь https://clickhouse.yandex/docs/ru/interfaces/odbc/

Кажется, я столкнулся с таким же, моментально сбрасывает...

нашел вот такое решение https://github.com/Percona-Lab/clickhousedb_fdw попробую

Доброго вечера, подскажите пожалуйста мануал по Distributed tables. Из найденного описано довольно скудно. Создать получается но данные не распространяются по кластеру, только внутри шарда, где были добавлены.

https://tech.marksblogg.com/billion-nyc-taxi-rides-clickhouse-cluster.html

<remote_servers>
<perftest_3shards>
perftest_3shards -- 3 Шарда по одной реплике в каждом

CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());

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

@den_crane спасибо. Попробую.

Всем привет, столкнулись с такой проблемой сегодня, по сети отвалилась нода кликхауса и все запросы по Distributed таблицам упали с сетевой ошибкой no route to host

ClickHouse server version 18.14.15 revision 54409

Code: 209, e.displayText() = DB::NetException: Timeout exceeded while reading from socket (10.2.0.141:9000), e.what() = DB::NetException
Code: 210, e.displayText() = DB::NetException: Net Exception: No route to host: (xxxx:9000, 10.2.0.141), e.what() = DB::NetException

соотвествонно вопросы
1) баг или фича?
2) спасет ли появление реплик от подобного?

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

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

это селекты

ну а какое вы поведение ожидаете для селектов 7

у вас нет половины данных , что по вашему должен отдавать кликхаус 67

ну половина громко сказано )

ну треть

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

запрашивайте напрямую с ноды

там не половина а капля)

а основной вопрос был вторым

если будет аналогичная реплика то будет ли no route to host

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

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

да. шардов много, данных много

это прдположение или задокументированная фича?

это обычное поведение кликхауса

нахрена тогда нужны были бы реплики

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

поэтому вопрос не с потолка

https://t.me/clickhouse_ru/72378

спс, а по второй части про реплику? именно no route to host с ней обработается?

Да

Спс

здравствуйте! подскажите кто-то использовал clickhouse в проекте symfony + doctrine? проблема в том, что при вызове flush вызывается метод beginTransaction, а реализация этого метода в FriendsOfDoctrine/dbal-clickhouse бросает исключение.