эти данные нужны только на момент выборки (отправки запроса по API)

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

ничего криминального )

https://clickhouse.yandex/docs/ru/table_engines/external_data.html

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

ага-ага

пошел копать )

благодарю

Ребят, всем привет, есть вопрос. Не знаю, как решить средствами КХ. Есть таблица для ивентов вида: ( ID UInt32 Event String GUID String Path String IP UInt32 UserID UInt32 TrackedDate Date ) GUID — идентификатор юзера в браузере (кука), Event — что произошло (page или image), Path — урл события, UserID — некий параметр для группы. У меня есть задача — получить все ивенты с Path = %success% с Event = page` для которых есть другой Event = image. собственно это решается достаточно легко: SELECT * FROM analytics.EventTrack WHERE (UserID = 92) AND (Event = 'page') and (Path like '%onepage/success%') AND (TrackedDate >= toDate('2017-09-01')) AND GUID IN ( SELECT GUID FROM analytics.EventTrack WHERE (UserID = 92) AND (Event = 'image') AND (TrackedDate >= toDate('2017-09-01')) ) Есть ситуация, когда пользователь сменил браузер, то есть у него может быть два GUID, но одинаковый IP. В реляционной БД я бы сделал алиас для таблицы и в сабквери бы сверял IP и дату (допустим, не больше суток, потому что динамический айпи, все дела). Как сделать в КХ, понятия не имею. Были мысли пробовать собирать IP адреса с датами в Memory таблицу (не работал ранее). Но правильно ли это?

я бы делал внешний словарь, который содержит текущую проклейку пользователей в виде guid-> id связной компоненты склейки, и отдельным процессом лопатил эти же логи на предмет одинаковых ip или еще какая логика вам в голову придет. словарь потом можно использовать двумя способами, 1. при вставке данных забирать в события текущее состояние склейки 2. при чтении забирать последнее наиболее актуальное состояние. дальше, в вашем запросе "все события1 для которых есть событие2" происходит что-то вроде джойна на себя же по (userid, guid) при этом достаточно произвольное условие на дату, т.е. события могут быть в любом порядке. и любом количестве. может так и должно быть. в любом случае, количество guid со временем неограниченно растет, возможны спецэффекты. дальше, если вы будете шардировать хранение, вам желательно организовать данные так, чтобы объединение результатов на шардах происходило как можно позже, например чтобы джойн был локальным на шарде. это значит что данные должны шардироваться так, чтобы история одного человека попадала в одну машину. это вряд ли получится, если например у вас для guid динамическое объединение в одного человека. это не значит что так не надо делать, просто надо понимать последствия. хотя если у вас id события int32, то возможно вам это не нужно. и ip только v4. в целом задача про последовательности событий в реляцинном случае обычно включает в себя джойн большой таблицы на саму себя по ключу с большой кардинальностью, и нормально не работает. но возможно у вас все не так плохо.

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

а за словарь спасибо, я его тоже хочу пощупать

пока шардирования нет. отчет генерируется, все ок )

спасибо за столь развернутый ответ! очень интересное решение, попробую

Коллеги, доброго времени суток. Мне кажется, где-то тут проскакивала информация, что при определенных обстоятельствах в ClickHouse, начинает разрастаться размер ZK snapshort. Можете скинуть ссылку на обсуждение/детали?

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

сегодня ZK навернулся и потянул за собой другие сервисы (кроме CH)

поломали в 1.1.54276 поправили в 1.1.54284 https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md

хм... у меня 1.1.54245 значит не то

снапшет ZK ~2G, кто-то знает, как найти основного "потребителя" места?

снапшет ZK ~2G, кто-то знает, как найти основного "потребителя" места?

du -hcs ./* | sort -h

я не про файловую систему

я про znode

какие ветки в ZK делают в клад в этот снапшет

или эта командя для zkcli?

Ааа, типо внутри ZK, ок понял.

Всем добрый день! Я правильно понимаю, что чтобы сменить тип одной колонки с Int32 на UInt32, например, необходимо создать новую таблицу с измененным типом этой колонки и INSERT'ить в нее данные ?

Всем добрый день! Я правильно понимаю, что чтобы сменить тип одной колонки с Int32 на UInt32, например, необходимо создать новую таблицу с измененным типом этой колонки и INSERT'ить в нее данные ?

есть MODIFY COLUMN: https://clickhouse.yandex/docs/ru/single/#alter

ok, спасибо

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

Конец года - начало 18, вроде в roadmap

есть MODIFY COLUMN: https://clickhouse.yandex/docs/ru/single/#alter

DB::Exception: ALTER of key column column_name must be metadata-only.

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

Подскажите по AggregateState Задача: выгрузить из CH пользователей который - сделали то-то и показывать им что-то. Идея: если взять AggregateState : uniqHLL12State или uniqCombinedState или что-то другое на фильтре Блума, передать это значение в рекламную сеть на Java - тогда если повторить алгоритм hhl12/... на java - можно быстро отвечать входит пользователь в множеcтво или нет ( с погрешностью) Как думаете эта идея будет работать или в каком направлении копать? Может кто то партировал CH алгоритмы вхождение уников на Java ?

А зачем в java это обрабатывать? оО Стейт все равно может жирный получить, либо можно поверх запроса который стейт собирает просто сделать каунт с фильтром по конкретному пользователю

И портируй не портируй стейт куда либ, данных меньше читаться не будет

А просто по хэш таблице проверить в Java вхождение я не вижу смысла ) можно запросов поверх проверить...быстрее будет (в плане не надо будет ничего портировать и пилить костыли)

У нас рекламные сервера на Java - которые знать не знают про CH и что в нем хранится ( т/е они не читают из него данные) работаю с ооочень маленьким набором данных. Есть внешний тулл выполняет запрос в CH - получает +-300М UUID, далее получаем uniqHLL12State - и сохраняет только этот State - т/е пару килобайт и передает их рекл. серверам Идея- Далее когда поступает запрос от uuid1 или uuid2 мы проверяем входит пользователь в этот State или нет Проверить можно через добавление в элемента в hhlState - если cout изменился то да... или нет...

Сейчас используем фильтры Блума - но хочется совместить с CH

Мы пока что думаем, что это хорошая версия. Но что-то не так. В логе две проблемы: 1. Откуда-то появился кусок с неправильными данными. 2. sefgault. По трейсу источник проблемы не удаётся понять. Насколько это воспроизводимо?

Сегодня опять упали с сегфолтом, но тут дело до перемещения партиций вообще не дошло, все что есть в логах 2017.09.07 10:08:17.258574 [ 28 ] <Error> BaseDaemon: ######################################## 2017.09.07 10:08:17.272317 [ 28 ] <Error> BaseDaemon: (from thread 27) Received signal Segmentation fault (11). 2017.09.07 10:08:17.272364 [ 28 ] <Error> BaseDaemon: Address: 0x3f7237783 2017.09.07 10:08:18.965770 [ 28 ] <Error> BaseDaemon: 0. clickhouse-server(DB::ColumnVector<unsigned int>::insertData(char const*, unsigned long)+0x16) [0x15b4a26] 2017.09.07 10:08:18.965913 [ 28 ] <Error> BaseDaemon: 1. clickhouse-server(void DB::Aggregator::convertToBlockImplNotFinal<DB::AggregationMethodConcat<TwoLevelHashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, TwoLevelHashTableGrower<8ul>, Allocator<true> > >, HashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, TwoLevelHashTableGrower<8ul>, Allocator<true> > >(DB::AggregationMethodConcat<TwoLevelHashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, TwoLevelHashTableGrower<8ul>, Allocator<true> > >&, HashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, TwoLevelHashTableGrower<8ul>, Allocator<true> >&, std::vector<DB::IColumn*, std::allocator<DB::IColumn*> >&, std::vector<DB::PODArray<char*, 4096ul, Allocator<false>, 15ul>*, std::allocator<DB::PODArray<char*, 4096ul, Allocator<false>, 15ul>*> >&, std::vector<unsigned long, std::allocator<unsigned long> > const&) const+0x99) [0x3132d29] 2017.09.07 10:08:18.965963 [ 28 ] <Error> BaseDaemon: 2. clickhouse-server(void DB::Aggregator::writeToTemporaryFileImpl<DB::AggregationMethodConcat<TwoLevelHashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, TwoLevelHashTableGrower<8ul>, Allocator<true> > > >(DB::AggregatedDataVariants&, DB::AggregationMethodConcat<TwoLevelHashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, TwoLevelHashTableGrower<8ul>, Allocator<true> > >&, DB::IBlockOutputStream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x965) [0x313f075] 2017.09.07 10:08:18.965994 [ 28 ] <Error> BaseDaemon: 3. clickhouse-server(DB::Aggregator::writeToTemporaryFile(DB::AggregatedDataVariants&)+0x179a) [0x30f4d1a] 2017.09.07 10:08:18.995048 [ 28 ] <Error> BaseDaemon: 4. clickhouse-server(DB::Aggregator::executeOnBlock(DB::Block&, DB::AggregatedDataVariants&, std::vector<DB::IColumn const*, std::allocator<DB::IColumn const*> >&, std::vector<std::vector<DB::IColumn const*, std::allocator<DB::IColumn const*> >, std::allocator<std::vector<DB::IColumn const*, std::allocator<DB::IColumn const*> > > >&, std::vector<unsigned long, std::allocator<unsigned long> >&, std::vector<StringRef, std::allocator<StringRef> >&, bool&)+0x978) [0x30f5898] 2017.09.07 10:08:18.995075 [ 28 ] <Error> BaseDaemon: 5. clickhouse-server(DB::ParallelInputsProcessor<DB::ParallelAggregatingBlockInputStream::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x2c8) [0x305abf8] 2017.09.07 10:08:18.995084 [ 28 ] <Error> BaseDaemon: 6. clickhouse-server() [0x399d05f] 2017.09.07 10:08:18.995113 [ 28 ] <Error> BaseDaemon: 7. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fe36b7676ba]

Что-то у меня жалуется на нехватку места, хотя алоцировать он пытается намного меньше чем лимит: DB::Exception: Memory limit (for query) exceeded: would use 9.41 GiB (attempt to allocate chunk of 134217728 bytes), maximum: 9.31 GiB

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

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

хм, логично

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

Это про CollapsingMergeTree?

Да

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

можно ли из материализованной вьюхи дропнуть партицию?

да, для materialize view создается обычная таблица вида .inner.название вью``

Ребят. Есть Nested колонка например с тремя колонками внутри. Если я делаю например sumArray(nested.column1), то фактически данные с остальных двух колонок будут читаться или нет?

И можно ли как то приджоинить только одну колонку из nested колонки, а не три сразу?

Т.е. делаю я например select nested.column1 from table array join nested. Или остальные колонки и так не читаются из nested?

остальные колонки не читаются и так

Супер, это то, что надо

Спасибо!

не уверен, что array join nested сработает. кажется, должно быть array join nested.column1

Я тут выше про нехватку памяти писал, вот в этом виео годно Алексей рассказывает что да как https://events.yandex.ru/lib/talks/4556/

не уверен, что array join nested сработает. кажется, должно быть array join nested.column1

Оно именно так и работает в данный момент

интересное поведение встретил функции sumif() - если там прописать ограничение, оно не транслируется выше для уменьшения выборки т.е прописав только sumif я имею ошибку по памяти, а если добавляю в where - все ок

во втором случае оптимизатор может пробросить условие из where в prewhere, и прочитается меньше кусков

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

интересное поведение встретил функции sumif() - если там прописать ограничение, оно не транслируется выше для уменьшения выборки т.е прописав только sumif я имею ошибку по памяти, а если добавляю в where - все ок

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

пробую удалить партицию Received exception from server: Code: 248. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Invalid partition format: 20170801_20170821_0_20882_333. Partition should consist of 6 digits: YYYYMM.

alter table site_stat_cache DROP PARTITION '20170801_20170821_0_20882_333';

при этом SELECT concat('alter table site_stat_cache DROP PARTITION ''',name,''';') FROM system.parts WHERE /*active and*/ table = 'site_stat_cache' and min_date>='2017-08-01'; ┌─concat(\'alter table site_stat_cache DROP PARTITION \\\'\', name, \'\\\';\')────────┐ │ alter table site_stat_cache DROP PARTITION \'20170801_20170821_0_20882_333\'; │ │ alter table site_stat_cache DROP PARTITION \'20170821_20170825_20883_93538_1857\'; │

А Nested вообще как под капотом устроено? Просто есть у меня например некоторое количество строк в Nested для каждой строки в основной таблице. И мне по этим Nested строкам нужно будет проводить фильтрации и пр., если смысл вынести уже отфильтрованные данные в соседнюю колонку или особой разницы не будет?

устроено как несколько массивов с общим значением offset. Насчет смысле не уверен.

спасибо. Я уже удалил просто месяц

да, неверно написал. alter table drop partition '201708' тогда

превед

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

да

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

Привет. Есть три варианта: 1. С помощью INSERT ... SELECT ... FROM remote(...) Просто, неэффективно. 2. Если у таблиц совпадает структура - перенести разные партиции на новые серверы. Для ReplicatedMergeTree см. ALTER ... FETCH PARTITION, для обычного MergeTree перенести файлы. Более сложно, эффективно. 3. Если старые серверы будут присутствовать в кластере в виде шардов, то данные с них можно никуда не переносить. Новые данные писать на другие шарды. Очень просто, быстро, недостаток - неравномерность нагрузки на кластере.

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

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

Ох ) Жестко ) Я такой объем запросов размазываю на кластер ) Для КХ многовато будет 200-300 запросов на один сервер

Добрый день. Нужна помощь) Пытаюсь создать времменую таблицу через jdbc драйвер соеденение. Выкидывается exception Code: 113, e.displayText() = DB::Exception: There is no session, e.what() = DB::Exception. Вообще jdbc драйвер поддерживает сессии?

как-то странно, мускул справлялся с такой ситуацией вообще легко

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

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

Все еще зависит от данных и самих запросов. Мы например агрегируем некоторые данные по данным из КХ. Агрегаторов от 5 до 10 штук. Они делают асинхронные запросы с concurrency 5 и таких процессов висит 25 штук. Но запросы у нас крайне простые. Отдать например значения трех колонок для конкретного пользователя.

С такой нагрузкой КХ вполне себе справляется и не было случаев когда запросы убивали сервер. Все запросы валятся в один сервер, но данные размазаны по кластеру.

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

а какого типа данные в базе ?

параметры сессии, страница входа, реферер, ip, временные параметры

и нужно в ближайшем риалтайме их отдавать ?

параметры сессии, страница входа, реферер, ip, временные параметры

^