BirkhoffВот это кстати очень интересно. А как происходит процесс добавления нового сервера в кластер? Делается ли распределение данных автоматически или это делает администратор?

Подключается новый узел (сервер), запускается утилита reorg. Дальше всё делается автоматически. При этом часть данных с существующих узлов мигрируют на новый.

BirkhoffЕсть ли выделенный сервер, к которому все обращаются с запросами где что лежит, или каждый узел знает все о каждом другом?

Такого выделенного сервера нет.
Существуют виртуальные прецессы (называются Parsing Engine - PE), которые управляют в том числе и пользовательскими сессиями. Каждый процесс обслуживает до 120 соединений. Такие процессы конфигурируются так, что они работают на нескольких узлах системы.
Процессы, работающие на разныз узлах общаются посредством коммуникационного слоя, состоящего из железки (коммутатор BYNET) и соответствующего софта (если сообщаются процессы внутри одного узла, трафик остаётся локальным через драйвер BYNET).

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

BirkhoffИ как обеспечивается отказоустойивость кластера в котором 300 серверов. Ведь вероятность выхода из строя какого то из узлов резко возрастает?

Для этого существует понятие клики. Клика - это группа, как правило из четырёх узлов, имеющих физический доступ к одному и тому же RAID-масиву (в конфигурации с 300 узлами таких массивов будет много). Соответственно, если один ужел из клики умирает, то виртуальные процессы мигрируют на оставшиеся узлы, но физически они по-прежнему обрабатывают свою часть данных.

BirkhoffПотом как можно распараллелить в такой схеме операцию типа Distinct count?

Могу пока только привести пан запроса.

Запрос:


План:


Видно, что непараллельных шагов здесь нет. Очевидно, распараллеливается.
Тонкостей реализации именно DISTINCT COUNT не знаю. Сорри.



BirkhoffНачиная с 10й Oracle предупреждает, что использовать хинты - мешать работе сервера. Rule based optimizer не суппортится и в будущем может вообще исчезнуть.

Вот это я и имел в виду. То есть в 9ке хинты всё ещё нужны. В Терадате они отсутствуют напрочь.

BirkhoffЕсли данные в Оракле распартиционированы хешем, неужели он потом не используется для извлечения? :)

ОК. Требуются пояснения.
Дело в том, что в Терадате при создании таблицы вы должны указать набор столбцов, который будет использоваться для хэширования (PRIMARY INDEX).
Хэш-функция в Терадате всегда выдаёт один и тот же результат для одного и того же входного значения (т.е это не round robbin и не генератор случайных чисел).
Файловая система Терадаты в пределах одной и той же конфигурации (количество единиц параллелизма) ВСЕГДА отправляет запись с одним и тем же значением PRIMARY INDEX на одну и ту же единицуу параллелизма (в Терадате она называется Access Module Processor - AMP).
Соответвенно, если нам требуется извлечь эту запись (т.е выполнить запрос вида SELECT ... FROM t1 WHERE PI = ...), то мы всегда знаем какой AMP хранит эту запись.

В Оракл значение столбца (столбцов), по которым производится хеширование не даст возможности напрямую извлечь запись. Нужен дополнительный индекс.
В Терадате же Primary Index - это не индекс, а функция.

BirkhoffНу вы же сами говорите, что у Терадаты модель shared nothing. У Oracle это не так. Поэтому масштабирование достигается не кластеризацией на 300 серверов, а железом и дисковыми массивами.

Масштабирование в случае Терадаты достигается железом и дисковыми массивами. Кластеризация - это несколько другое.
Тем более, в Терадате тоже есть понятие кластер, но оно используется несколько по-другому (это ещё один софтверный механизм повышения отказоустойчивости системы).

Разница между масштабируемостью Терадаты (и в целом архитектуры MPP) и масштабируемостью Оркл (и в целом СУБД, работающих на SMP-платформах) заключается в том, что у Терадаты масштабируемость линейная (т.е при добавлении новых узлов, производительность растёт прямо пропорционально), а в СУБД на SMP-платформах этого нет в силу того, что производительность SMP-систем нелинейно зависит от количества процессоров (в силу возрастающего оверхеда на межпроцессорное взаимодействие).

Побочный эффект - в случае Терадаты нужно меньше процессоров для получения системы аналогичной производительности.

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

Опять-таки, разница между "можно придумать" и "активно используется" довольно велика. Представьте себе ситуацию, когда громадная (миллиарды записей) таблица хранится в одной копии на дисовом массиве, который внезапно выходит из строя. Что делаем? Ставим новый массив и заливаем данные из бэкапа или грузим повторно из источников. Как долго? Долго.
Если есть FALLBACK-таблица, то система просто продолжает работать и журналировать все изменения, пока мы не поднимем упавший массив. После этого система автоматом синхронизирует таблицы.

BirkhoffДа я в общем-то не провоцирую, а пытаюсь получить ответы на вопросы, которые меня интересуют :)

Как говорится в известной рекламе - Вэлком !!!

С радостью буду отвечать и на другие вопросы.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

BirkhoffСобственно я имел в виду, что происходит при обновлении хранилища (вставке новых записей, или апдейте) Блокируется ли доступ пользователям, пока записи расползаются по серверам или какой то другой механизм работает?

Это смотря как вставлять. Если по одной записи - то блокировка на уровне ROW HASH со всеми вытекающими последствиями.
А если исползуются утилиты быстрой загрузки данных FASTLOAD и MULTILOAD, то таблица на время загрузки переводится в недоступное для выполнения запросов состояние.
В общем, Терадата - типичный блокировочник, если Вы именно это хотели узнать.

BirkhoffСудя по этому плану (насколько я его понял), параллельно данные считываются из разных партиций таблиц в SPOOL 4, а по спулу уже идет агрегация. Хотя там и написано all-AMP, но если spool один, то как по нему можно устроить параллельную обработку?

Спул то один, но он тоже распределяется по узлам. Как я уже говорил, в терадате все таблицы распределяются.
К тому же, можно видеть, что в спул 4 ожидается одна запись. Вероятно, на этом этапе уже все считается.

Кстати - небольшое терминологическое отступление. Партиция в Терадате означает несколько другое. Это понятие логическое, а не физическое.
То есть, партиция не показывает физическое место на диске, где хранятся записи. И, вообще, в Терадате записи не хранятся в фиксированных местах (особенности её файловой системы).
В общем, речь идёт не о хш-партишионинге, а о хэш-дистрибьюшене. Пардон за большое количество иностранных слов.

По параллельной обработке - остаюсь на своём. С тонкостями реализации не знаком.

BirkhoffТаблспейсы могут быть физически разнесены по дискам и когда мы делаем select - Oracle будет вычислять хэш-функцию для каждого deptno и по ней поймет в каком таблспейсе лежит конкретная запись.

А план запроса с указанием метода доступа не приведёте?
А как он поймёт, в каком тейблспейсе искать? В терадате, например для этого хэш-карты используются. Правда, тейблспейсов там нету. Вообще, там файловая система проще - меньше объектов.
Никаких тейблспейсов создавать не надо. Только CREATE TABLE с указанием PRIMARY INDEX. Дальше всё автоматически.

То есть:

CREATE TABLE dept (deptno INTEGER, deptname VARCHAR(32)) UNIQUE PRIMARY INDEX (deptno);

Интересно, каков будет размер оператора создания таблицы, приведённого Вами, если количество хэш-партишинов будет 65535 (как в Терадате)?
И как эти партишионы разнести по тейблспейсам и дискам эффективно?
И что происходит при добавлении новых дисков, тейблспейсов, партишионов?
Как вообще этим всем управлять можно?


BirkhoffВот этот момент я не понял. RAID массив сам дублирует данные в таблицах на случай выхода из строя дисков в массиве. В этом смысле от нас не требуется никаких дополнительных действий по распределению данных по дискам. Это делает сам RAID (ну или ASM если мы его используем)
Поэтому если диск выходит из строя - заменяем диск и данные сами переходят на новый диск. Никакой остановки системы тут даже не требуется.
Вот с случае shared nothing без использования клик, о которых вы сказали, такое принудительное дублирование, наверное, имеет смысл. Но не в случае Оракла.

Всё что происходит на уровне RAID - то же самое и в Терадате.
А, вот, что произойдёт, если дисковый массив выйдет из строя, например, горят два диска в линейке или из-за сбоя по питанию вылетает вся коробка?
В Терадате существует второй дисковый массив (в другой клике), на котором хранится вторая копия таблицы, с которой можно продолжать работать.

Кстати, есть ещё один механизм повышения надёжности - называется DUAL ACTIVE - это когда в режиме активный-активный работают две системы (то есть, полное дублирование систем, но при этом обе работают в активном резиме, выполняя запросы). На данный момент несколько клиентов успешно эксплуатируют такие системы (как правило, их разносят географически для обеспечения защиты от неприятностей типа стихийных бедствий).

BirkhoffХотя в Oracle ничего не мешает внутри партиции построить индекс и искать по нему.

Да, но это дополнительный индекс, как я уже говорил. Место занимает, обслуживания требует, опять-таки.

BirkhoffХотя для DWH hash партиции редко (если вообще) используются, обычно какие то другие, призванные сузить спектр поиска до партиции или нескольких.

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

BirkhoffТогда при оптимизации запроса, будет вычисляться не партиция для каждой записи, а из каких партиций вообще имеет смысл данные доставать, а какие не трогать. Техника называется partition pruning.

В Терадате такая же фича имеется. Называется PARTITIONED PRIMARY INDEX. Оно уже для сужения поиска и используется.
А partition pruning в Терадате называется partition elimination.

А ещё отдельные партиции бэкапить можно. Ну, это, наверное, и Оракл может тоже.

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

Всё Терадата делает автоматически.

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

Если Вы делаете в Оракл партишионинг не по хэш, а какими-то другими способами, то равномерного распределения данных между единицами параллелизма достичь невозможно.
Соответственно, фулл-сканы будут не такими эффективными, как в Терадате. Соответственно, запросы типа ad hoc (характерные для хранилищ данных) не будут выполняться также эффективно, соответственно, нужно строить индексы, обслуживать их и со страхом ждать запросов, под которые не построены индексы :)



С уважением,
Константин Лисянский
http://lissianski.narod.ru

Birkhoff Отсюда вопрос - насколько быстро это происходит в случае распределенной системы. Например, есть у нас 300 узлов, и пошел апдейт. Не станет ли тут узким местом как раз распределенность?

Смотря какой UPDATE. Если пошёл UPDATE по PRIMARY INDEX (столбцам, по которым выполняется распределение данных), то, действительно, будет трафик между узлами. Однако, первичные индексы в большинстве случаев (хотя, не всегда) совпадают с первичными ключами, а кому надо апдейтить первичные ключи? В случае апдейта столбцов, не входящих в первичный индекс, все апдейты происходят локальло в пределах одного AMP без пересылки записей между узлами.
Но, на самом деле, межузловой трафик - это тоже не страшно. Он есть постоянно, поскольку джойны очень часто требуют перераспределения данных между узлами. На это существует коммутатор с очень приличной пропускной способностью.

BirkhoffИ кто подает сигнал, что все таблицы обновились, можно снимать блокировку?

Lock Manager

BirkhoffИ куда коннектятся пользователи? На любой узел или на какой то конкретный?

На конкретный. На котором имеется PARSING ENGINE. Как я уже писал, один PE может обрабатывать до 120 сессий. Система конфигурируется так, чтобы распределить PE между узлами.

В принципе, все узлы равноправны, то есть, по большоу счёту, не важно к каму узлу коннектиться пользователь.

BirkhoffСобственно вопрос был даже не по Терадате, а вообще, как в даже в теории распараллелить distinct count. Ну ОК, допустим Терадата это как-то все-таки делает. :)

Я это понял. В противном случае не спросили бы :)

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

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

BirkhoffЭтим всем в основном администратор управляет. Автоматом мало что делается. Но честно говоря не вижу тут большой проблемы.
Ну, если речь идёт о сотняз или тысячах объектов, за каждым из которых нужно следить, то желательно поменьше действий в расчёте на один объект выполнять. В противном случае администрирование в кошмар превращается.

И если речь идёт о терабайтных системах, то лишний раз данные перезагружать - тысячу раз подумаешь.


BirkhoffИмхо, какая-то надуманная проблема

Да. нет. Выход из строя RAID-массива вполне вероятная вещь. Хорошо, не бомба. Дрогнула рука техника - вместо вышедшего из строя диска выдернул соседний из этой же линейки. Да, мало ли что ещё может произойти...

BirkhoffНо если бобма в здание попала с сервером, то и тут есть разные технологии типа Data Guard, которые позволяют практически в реальном времени создавать дубль базы на дургом сервере и в случае полного уничтожения основного сервера - поднять резервный. Видимо что то похожее на Dual Active.

Ну, не совсем. Если в случае Data Guard нужно резервный сервер поднимать, то в случае Dual Active он постоянно работает и приносит пользу.

BirkhoffДа, но это дополнительный индекс, как я уже говорил. Место занимает, обслуживания требует, опять-таки.

Не думаю, что это основной bottleneck :)

Конечно, нет, но индексов нужно больше. А это - больше дискового пространства, больше администрирования.
В целом работает правило, что Терадата требует меньше дискового простанства чем любая другая СУБД (кроме, пожалуй, Sybase IQ, который в этом плане делает всех :)

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

В смысле одинаковое количество строк с каждого диска (единицы параллелизма)? В принципе, да, это непростая задача.
Но, давайте рассмотрим простейший случай - отсутствие каких-либо индексов.
Имеем таблицу в миллион записей, систему из 100 устройств параллелизма (10-узловая машина с Терадатой). Соответственно, на каждом узле будет храниться по 10 тысяч записей (примерно, при условии, что первичный индекс выбран правильно). Запросы с выборкой по первичному индексу нас мало интересуют - они выполняются очень быстро, правктически всегда за одно чтение с диска. Других индексов нет.
Есть запрос на выборку по полю, не являющемуся первичным индексом (по полу, например). В этом случае все 100 устройств параллелизма будут сканировать свою часть таблицы, сотоящую из 10 тыс. записей. Это вполне предсказуемая нагрузка. Ясно, что, поскольку наши записи перемешаны в случайном порядке, количество записей с мужским или женским полом будет примерно одинаковым на каждом устройстве параллелизма.

Имеет это какой-то смысл или я слишком увлёкся?


BirkhoffНу, это уже маркетинг пошел :)

Сорри, не хотел :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru

По поводу COUNT DISTINCT.
Допустим, есть таблица заказов:
order_id, order_date, customer_id, product_id, amount

Вполне логично допустить, что первичным индексом будет order_id для равномерного распределения таблицы по дискам.
Теперь надо вычислить сколько уникальных клиентов сделали заказы в течение года.

SELECT count(DISTINCT customer_id) FROM orders;

Как посчитать параллельно?
Первое соображение - в силу хэширования потенциально на каждом диске имеются записи содержащие все значения customer_id.

Давайте первым шагом перераспределим данные между узлами по столбцу customer_id.

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

В результате получим, что все записи с Васей Пупкиным лежат на одном узле, с Петей Таракановым - на другом и т.д.

Теперь осталось для того, чтобы найти DISCTINCT записи отсортировать каждый кусочек таблицы локально на каждом устройстве параллелизма.
Опять-таки это параллельная операция. Длительность пропрциональна N*logN/nAMPS (где nAMPS - количество единиц параллелизма).

Вот и всё.

Можно и по-другому - сначала сортируем данные локально по столбцу customer_id (N*logN) и убираем дубликаты.

Потом перераспределяем данные по столбцу customer_id (их уже будет меньше, поскольку мы убрали дубликаты локально).

Потом повторно выполняем сортировку и устранение дубликатов.

Не знаю, какой из способов эффективнее. Скорее всего, при разной демографии данных по-разному.
На это и существует оптимизатор, чтобы выбрать между ними.

Но видно то, что операцию DISTINCT COUNT можно выполнять параллельно.

Я думаю, что этими двумя вариантами дело не ограничивается, наверняка есть ещё алгоритмы. Но дальше думать ломает - спать уже пора.

Кстати, мне почему-то кажется, что это не самая сложная в распараллеливании задача.
На ум приходят нарастающие и скользящие итоги и прочие OLAP-операции, которые тоже выполняются в Терадате параллельно.


Спокойной ночи :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru

Что-то не спится мне :)

Поковырялся тут в интернете (славься Гугл, великий и могучий :). Нашёл интересную статейку .

Как в воду глядел. Два алгоритма, которые я описал в предыдущем посте упоминаются как базовые. Я ещё не рассказал о третьем базовом алгоритме, поскольку счёл его неэффктивным (это когда локально отсортированные записи отправляются на координационный узел, где производится глобальная сортировка). Оказывается, этот алгоритм эффективен на небольшом количестве DISTINCT групп.

В общем, авторы развивают эту идею и предагают несколько модифицированных алгоритмов, которые получаются путём "скрещивания" первого, второго и третьего. Любопытная статья для общего развития.

Да, ещё нашёл презентацию по Терадате. Тоже довольно интересная. В картинках объясняет архитектурные принципы и преимущества Терадаты.

Ну, теперь уж, точно спокойной ночи :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru

Продолжает неспаться :))
Тема-то оказалась очень интересной. Это всё про паралелизм.
Вот, нашёл ещё одну презентацию по Терадате , в которой есть небольшой пассаж про параллельные алгоритмы (см. стр. 39):


Опять-таки без подробностей, но кое-какие выводы сделать можно.
Скорее всего, применяются адаптивные алгоритмы (в терминах статьи, ссылку на которую я привёл постом выше) - When local cache fills, spill lowest hit items to global

Удачи!


С уважением,
Константин Лисянский
http://lissianski.narod.ru

Тем более, что Оракл, вроде бы здесь не относят к "Другим СУБД".
Вероятно, имелось в виду "Сравнение СУБД". Однако, там, как правило, не обсуждаются вопросы DWH.
Так что, присоединяюсь к backfire. НАверное, всё-таки, по теме.
К тому же, разве не интересно было узнать, как работают параллельные алггоритмы агрегирования?

По поводу PR - я максимально стараюсь придерживаться технического сравнения. Возможно, иногда заносит. Приношу извинения, если это кого-то обижает.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

P.S. Если читаете этот топик, наверняка, интересно :)

Мне кажется, не надо в отдельный форум.
Эта тема пока не получила большого распространения чтобы выделять её в отдельную. ИМХО, конечно.


С уважением,
Константин Лисянский
http://lissianski.narod.ru