loki1984,

Алгоритмы будут зависеть от ситуации (статистики и подходящих проекций). Если измерение небольшое, то все измерение просто зеркалируется по нодам, если большое, то произойдет BROADCAST по частям, если на факте висит сортировка по FK, то вместо обьединения через хэш-таблицы (HASH JOIN) произойдет соединение путем объедения записей упорядоченных значений колонок (MERGE JOIN).

Ситуацию, чтобы Вертика не смогла эффективно распределить между серверами соединение или агрегацию, уведя большой объем работ на инициализирующую ноду и заставив ее все собирать я видел пару раз в жизни и то это были запросы на соединение больших фактовых таблиц и больших измерений с количеством джойнов более полсотни. Но опять же, под такие большие запросы имеет смысл делать реоптимизацию структуры хранения данных. Например, никто не мешает сделать JOIN проекцию на факт+измерения, если этим измерения всегда цепляются INNER JOIN. В таком случае без разницы, как сегментируются измерения и факты, их джойн проекция будет лежать сразу в одном месте по нужным полям измерений с фактами и все это лежат рядом на серверах. Этакая материальная проекция, позволяющая дематериализовать нужные поля измерений в факты без затрат по кодированию и сопровождению. В ситуации с 30 миллионами клиентов конечно смысла возится с такой проекцией нет, но вот если их хотя бы миллионов 100, наверное имеет смысл уже подумать ее сделать.

loki1984,

Гм, а я недостаточно подробно объяснил как ? :)

loki1984ASCRUS,

у нас конкретный пример от Александра: есть 30 МЛН клиентов, есть операции по ним. Среди этих 30 МЛН есть 5 клиентов, чьи операции занимают 20% от всей таблицы. Допустим у нас 100 параллельных процессов обработки, на которых хранятся данные.
Если размазывать данные по клиентам, то на 5 из 100 серверов данных окажется больше в разы. То, что называется skew.

Если таблица с операциями будет распределена по своему ключу, то проблема встанет всё равно, т.к. предположительно все равно в момент join будет распределение по ключу клиента. Как конкретно в вертике решена эта проблема?
Еще раз. Данные фактов не будут размазываться по клиентам. Это контрпродуктивно. Так же, как и по городам, полу и прочему :) Данные фактов будут сегментироваться по уникальному ключу, чаще всего это PK. Но помимо сегментации данные фактов будут на каждом сервере храниться в упорядоченном виде, если в сортировке хранения проекции указать Код Клиента. С учетом того, что Вертика колонориентированный сервер, каждой ноде кластера получить с фактов список ключей клиентов и попросить другие ноды дослать ей по этому списку нужные записи для соединения дело миллисекунд. Не нужно будет даже полную копию измерения собирать со всех нод и рассылать на все ноды. BROADCAST будет минимальным. Если же на сам запрос к фактам еще накладывается общий фильтр по другим полям, это вообще будет замечательно выглядеть - оптимизатор наложит фильтр, очертит круг нужных записей, с них получит на каждой ноде ид клиентов, соберет по спискам с других нод, далее в зависимости от запроса сверху каждая нода проведет дальнейшие действия (сортировка, агрегация, окна, ...).

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

Ivan DurakASCRUSкаждой ноде кластера получить с фактов список ключей клиентов и попросить другие ноды дослать ей по этому списку нужные записи для соединения дело миллисекунд. Не нужно будет даже полную копию измерения собирать со всех нод и рассылать на все ноды. BROADCAST будет минимальным.
Клевая фича. Броадкаст будет не фактов а измерения. Кстати гринплам так не умеет. Он даже и сортировку внутри нод не делает.
Там еще один нюанс - Вертике можно же указать способ хранения для столбцов (encoding). Возвращаясь к тому примеру с 20% 5 клиентов от всей таблицы. В фактовой таблице делаем сортировку по полю account_id и назначаем ему ENCODING RLE. Теперь этот столбец будет хранится как КодКлиента:КоличествоИдущихПодрядЗаписей. При чтении контейнеров для запроса Вертика изначально уже не будет просматривать значения колонки клиента по всем записям таблицы, которые легли в этот блок, там будет ровно столько записей на эту колонку, сколько уникальных значений во всех записях этого контейнера кода клиента там присутствует. То есть моментально, вне зависимости от размера контейнера (они по мере ухода в историчность еще и укрупняются, дефрагментируясь). В этом плане кодирование хранения великая штука. Например у нас есть большой символьный код группы, групп ограниченное число, поиск по нему идет, но сортировка не выгодна по каким то причинам. Делаем ENCODING BLOCK_DICT и Вертика в контейнерах вместо самих кодов хранит значения счетчика, а все коды, используемые в записях хранимого контейнера записывает как словарик в начало контейнера кодируя внутренним счетчиком. Теперь при работе с таким кодом группы достаточно просто считать заголовок контейнера и сразу увидеть все значения, которые присутствуют в этом контейнере по этому полю. Так как записей в одном контейенере на таблицу могут быть миллионы, очень экономичный способ поиска информации без дополнительных на хранение или процессорное время, как это происходит при алгоритмах индексации данных, упорядоченного хранения и т.д. Ну а если учесть, что на каждый хранимый контейнер в заголовок пишется его статистика по полям, то вообще быстрый поиск информации без полного просмотра данных на хороших скоростях шуршит. В Нетизе помнится тоже статистика по блокам хранения данных хранится, но в отличие от Вертики у них блоки фиксированной длины, на больших объемах их много просматривать приходится, у Вертики в этом плане склонность к автоматическому укрупнению хранения данных по мере их устаревания мне кажется правильно сделано.