Ещё много Nullable

Если я правильно помню, это - инкрементальный номер операции freeze. То есть, делаете freeze два раза - будут две директории. Также есть возможность написать FREEZE PARTITION ... WITH NAME 'name' - явно указать имя директории для бэкапа.

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

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

Могут быть в разных таблицах.

Нет

У меня явно одна таблица

Это наверное баг, из-за рестора дампом

Рестор дампом к такому не может привести

Ну тогда я теряюсь в догадках

Добрый день, подскажите, есть более короткая запись такого WHERE arrayExists(t -> t IN (external', 'internal', 'timeout'), tags)

есть массив Array(String) нужно проверить что в нём есть хотя бы одина из строк

всем привет )

Ку

Добрый день, подскажите, есть более короткая запись такого WHERE arrayExists(t -> t IN (external', 'internal', 'timeout'), tags)

Вроде нет более хорошей. Есть функция arrayIntersect, но я думаю - будет работать хуже.

ок, видимо до какой-то версии работала конструкция WHERE tags IN (....)

по типу как я написал, но в 18.4 перестала

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%BE-%D0%BD%D0%B5%D1%81%D0%BE%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%B8%D0%BC%D1%8B%D0%B5-%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F-4

да, спасибо, мы долго сидели на 1.1.54343

Можно ли переименовывать табличку в CH?

Можно ли переименовывать табличку в CH?

я это делал просто переименовав ее на диске. но это очень «так себе» решение

https://clickhouse.yandex/docs/ru/query_language/misc/#rename нет?

если таблица Replicated, то path в ZK остаётся прежним

Я слышал, что недавно ввели в КХ update и delete. Так вот: извините за глупый вопрос, но как сделать update на полях фиксированной длины. Например, у каждой третьей строки сменить булево значение в одном из столбцов на противоположное?

В русской документации пока нету.

И еще такой вопрос: как в этом случае будет использоваться память? Не будет ли лишнего копирования (казалось бы, не должно быть)?

апдейтов нет, и апдейт и делит работают и будут работать через перезапись в новое место ( merge )

и кстати что такое каждая третья строка? такого понятия вообще нет в КХ.

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

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

update можно реализовать через ReplacingMergeTree и запросы, которые учитывают что нужно отбирать последнюю ревизию записи. delete делается через копирование таблицы, это больше когда нужно как инструмент администратора

update можно реализовать через ReplacingMergeTree и запросы, которые учитывают что нужно отбирать последнюю ревизию записи. delete делается через копирование таблицы, это больше когда нужно как инструмент администратора

можно краткий пример?

https://clickhouse.yandex/docs/ru/query_language/alter/#_4 насколько я понимаю, дизайн подразумевает что data файлы вообще никогда не меняются, иначе это ломает все, тот же freeze партиций через хардлинки.

можно краткий пример?

CREATE TABLE IF EXISTS groups ( date_time DateTime, name String, logins Array(String) ) ENGINE = ReplacingMergeTree(date_time) ORDER BY (name);

и после нужно отбирать там где argMax(logins, date_time)

SELECT argMax(logins, date_time) AS logins WHERE name = 'pepe';

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

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

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

это ж другой движок

а кафка всегда заливает новые записи? или то же должна обновлять существующие?

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

Ничего подозрительного.

Точно что-то с Nullable, вот таких много нашёл 2018.08.27 20:54:33.087439 [ 8 ] <Error> void DB::BackgroundProcessingPool::threadFunction(): Code: 366, e.displayText() = DB::Exception: Logical err or: Sizes of nested column and null map of Nullable column are not equal, e.what() = DB::Exception, Stack trace: 0. /usr/lib64/libclickhouse.so.18(StackTrace::StackTrace()+0x25) [0x7fa06618d635] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x39) [0x22db659] 2. /usr/lib64/libclickhouse.so.18(DB::ColumnNullable::checkConsistency() const+0x91) [0x7fa065e006e1] 3. /usr/lib64/libclickhouse.so.18(DB::DataTypeNullable::serializeBinaryBulkWithMultipleStreams(DB::IColumn const&, std::function<DB::WriteBuffer* (st d::vector<DB::IDataType::Substream, std::allocator<DB::IDataType::Substream> > const&)>, unsigned long, unsigned long, bool, std::vector<DB::IDataType::Substream, std::allocator<DB::IDataType::Substream> >) const+0x55) [0x7fa065484df5] 4. /usr/lib64/libclickhouse.so.18(DB::IMergedBlockOutputStream::writeData(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::IDataType const&, DB::IColumn const&, std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std: :less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, bool)+0x687) [0x7fa065ff4587] 5. /usr/lib64/libclickhouse.so.18(DB::MergedBlockOutputStream::writeImpl(DB::Block const&, DB::PODArray<unsigned long, 4096ul, Allocator<false>, 15ul > const*)+0x5a6) [0x7fa065ff4e26] 6. /usr/lib64/libclickhouse.so.18(DB::MergeTreeDataMergerMutator::mergePartsToTemporaryPart(DB::MergeTreeDataMergerMutator::FuturePart const&, DB::MergeListEntry&, unsigned long, long, DB::DiskSpaceMonitor::Reservation*, bool)+0x2cf8) [0x7fa065f94f18] 7. /usr/lib64/libclickhouse.so.18(DB::StorageMergeTree::merge(unsigned long, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allo cator<char> > const&, bool, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)+0x461) [0x7fa065eb7081] 8. /usr/lib64/libclickhouse.so.18(DB::StorageMergeTree::backgroundTask()+0x17c) [0x7fa065eb971c] 9. /usr/lib64/libclickhouse.so.18(DB::BackgroundProcessingPool::threadFunction()+0x48d) [0x7fa065f4106d] 10. /usr/lib64/libstdc++.so.6(+0xea6de) [0x7fa063c436de] 11. /lib64/libpthread.so.0(+0x78ea) [0x7fa0633d98ea] 12. /lib64/libc.so.6(clone+0x3f) [0x7fa06310f4df]

а кафка всегда заливает новые записи? или то же должна обновлять существующие?

только заливает и выдает, ничего не меняет

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

тогда то что залила кафка это revision=0, ищешь какие записи нужно обновить, и делаешь INSERT увеличивая revision на единицу

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

тогда то что залила кафка это revision=0, ищешь какие записи нужно обновить, и делаешь INSERT увеличивая revision на единицу

О! спасибо. хорошая идея

SELECT max(revision) AS revision, argMax(field1, revision) AS feild1, argMax(field2, revision) AS feild2, ... WHERE keyField1 = v1 AND keyField2 = v2 AND ...

а потом INSERT с resivion + 1 и обновлёными полями

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

BTW, с Replacing не обязателен version/revision. И он вычисляет последнюю версию сам, с помощью final select ... from tablename final

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

Не используйте КХ. Вся суть КХ очень быстро сканировать весь объем. Сделайте одну таблицу с более менее подходящими партициями и индексом.

То есть иметь несколько одинаковых таблиц - плохая идея?

нет, ну вот у вас 80TБ данных, вы их хотите на 5 умножить?

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

50 млн в день не звучит как-то много. Возможно, вам даже фул скан подойдет :)

И индексы кх тоже ненастоящие, по умолчанию они указывают на 8192 строки, все оптимизировано для фулсканов. И с "индексами" все непросто, если кардинальность первых полей маленькая, КХ может искать и по другим полям из "индекса" https://gist.github.com/den-crane/cbc6f0777d03a00417d70018378d360d

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

нету автоинкремента, откуда вообще идея добавлять автоинкремент в DWH? Накой он там нужен

ладно. Попробую через DateTime. Не гарантирует ничего, но хоть как-то позволит упорядочивать

поиска ? ?

ну илипоиск по дате - да

дату можно, типа DateTime DEFAULT now(). упорядочивать в смысле order by, лучше по самим данным, выше будет компрессия если похожие строки упадут рядом в колонку.

хорошо

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

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

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

именно по этому из них всегда нужно выбирать с доаггрегацией

подскажите как удалить path из zookeeper? удалил таблицы с реплик, а в zookeeper записи остались и мешают пересоздать

А как вы удаляли так что они остались?

Зайдите через зукиперкли и удалите по-моему команда рм или дел

Там же просто файловая система по сути

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

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

Как можно избавиться от такого? 2018.08.28 06:14:51.068603 [ 8 ] <Debug> shard_2.foo (ReplicatedMergeTreeQueue): Not executing log entry for part 20180801_20180824_812489_814335_968 because another log entry for the same part is being processed. This shouldn't happen often. 2018.08.28 06:14:51.068630 [ 8 ] <Debug> shard_2.foo (ReplicatedMergeTreeQueue): Not merging into part 20180801_20180824_812489_814374_983 because part 20180801_20180824_812489_814370_982 is not ready yet (log entry for that part is being processed). записи вообще приостановлены уже минут 10 как, все равно ничего не меняется, полный лог таких сообщений и продолжается

при этом еще проскакивают 2018.08.28 06:20:27.783612 [ 9159 ] <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from other-node:55212), Stack trace: но записи сейчас точно остановлены

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

если я правильно понимаю Too many parts, то достаточно просто подождать, пока рассосётся. И там действительно дохрена частей, скорее всего.

А так - пишите не по одной строке на инсерт, а сразу миллиончик

понял, подожду, спасибо.

пишу по 65к или раз в 5 секунд

поэтому и непонятно, что случилось

у нас неравномерная нагрузка, поэтому бывает, что 65к зайдет за секунду, а бывает, что за 5 секунд и 100 не наберется

Тогда странно. В диск не упирается? Зукипер отдельно?

подскажите как удалить path из zookeeper? удалил таблицы с реплик, а в zookeeper записи остались и мешают пересоздать

Вот тут /clickhouse/tables/{your_path}/replicas данные по репликам