Скорость и оптимизация JOIN 1 к 1 и Materialized view

[Mikhail Petrov]

Есть две таблицы с общим ключем (формата uid, значения случайны). Фактически - половина данных о событии находится в одной таблице, половина - в другой. Таблицы - большие, на сотни гигабайт. Общий столбец в primary key не включен.

Пробовал сделать JOIN - получил крайне медленную работу и падение из-за недостатка памяти.

1. Правильно ли я понимаю, что если JOIN таблицы аналогичен JOIN'у subquery, то единственный способ сделать его с учетом доступной памяти - это делать последовательно много запросов, используя subquery и ограничивая объем subquery, например, по uid % 10 = X - получая по 1/10 части данных каждый раз?

2. Имеет ли значение отсутствие uid в primary key? Ускорит ли JOIN добавление его в ключ? Будет ли при этом иметь значение порядок столбцов в ключе? Сейчас он не в ключе, потому что для нормальных запросов значения вообще не имеет, и сортировать по нему совсем бессмысленно - это просто случайная уникальная (с достаточной вероятностью :) ) строка.

И пара вопросов по MATERIALIZED VIEW

1. Я правильно понимаю, что из VIEW данные уже не удалятся - при удалении исходной таблицы, или ее переименовании, или при detach partition? 

2. VIEW привязан к талицам именно по названию? Что произойдет, если пересоздать исходную таблицу?

3. Можно ли использовать UNION в исходных запросах для VIEW? Иными словами, можно ли "смерджить" две таблицы через VIEW?

4. Можно ли сделать MATERIALIZED_VIEW над MATERIALIZED_VIEW? А если сделать VIEW типа AggretagingMergeTree над VIEW типа AggretagingMergeTree? Я столкнулся с какими-то странными ошибками, не могу понять, это моя неопытность или слишком сложная конфигурация.

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

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

[Yegor Andreenko]

Вам стоит почитать это https://groups.google.com/forum/#!searchin/clickhouse/primary$20key%7Csort:relevance/clickhouse/eUrsP30VtSU/903Smz8pAgAJ

[madm1ke]

Во! Я помнил, что где-то видел более подробное описание, спасибо! :)

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

2016-11-13 13:46 GMT+03:00 Yegor Andreenko <f1y...@gmail.com>:

Вам стоит почитать это https://groups.google.com/forum/#!searchin/clickhouse/primary$20key%7Csort:relevance/clickhouse/eUrsP30VtSU/903Smz8pAgAJ

--
You received this message because you are subscribed to the Google Groups "ClickHouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/d48d3f87-8c54-48fe-ba58-91d071155b2a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[man...@gmail.com]

Про JOIN.

Первичный ключ никак не используется для JOIN.
Поддерживается только hash join (путём размещения данных "справа" в хэш-таблице в оперативке), но не merge join.


Про MATERIALIZED VIEW.

Да, данные из MATERIALIZED VIEW не удаляются автоматически.

> VIEW привязан к талицам именно по названию? Что произойдет, если пересоздать исходную таблицу?

Да, привязан по названию. Насколько я представляю, если пересоздать исходную таблицу, то она останется привязанной к view, но этот случай не тестировался.

> Можно ли использовать UNION в исходных запросах для VIEW? Иными словами, можно ли "смерджить" две таблицы через VIEW?

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

> Можно ли сделать MATERIALIZED_VIEW над MATERIALIZED_VIEW? А если сделать VIEW типа AggretagingMergeTree над VIEW типа AggretagingMergeTree?

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

В целом, MATERIALIZED VIEW работают как триггеры на INSERT. Было бы намного лучше оформить эту функциональность в виде триггеров, так как это было бы более ясно.

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

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

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

[madm1ke]

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

16 ноября 2016 г., 4:56 пользователь <man...@gmail.com> написал:

--

You received this message because you are subscribed to the Google Groups "ClickHouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/b5d5e48a-9ce0-4ed9-94f0-4029eebb3af9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[madm1ke]

Проверил - VIEW типа AggretagingMergeTree над VIEW типа AggretagingMergeTree - работает, но только через subquery, чтобы избавиться от пересечения -Merge и -State - чисто сложности синтаксиса.

16 ноября 2016 г., 10:56 пользователь madm1ke <madmi...@gmail.com> написал:

--

Mikhail U. Petrov.