Alexander Ryndin,

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

Alexander Ryndin,

Поясни, что ты имеешь ввиду. Сегментация в Вертике работает без проблем, балансировка данных достаточно грамотная, я даже не знал, что там могут быть какие то проблемы. Сегментация Вертикой делается автоматически по полям PK, если явно не указана. При явном указании можно зеркалировать данные для всех нод (что удобно для небольших измерений), для мастер-детайл например указать сегментацию для мастера по PK, для детайла по FK, обеспечив таким образом их соединение JOIN без BROADCAST и т.д. Здесь вообще проблем не возникает, даже если в мастер-детайл лежат десятки миллиардов записей.

Alexander RyndinОчень простой и довольно распространенный кейс: есть табличка-измерение - 30 млн. клиентов, а также табличка фактов с операциями этих клиентов (для простоты пускай это будут звонки/смс). Допустим 20% звонков/смс сделаны с 2-10 служебных номеров (Яндекс-такси, Сбербанковский информатор и т.д.). Как тогда будешь пилить данные между узлами?
Никак не буду. Клиентам скажу сегментироваться и сортироваться по PK, а звонкам сегментироваться по своему PK, а сортироваться по FK ключ клиента + другие поля, значимые при фильтрах запросов. Дальше оптимизатор Вертики сам все сделает правильно (фильтры+MERGE JOIN+частичный BROADCAST) Как измерение и факт в сегментации связаны и какие здесь проблемы? :) Руками в Вертике такие вещи не делаются, это забота оптимизатора.

В общем Саш, ты о чем то таком ручном говоришь не понятном, чего в Вертике просто нет.

Alexander RyndinА сейчас говоришь про сегментацию и мастера, и детайла по PK.
Клиенты и звонки это никак не мастер-детайл :) Это измерение-факт со связью. Вот CDR+CDR List Of Traffic это как раз мастер-детайл. И там на один сдр где то от 1 до 10 записей детальки, которые имеет смысл уложить рядом с самой записью СДР.

P.S. Ну ты сравнил файловую помойку Hadoop и Vertica. У них же вообще абсолютно разные принципы хранения данных, зеркалирования и прочее. Они даже близко не похожи. Поэтому поведение Хадупа на Вертику генерировать не корректно. Так же как и например поведение Нетизы, которая по принципам хотя и ближе к Вертике, но так же отличий столько, что поведение совершенно разное (я уж молчу про ГринПлам).

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 и Вертика в контейнерах вместо самих кодов хранит значения счетчика, а все коды, используемые в записях хранимого контейнера записывает как словарик в начало контейнера кодируя внутренним счетчиком. Теперь при работе с таким кодом группы достаточно просто считать заголовок контейнера и сразу увидеть все значения, которые присутствуют в этом контейнере по этому полю. Так как записей в одном контейенере на таблицу могут быть миллионы, очень экономичный способ поиска информации без дополнительных на хранение или процессорное время, как это происходит при алгоритмах индексации данных, упорядоченного хранения и т.д. Ну а если учесть, что на каждый хранимый контейнер в заголовок пишется его статистика по полям, то вообще быстрый поиск информации без полного просмотра данных на хороших скоростях шуршит. В Нетизе помнится тоже статистика по блокам хранения данных хранится, но в отличие от Вертики у них блоки фиксированной длины, на больших объемах их много просматривать приходится, у Вертики в этом плане склонность к автоматическому укрупнению хранения данных по мере их устаревания мне кажется правильно сделано.