Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Украина - вперёд с Vertica!  [new]
loki1984
Member

Откуда:
Сообщений: 345
ASCRUS
Alexander Ryndin
А сейчас говоришь про сегментацию и мастера, и детайла по PK.


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

BTW интересно, есть ли у хваленой вертики что-то подобное:
https://www.google.com/patents/US20110093499
или http://www.teradata.com/web-seminars/PayPal-Dealing-with-Natural-Data-Skew/
23 апр 14, 19:39    [15925022]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
loki1984,

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

Ситуацию, чтобы Вертика не смогла эффективно распределить между серверами соединение или агрегацию, уведя большой объем работ на инициализирующую ноду и заставив ее все собирать я видел пару раз в жизни и то это были запросы на соединение больших фактовых таблиц и больших измерений с количеством джойнов более полсотни. Но опять же, под такие большие запросы имеет смысл делать реоптимизацию структуры хранения данных. Например, никто не мешает сделать JOIN проекцию на факт+измерения, если этим измерения всегда цепляются INNER JOIN. В таком случае без разницы, как сегментируются измерения и факты, их джойн проекция будет лежать сразу в одном месте по нужным полям измерений с фактами и все это лежат рядом на серверах. Этакая материальная проекция, позволяющая дематериализовать нужные поля измерений в факты без затрат по кодированию и сопровождению. В ситуации с 30 миллионами клиентов конечно смысла возится с такой проекцией нет, но вот если их хотя бы миллионов 100, наверное имеет смысл уже подумать ее сделать.
23 апр 14, 19:40    [15925026]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Vovaka
Member

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


Стандартное решение дня МРР: сегментировать и то и то по своим ключам. Получаем равномерное распределение данных, но проблему джойнов.
В Вертике можно измерению сказать unsegmented all nodes, тогда оно расклонируется по всем нодам, 30 млн записей - фигня, физического места займут немного, лицензий вообще не потратится дополнительных, зато не будет поражняка в сети кластера и производительность вырастет.
Плюс у Вертики всегда есть доп.проекции, которые и сегментируются, и сортируются по другим правилам нежели таблица (суперпроекция).
23 апр 14, 19:47    [15925056]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
loki1984
Member

Откуда:
Сообщений: 345
ASCRUS,

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

Если таблица с операциями будет распределена по своему ключу, то проблема встанет всё равно, т.к. предположительно все равно в момент join будет распределение по ключу клиента. Как конкретно в вертике решена эта проблема?
23 апр 14, 19:50    [15925068]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
loki1984
ASCRUS,

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

Если таблица с операциями будет распределена по своему ключу, то проблема встанет всё равно, т.к. предположительно все равно в момент join будет распределение по ключу клиента. Как конкретно в вертике решена эта проблема?


В предыдущем посте ответ.
23 апр 14, 19:52    [15925074]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
loki1984,

Гм, а я недостаточно подробно объяснил как ? :)
23 апр 14, 19:58    [15925097]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
loki1984
Member

Откуда:
Сообщений: 345
Vovaka
loki1984
ASCRUS,

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

Если таблица с операциями будет распределена по своему ключу, то проблема встанет всё равно, т.к. предположительно все равно в момент join будет распределение по ключу клиента. Как конкретно в вертике решена эта проблема?


В предыдущем посте ответ.

Не увидел в момент написания поста. По сути это то же самое, что гонять по сети эти 30 млн в момент join, только снижается нагрузка на сеть, зато растёт объём хранимых данных в N=кол-во параллельных процессов. В принципе справедливо, чем-то надо жертвовать.

А вообще пример довольно надуманный конечно. Оракл его везде приводит, т.к. только в этом случае может потягаться с MPP. Если кол-во таких клиентов с большим числом операций будет больше чем кол-во единиц параллелизма, то проблема вообще исчезнет.

Или если есть возможность распределить данные по паре ключей, опять же проблемы не будет. Например если у сети магазинов есть гипермаркеты и магазины у дома, остатки можно сегментировать по паре магазин+товар и skew не будет.
23 апр 14, 20:02    [15925114]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
loki1984
Member

Откуда:
Сообщений: 345
ASCRUS, вы нет, vovaka да.
23 апр 14, 20:03    [15925117]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
loki1984,

Я с этим сталкивался просто :) Не из книжек пример.
23 апр 14, 20:06    [15925135]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Vovaka
Alexander Ryndin
Очень простой и довольно распространенный кейс: есть табличка-измерение - 30 млн. клиентов, а также табличка фактов с операциями этих клиентов (для простоты пускай это будут звонки/смс). Допустим 20% звонков/смс сделаны с 2-10 служебных номеров (Яндекс-такси, Сбербанковский информатор и т.д.). Как тогда будешь пилить данные между узлами?


Стандартное решение дня МРР: сегментировать и то и то по своим ключам. Получаем равномерное распределение данных, но проблему джойнов.
В Вертике можно измерению сказать unsegmented all nodes, тогда оно расклонируется по всем нодам, 30 млн записей - фигня, физического места займут немного, лицензий вообще не потратится дополнительных, зато не будет поражняка в сети кластера и производительность вырастет.
Плюс у Вертики всегда есть доп.проекции, которые и сегментируются, и сортируются по другим правилам нежели таблица (суперпроекция).
Если это измерение из 30 млн. записей раскопировать по всем нодам, то, мне кажется, и JOIN будет происходить несколько медленее. А потом, когда я еще чего нибудь захочу сгруппировать по столбцам, отличным от ключа секционирования, то начнется еще большее веселье.
23 апр 14, 20:09    [15925153]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
loki1984
Vovaka
пропущено...


В предыдущем посте ответ.

А вообще пример довольно надуманный конечно. Оракл его везде приводит, т.к. только в этом случае может потягаться с MPP. Если кол-во таких клиентов с большим числом операций будет больше чем кол-во единиц параллелизма, то проблема вообще исчезнет.
Хэш алгоритмы, которые распределяют данные по нодам не столь умны, чтобы каждого такого клиента положить на свою ноду. Есть ненулевая вероятность, что при разбиении на секции они могут упасть на одну ноду.
23 апр 14, 20:12    [15925175]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Alexander Ryndin
loki1984,

Я с этим сталкивался просто :) Не из книжек пример.


Абонентскую базу явно проще клонировать по нодам MPP. Винты сейчас большие и недорогие. У Facebook кластер Вертики 255 серверов и на каждом 15 х 4ТБ дисков, какой raid не знаю правда, но все равно сильно.

Кстати, на пилот в FB кроме Вертики не вышел ни один из вендоров больше, к чему бы это? :) Пилот правда был на 1 ПТ, но что это за проблема для именитых вендоров? ;)
23 апр 14, 20:12    [15925178]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Alexander Ryndin
Если это измерение из 30 млн. записей раскопировать по всем нодам, то, мне кажется, и JOIN будет происходить несколько медленее.


Это почему это? Джойны будут локально на нодах происходить.

Alexander Ryndin
А потом, когда я еще чего нибудь захочу сгруппировать по столбцам, отличным от ключа секционирования, то начнется еще большее веселье.
Ну да, тут хуже. Но в Вертике можно сделать проекцию и под такой запрос и опять все полетит, но в жертву принесем физическое место.
23 апр 14, 20:17    [15925197]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
loki1984
ASCRUS,

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

Если таблица с операциями будет распределена по своему ключу, то проблема встанет всё равно, т.к. предположительно все равно в момент join будет распределение по ключу клиента. Как конкретно в вертике решена эта проблема?

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

Если же соединений очень много и измерения большие, то проще всего даже не зеркалировать их по нодам, указав Вертике в явном виде, а просто сделать преджойн проекцию с денормализацией звезды (полей измерений в факт).
23 апр 14, 20:21    [15925211]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Vovaka
Alexander Ryndin
Если это измерение из 30 млн. записей раскопировать по всем нодам, то, мне кажется, и JOIN будет происходить несколько медленее.


Это почему это? Джойны будут локально на нодах происходить.

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

А проекция это что?? эдакое Materialized view?
24 апр 14, 10:28    [15927147]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
ASCRUS
каждой ноде кластера получить с фактов список ключей клиентов и попросить другие ноды дослать ей по этому списку нужные записи для соединения дело миллисекунд. Не нужно будет даже полную копию измерения собирать со всех нод и рассылать на все ноды. BROADCAST будет минимальным.

Клевая фича. Броадкаст будет не фактов а измерения. Кстати гринплам так не умеет. Он даже и сортировку внутри нод не делает.
24 апр 14, 10:41    [15927242]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Ivan Durak
А проекция это что?? эдакое Materialized view?


Ну больше всего похоже на матвью, да. Это набор колонок таблицы (или нескольких для преджойн проекций), которые хранятся (дублируя данные в суперпроекции) по своим правилам сортировки и сегментирования. Оптимизатор выбирает наиболее подходящую проекцию для запроса.
24 апр 14, 11:26    [15927601]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ivan Durak
ASCRUS
каждой ноде кластера получить с фактов список ключей клиентов и попросить другие ноды дослать ей по этому списку нужные записи для соединения дело миллисекунд. Не нужно будет даже полную копию измерения собирать со всех нод и рассылать на все ноды. BROADCAST будет минимальным.

Клевая фича. Броадкаст будет не фактов а измерения. Кстати гринплам так не умеет. Он даже и сортировку внутри нод не делает.

Там еще один нюанс - Вертике можно же указать способ хранения для столбцов (encoding). Возвращаясь к тому примеру с 20% 5 клиентов от всей таблицы. В фактовой таблице делаем сортировку по полю account_id и назначаем ему ENCODING RLE. Теперь этот столбец будет хранится как КодКлиента:КоличествоИдущихПодрядЗаписей. При чтении контейнеров для запроса Вертика изначально уже не будет просматривать значения колонки клиента по всем записям таблицы, которые легли в этот блок, там будет ровно столько записей на эту колонку, сколько уникальных значений во всех записях этого контейнера кода клиента там присутствует. То есть моментально, вне зависимости от размера контейнера (они по мере ухода в историчность еще и укрупняются, дефрагментируясь). В этом плане кодирование хранения великая штука. Например у нас есть большой символьный код группы, групп ограниченное число, поиск по нему идет, но сортировка не выгодна по каким то причинам. Делаем ENCODING BLOCK_DICT и Вертика в контейнерах вместо самих кодов хранит значения счетчика, а все коды, используемые в записях хранимого контейнера записывает как словарик в начало контейнера кодируя внутренним счетчиком. Теперь при работе с таким кодом группы достаточно просто считать заголовок контейнера и сразу увидеть все значения, которые присутствуют в этом контейнере по этому полю. Так как записей в одном контейенере на таблицу могут быть миллионы, очень экономичный способ поиска информации без дополнительных на хранение или процессорное время, как это происходит при алгоритмах индексации данных, упорядоченного хранения и т.д. Ну а если учесть, что на каждый хранимый контейнер в заголовок пишется его статистика по полям, то вообще быстрый поиск информации без полного просмотра данных на хороших скоростях шуршит. В Нетизе помнится тоже статистика по блокам хранения данных хранится, но в отличие от Вертики у них блоки фиксированной длины, на больших объемах их много просматривать приходится, у Вертики в этом плане склонность к автоматическому укрупнению хранения данных по мере их устаревания мне кажется правильно сделано.
25 апр 14, 13:32    [15935262]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
а это как раз уже все умеют
25 апр 14, 13:47    [15935388]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
SQLMantis
Member

Откуда: Москва
Сообщений: 240
Ivan Durak
Клевая фича. Броадкаст будет не фактов а измерения. Кстати гринплам так не умеет. Он даже и сортировку внутри нод не делает.


Вы хотите сказать что greenplum, сортировку делает только на мастер-ноде?
6 май 14, 18:13    [15981969]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
SQLMantis
Ivan Durak
Клевая фича. Броадкаст будет не фактов а измерения. Кстати гринплам так не умеет. Он даже и сортировку внутри нод не делает.


Вы хотите сказать что greenplum, сортировку делает только на мастер-ноде?

нет, сортировку он делает на всех нодах паралельно. Но он НЕ ХРАНИТ данные отсортированными (так как я понял делает Вертика и Террадата) !!!
7 май 14, 13:45    [15985365]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
SQLMantis
Member

Откуда: Москва
Сообщений: 240
Ivan Durak
SQLMantis
пропущено...


Вы хотите сказать что greenplum, сортировку делает только на мастер-ноде?

нет, сортировку он делает на всех нодах паралельно. Но он НЕ ХРАНИТ данные отсортированными (так как я понял делает Вертика и Террадата) !!!


проекция (поправте меня если я не прав) - это еще одна копия данных на ноде, которая отсортирована в порядке указанном при ее создании.
Чем это отличается от индекса?
7 май 14, 15:57    [15986331]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
SQLMantis
Ivan Durak
пропущено...

нет, сортировку он делает на всех нодах паралельно. Но он НЕ ХРАНИТ данные отсортированными (так как я понял делает Вертика и Террадата) !!!


проекция (поправте меня если я не прав) - это еще одна копия данных на ноде, которая отсортирована в порядке указанном при ее создании.
Чем это отличается от индекса?

Это вообще про какую субд вопрос???
В гринпламе никаких проекций нет
7 май 14, 20:55    [15987858]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
SQLMantis
проекция (поправте меня если я не прав) - это еще одна копия данных на ноде, которая отсортирована в порядке указанном при ее создании.
Чем это отличается от индекса?


Да, так. При создании таблицы в Вертике создается суперпроекция со всеми колонками, сортированная, сегментированная, партиционированная по заданным правилам. Создание доп. проекций означает новую физическую копию части колонок таблицы (или колонок разных таблиц в преджойн проекциях) со своими правилами физического хранения (сортировка, сегментирование). Оптимизатор выберет наиболее подходящую. Больше всего это похоже на матвью. Индексы с успехом заменяют сортировка и формат кодирования хранения данных. Есть еще группировка колонок, когда можно указать набор колонок, которые физически будут храниться вместе. А-ля row storage внутри колоночного :)
7 май 14, 22:37    [15988149]     Ответить | Цитировать Сообщить модератору
 Re: Украина - вперёд с Vertica!  [new]
SQLMantis
Member

Откуда: Москва
Сообщений: 240
Vovaka
Да, так. При создании таблицы в Вертике создается суперпроекция со всеми колонками, сортированная, сегментированная, партиционированная по заданным правилам. Создание доп. проекций означает новую физическую копию части колонок таблицы (или колонок разных таблиц в преджойн проекциях) со своими правилами физического хранения (сортировка, сегментирование). Оптимизатор выберет наиболее подходящую. Больше всего это похоже на матвью. Индексы с успехом заменяют сортировка и формат кодирования хранения данных. Есть еще группировка колонок, когда можно указать набор колонок, которые физически будут храниться вместе. А-ля row storage внутри колоночного :)


Спасибо, большое. Стало интересно и я вчера почитал документацию.
Действительно интересная возможность. А почему слияние только inner?
8 май 14, 10:13    [15989320]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить