TorinТолько один момент - teradata одна из самый "старых по рождению" баз данных

Это правда. Терадата - одна из старейших реляционных баз данных.

TorinЭто была иерархическая база данных, сейчас она почему то RDBMS

Она всегда была реляционной.

Angel13Я слышал, что изначально он разрабатывался как специальная СУБД для БИ

Это так. Терадата изначально разрабатывалась для создания систем поддержки принятия решений (хранилищ данных, хотя в то время такого термина ещё не было).
Когда она создавалась (конец 70-х, начало 80-х), кроме мейнфреймов ничего не было. Была маленькая компания под названием Intel. Инженеры Teradata сделали ставки на микропроцессоры Intel. Идея была такая - объединить большое количество микропроцессоров для параллельной обработки данных. Таким образом появилась архитектура MPP - массивно-параллельная обработка.
Сегодня это самая мощная реляционная СУБД для хранилищ данных. Крупнейшие в мире хранилища данных работают на СУБД Терадата.
Она отлично масштабируется, имеет высокую производительность и очень легка в обслуживании. Поддерживает стандарт ANSI SQL, доступна для любых клиентских приложений (через интерфейсы ODBC, JDBC, CLI).

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

TorinВообще говоря, инфы очень много, можно начать с http://www.teradata.com

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


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

Не за что. Задавайте вопросы. Отвечу.
Демо-версии практикуются. Можно заказать по ссылке ниже.



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



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

Она по прайслистам не продаётся.
Задавайте лучше технические вопросы.
Тут не интернет-магазин, а технический форум :)

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

По-моему, пора вводить обязательную регистрацию с подтверждением по email как это делается в серьёзных форумах.

Юрий, не забывайте, пожалуйста, выполнять

Правила форумаЗаполнить свой профиль и по возможности указать свое полное имя

Не надо стыдиться себя самого.

2ALL: Скорее всего, цен на Терадату вы здесь не увидите.
Ещё раз призываю обсуждать технические вопросы.

Если хотите цены - обращайтесь, пожалуйста, в компанию, которая эту самую Терадату продаёт.

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

Можно.

Компания называется NCR.

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

Вообще-то Warehouse Builder должен устанавливаться в рамках Teradata Client.
У Вас должна быть группа Teradata Client, поищите там Teradata Warehouse Builder Visual Interface.
Может, просто не установили клиента?
Что у Вас установилось, можете перечислить?


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

JuriiЯ являюсь специалистом по Cognos, и не хочется усложнять жизнь читателям моих постингов - поэтому сообщение в форум Работа, и постинг про терадату я писал от имени Guest_321.

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

Знакомых в NCR у меня много поскольку я сам работаю в этой компании.

Как и у любой большой компании у NCR много партнёров - BusinessObjects, Cognos, Hyperion, Microsoft, Microstrategy, SAS и другие (перечислены не в порядке важности, а по алфавиту).

Какие вопросы хотите обсуждать за пивом?


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

JuriiВо-первых, стоит выпить за партнерство между Cognos и NCR :)

Ну, если честно, то у меня много других поводов выпить. Хотя и за это готов тоже. Славься Когнос

JuriiЧто касается серьезных дел, то хотелось бы обсудить вопросы масштабирования хранилищ данных на Терадате, и как она работает на мультипроцессорных серверах, вопросы соотношения цена/качество.

Теоретически масштабируются до 2048 процессоров (1024 узла в массивно-параллельной конфигурации).

Практически пока самая большая система - около 300 узлов. Объёмы данных исчисляются десятками и сотнями терабайт.

Так что, масштабируется

Чтобы понять, как Терадата работает на мультипроцессорных системах (а на других системах большого смысла в ней нет) достаточно почитать Introduction to Teradata Warehouse . Там это объясняется.

Соотношение цена/качество замечательное. Очень качественный продукт

OLAPMASTERКоль пошел разговор о хранилище данных, то есть хоть что то чем Oracle 9I уступает Teradata??

Терадата является специализированной СУБД для корпоративных хранилищ данных. Oracle в основном позиционируется для OLTP. Терадата на рынке OLTP не присутствует, зато доминирует на рынке больших корпоративных хранилищ данных.

Терадата является масштабируемой, высокопроизводительной, лёгкой в сопровождении СУБД.

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

Оптимизатор Терадаты изначально был cost-based (то есть, развивался около 20 лет). В Оракл оптимизатор только недавно стал cost-based. Выводы делайте сами.


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

На самом деле, все различия кроются в архитектуре.
Терадата использует несколько базовых принципов:
1. Массивно-параллельная архитектура с высокой степенью распараллеливания всех запросов. Соответственно, возможность собрать систему с заданным уровнем производительности.
2. Хэш-партишионинг как средство для равномерного распределения данных между единицами параллелизма для обеспечения высокой степени параллельной обработки.
3. Продвинутый оптимизатор, с эффективными алгоритмами параллельной обработки данных.
4. Высокая степень избыточности (по необходимости) для обеспечения высокой готовности. Например, помимо поддержки RAID и дублирования узлов в Терадате есть дублирование таблиц на уровне СУБД. Называется FALLBACK - фактически полное дублирование избранных таблиц в двойном экземпляре для того, чтобы суметь пережить падение узлов системы.

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

BirkhoffНу это не совсем верно, Oracle давно не делает упора только на OLTP.

Сравнительно недавно по сравнению с Терадатой :)

BirkhoffВ СУБД Oracle очень много фич, обычно присутствующих только в специализированных базах.

Абсолютно согласен. В Оракл, на мой взгляд, фич больше, чем в любой другой СУБД.

BirkhoffС масштабируемостью тоже ничего. Вот нашел наконец линку http://www.wintercorp.com/VLDB/2003_TopTen_Survey/All%20Winners.pdf

Исследование Винтера потихоньку начинает дискредитировать себя.
Например, в нём не участвуют крупнейшие клиенты IBM и Терадаты Подумайте, у них ведь нет никакого стимула участвовать в нём.
Ну, и потом, Винтер не оценивает сложность запросов - простое деление OLTP/DSS ещё ни о чём не говорит. Нет ничего похожего на full disclosure report как в тестах TPC (опять-таки, зачем клиентам это нужно?).
Так что, надо осторожно относиться к таким исследованиям (имея ещё в виду, что маленькая компания не может быть неангажированной каким-нибудь производителем :).

BirkhoffВидно, что Oracle неплохо себя чувствует в DSS, даже по сравнению с Терадатой.

Да, но есть факт - за последние три года более сотни крупных компаний заменили Оракл на Терадату в качестве корпоративного хранилища данных.
ЗА прошлый год не было ни одной замены в обратную сторону (в предыдущие годы только несколько, которые также можно поставить под вопрос).


BirkhoffКстати, а почему Терадаты нет в TPC-H тестах?
Терадата долгое время участвовала в тестах, начиная с TPC-D и всегда занимала первые места.
Но эти тесты очень ограничены и удалены от реальной жизни. Те запросы, которые выполняются клиентами Терадаты гораздо сложнее тестов TPC.
В одно время производители поняли, что TPC - это здорово, и стали встраивать в свои СУБД фичи, специально предназначенные для победы в тестах. Согласитесь, это не очень продуктивное занятие, если эти новые фичи не помогают в реальной жизни.
Ну, и потом, эти тесты стоят довольно дорого. NCR - не такая богатая компания, как, скажем, Оракл или IBM. Поэтому эти деньги идут на R&D, что, на мой взгляд более полезно.
Ну, и наконец, надо заметить, что в тот момент, когда Терадата ушла с тестов TPC она очень сильно опережала ближайших соперников (которые, по-моему, только через год смогли продемонстрировать аналогичный результат). То есть, это был уход сильного игрока, а не слабого.

BirkhoffТо есть куски базы данных распределяются между серверами?

Абсолютно верно. С одним уточнением - куски КАЖДОЙ таблицы (каждого индекса тоже), включая даже таблицы системного каталога.

BirkhoffНу "недавно" это уже лет около 10. Да и потом в этом деле совершенно не обязательно алгоритм разрабатывать 20 лет. Можно и за месяц придумать что-то эффективное :)

В какой версии CBO от Оракл перестал иметь необходимость принимать от разработчика хинты для нормальной работы? :)
За месяц - ГЫ :)

BirkhoffВ Oracle тоже запросы параллелятся, но допускаю что в Терадате это может быть делается лучше.

Это правильное допущение :)


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

Да, но отличие в том, что в Терадате файловая система построена на хэшировании, то есть хэширование не только используется для того, чтобы раскидать данные, но и для того, чтобы потом получить к этим данным доступ. То есть, зная хэш-код записи мы всегда знаем куда надо идти, чтобы получить к ней доступ. Ни одна СУБД, использующая хэширование не использует хэширование для доступа к данным, только Терадата.
Любой другой вид партишионинга не даёт такого равномерного распределения данных для обеспечения эффективной параллельной обработки данных. Поэтому в Терадате другие виды распределения данных не применяются. Есть так называемый RANGE и CASE партишионинг, но они играют вторичную роль. Данные всегда сначала хешируются.

Birkhoff"Продвинутость" оптимизаторов сравнивать сложно.

В принципе, да, довольно сложно. Надо достаточно хорошо знать этот предмет.

BirkhoffВ Oracle для переживания падения узлов есть Real Application Clusters.

Всё здорово, но где Вы видели систему на Оракл, состоящую хотя бы из десятка узлов (не говоря о сотнях)?

BirkhoffА дублирование и страйпинг на уровне СУБД делается, например с помощью ASM (Automatic Storage Management)

Не знаю, что это такое. Можно ли, например, в Оракл средствами СУБД продублировать только одну критически важную таблицу?

BirkhoffP.S. Вообще, неблагодарное это занятие - рассказывать чем твой продукт лучше, чем продукт конкурента, а тем более чем конкурент хуже :)
Конкуренты обычно знают свой продукт лучше и могут найти ответ.

Согласен на все сто. На то она и конкуренция. Я не старался сказать, что Оракл хуже. Я просто хотел показать, какие свойства есть у Терадаты и как они обеспечивают ей конкурентные преимущества. Несмотря на провокационность Ваших вопросов :)


Удачи!

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

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