НиколайКонстантин поправит.

В Teradata тоже наверное есть понятие как сolocated join

Это когда подбирется ключ для хэширования одинаковый для нескольких таблиц.

Например
Table Customer
(customer_id, customer_columns...)
Table transactions
(trans_id, customer_id, trans_columns...)

Partitionig key выбирается для обеих таблиц сustomer_id

Тогда join этих таблиц идет в пределах одного узла без передачи данных на другие узлы.


Пример примитивный не учитывает что может быть data skew (когда на одном узле данных больше чем на другом)


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

Про data skew немного не понял - поясните, пожалуйста.



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

OLAPMASTERНезнаю Константин Вы так все интресно рассказываете, но Oracle поверьте мне уж очень хорошо напичкан вопросами хранения данных, и таблицные пространства на разных дисках и партиции и путь теже хинты(писать запросы надо готовой а не мышкой!!!) делают его более гибким чем слона Терраду.

Я знаю, чем напичкан Оракл.
Расскажите произодителям репортинговых тулзов, чем надо писать запросы, а также расскажите бизнес-пользователям, что им всем поголовно надо выучить SQL и в совершенстве освоить хинты.


P.S.
Кстате в Oracle тоже локализуеться запрос на партицию. Так что это не только для хранения но и для доступа к данным

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



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

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

В Терадате ВСЕ запросы, в условии WHERE которых стоит условие на PRIMARY INDEX (столбец, или набор столбцов, по которым осуществляется хэш-распределение) выполняются за одно чтение с диска, то есть, не только партишион (AMP) определяется, но и выбирается конкретная запись.

То есть, запрос


выполнятся за одно чтение.

PiНо Oracle предлагает использовать комбинированные секционирования, например, range+hash. И тут как бы все в порядке - и красота в распределении, и удобство администрирования.

Терадата тоже. Только немного в другой последовательности - сначала хэш, а потом RANGE или CASE.
При этом партишионинг второго уровня осуществляется логически, а не физически.


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

OLAPMASTERВот сдесь действительно может возникнуть непонимание из за того что одно и тоже слово имеет разные значения. Я так понимаю этот хеш индекс он всеравно есть в Терраде и по нему происходит основной поиск. Но вот вопрос если например запрос с HEAVING то как сдесь поможет этот ключ, надо найти всех покупателей короые сделали больше чем 100 покупок в сумме, как он пойдет,что ему даст этот индекс?? да он обработает всех покупателе и сбросит их в буфер а там будет смотреть у кого больше 100.
Или как он пойдет, если возможно план показать это было бы интересно.

Хэш-индекс - это не индекс в традиционном понимании.
Тут, видимо, надо рассказать, как это работат.
Итак, при создании таблицы выбирается столбец (группа столбцов), которые используются для распределения таблицы по единицам параллелизма (которые в Терадате называются AMP - Access Module Processor).
Ок. Создали таблицу теперь нужно её наполнять.
При выполнении операции вставки записи в таблицу значение столбца, являющегося первичным индексом пропускается через хэш-функцию. В результате получается 32-битное число. Одна половина этого числа (называется DSW - destination selection word) исползуется для отыскания того AMP, на диске которого будет храниться эта запись. Вторая часть (remainder) используется как часть ROWID.
Нетрудно заметить, что DSW может принимать 65536 значений.
Эти значения (при конфигурировании системы) размещаются в матрице (хэш-карте), которая адресует AMPы.
То есть, по значению DSW мы можем однозначно сказать, на какой AMP пойдёт данная запись.
Дальше этому AMPу отправляется сообщение о том, что надо вставить новую запись.
AMP со своей стороны вставляет запись в таблицу. При этом записи присваивается ещё одно число поимио того, которое она получила при хэшировании первичного индекса. Называется оно uniquness value.
Число, полученное при хэшировании и uniquness value вместе образуют ROWID записи, которое хранится в таблице вместе с записью.
Вставляемая запись помещается в блок (блоки имеют переменную длину). Блоки хранятся в циллиндрах и адресуются внутри циллиндра с помощью специального индекса (CYLINDER INDEX). Циллиндры также индексируются (MASTER INDEX).
Записи хранятся в порядке логически отсортированных ROWID и не имеют постоянного места на диске (кстати, в силу этого в Терадате не требуется периодическая реорганизация индексов).

Таким образом хэш-индекс - это не индекс в традиционном понимании (то есть структура, которая хранит соответствие значение-адрес записи), хотя физически он занимает место (в основном это ROWID, master index и cylinder index занимают не много места).

Соответственно, поиск по первичному индексу происходит очень быстро - хэшируется значение, стоящее в условии WHERE запроса, и Терадата знает какому AMPу надо послать сообщение, чтобы он её достал.

Дальше используется двухуровневая структура master index-cylinder index, и запись извлекается.


Теперь по поводу запроса с HAVING.
Естественно, первичный индекс здесь использоваться не будет. Будет FULL TABLE SCAN.

Под рукой нету подходящей таблицы.
Давайте из таблицы товаров:


План запроса:



Этот запрос выполняется с предсказуеой степенью параллелизма (All-AMP, то есть параллельная работа всех единиц параллелизма).



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

OLAPMASTERСпасибо Константин, кажеться вы пролили свет на меня. Я понял что это просто организация хранения данных. Далее можно строить индексы на эти АМР-ы что бы там еще быстрее работать да??

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

OLAPMASTERНо я так понимаю операция insert там очень жестко проходить, надо захешировать все записи определить в какие АМР-ы их класть и перестроить индексы это наверно долго.

Не совсем так. Операции массовой загрузки данных из плоских файлов, например, в Терадате выполняются чрезвычайно эффективно. Потому как выполняются они параллельно. Операции INSERT INTO ... SELECT также выполняются эффективно. Скажем, у меня на одноузловой машине такая операция на 250 млн. строк (примерно 10 ГБ) выполняется порядка 6 минут (то есть, со скоростью порядка 700 тыс. записей в секунду).


Конечно, догнать Оракл в приложениях класса OLTP Терадате, я думаю, не удастся. Но она и не для этого разрабатывалась.
Это я к тому, что операции вставки и обновления единичных записей, действительно, для Терадаты довольно тяжелы.
Однако, если речь идёт, напрмер, о коротких запросах на чтение данных, то это не проблема. У Терадаты есть клиенты, где такие запросы работают параллельно с тяжёлыми запросами DSS, то есть нагружка носит смешанный характер.
Например, в сети казино Harra's в день выполняется до 300 тысяч таких коротких запросов, которые работают параллельно со сложными запросами. Время отклика таких запросов меньше секунды.

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

Если хотят писать в таблицу, то ждут. Если хотят читать, то могут делать это параллельно с этим запросом.
Более того, если двум (или более) запросам нужно сканировать одну и ту же таблицу, то Терадата может это делать один раз для всех (даже несмотря на то, что второму и третьему запросу надо начать сканировать позже). Это называется syncronized table scan.

OLAPMASTERВообще запросы с HAVING штука тяжелая.
Не для Терадаты. Поскольку она выполняет их параллельно.

OLAPMASTERВот пример Oracle как будет выполнять запрос на поиск таких мест продаж

Трудно понять степень параллелизма этого запроса, соответственно, и оценить его эффективность.

OLAPMASTERНо ничего не заблокировал!
В хранилищах данных, в общем случае, вопросы блокировок не так актуальны, как в OLTP-приложениях. В них транзакционность меньше выражена. Поэтому принципиальных преимуществ версионность здесь, на мой взгляд, не даёт.


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

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

Конечно, есть. Вечно мы думаем, что мы какие-то уникальные, и что у нас всё по-другому.
Я думаю, половина крупных телекомов в мире использует Терадату в качестве платформы для хранилищ данных.
Розница и банки тоже не отстают.
Ещё один факт - такие компании, как SAP и Siebel заключили с Терадатой стратегическое партнёрство.
К тому же у Терадаты не только СУБД имеется. Есть ещё куча приложений. Например, для той же розницы - Retail Decisions (OLAP/Reporting), Supply Chain Intelligence, Demand Chain Management, Price Optimization, Market Basket Analysis, Fraud Detection, POS Productivity и ещё много чего.
Есть отраслевые модели данных.
Есть аналитический CRM, который занимает лидирующую позицию среди приложений этого класса.
Так что, рынок есть.


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

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

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

ОК. Здесь, наверное, следут пойти дальше, и коснуться других индексов, которые есть в Терадате.
Расскажу о том, что такое secondary index.
Начну с того, что в Терадате не используются B-tree индексы. Вторичный индекс в Терадате - это тоже таблица, которая также распределяется по всем единицам параллелизма.

Допустим, у нас есть таблица клиентов, которая посредством перцичного индекса customer_id распределяется по единицам параллелизма (AMPам).

Допустим, у нас есть другой способ уникальной идентификации клиента (альтернативный ключ). Предположим, что это passport_number. Предположим также, что все номера паспортов уникальны (наверное, это близко к действительности).

Если нам нужно отыскать в таблице клиента по заданному номеру паспорта, а по этому полю нет индекса, то выполняется (как и везде) полное сканирование таблицы.
Если мы знаем, что такие запросы будут выполняться часто, мы можем принять решение создать по этому полю индекс.
ОК. Создаём.

CREATE UNIQUE INDEX (passport_number) ON T_Customer;

Что происходит физически? Терадата создаёт вспомогательную индексную таблицу и распределяет её как будто это обычная таблица с первичным индексом passport_number. Кроме passport_number в этой таблице хранится ROWID строки, содержащей клиента с номером паспорта, кранящемся в данной строке индексной таблицы.
В общем случае строки индексной подтаблицы распределены по AMPам не так, как строки базовой таблицы (за редким исключением когда хэш-значение первичного индекса совпадает с хэш-значением вторичного).
Теперь нам нужно выбрать запись с паспортом определённого номера.
Оптимизатор понимает, что есть индекс, соответственно, сначала ищется строка индексной таблицы, которая содержит номер паспорта, который мы указали в запросе. По аналогии с доступом по первичному индексу (см. мой пост на эту тему выше), эта операция выполняется за одно чтение с диска.
После этого чтения у нас будет ROWID нужной записи в базовой таблице. Далее всё происходит ещё раз - по ROWID определяем какой AMP содержит эту запись и отправляем ему сообщение, чтобы он её достал.
В итоге использщование уникального вторичного индекса позволяет за два чтения с диска достать нужную нам запись.
Не так эффективно, как в случае с первичным индексом, но тоже очень быстро.
Это расширяет спектр запросов, которые можно охарактеризовать как pruning (хотя это немного другое).


Теперь по поводу - где что лежит. В терадате это - не загадка. Существуют функции, которые позволяют посмотреть, на каком AMPе лежит данная запись.

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



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

Birkhoff Похоже, что опять маркетинг пошел :) Я же про Россию спрашивал. :)
Ну да ладно, это была провокация с моей стороны.
Я и так понял, что система очень интересная, да и наша дискуссия заставила взглянуть на некоторые вещи по-новому. :)

Я отдавал себе отчёт и предвидел про маркетинг :)
Ну, а как я ещё смог бы про перспективы рассказать?
Дейтвительно, провокация :)

Я рад, что дискуссия приносит пользу не мне одному :)

BirkhoffА вот вопрос более технический.
А что с клиентами к Терадате?

Всё, что работает через ODBC и JDBC можно прицепить.
Например, BusinessObjects, Microstrategy, Cognos, Brio, Siebel Analytics, Crystal Reporting, SAP BW и.т.д
Хотите, можно Excel.

BirkhoffКаковы возможности SQL?
Очень хорошие. ANSI-99 довольно широко поддерживается. Плюс расширения Терадаты.
Из основных фич:
- аналитические и OLAP-функции (нарастающие и скользящие итоги, CUBE, ROLLUP, RANK OVER, статистика и т.д.)
- рекурсивные запросы (в стандарте ANSI)
- триггеры (в стандарте ANSI)
- UDF
- хранимые процедуры (SPL в стандарте ANSI)
- курсоры
- все виды джойнов (до 64 в одном запросе, самое интересное, что при этом работает)
- подзапросы с диким уровнем вложенности (тоже до 64, но это не пробовал :)

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

Microstrategy, BusinessObjects, Cognos (ReportNet) специально оптимизируют SQL под Терадату чтобы перенести нагрузку с клиента.
Все остальные могут использовать стандартные фичи.
В этом плане Терадата мало чем отличается от конкурирующих СУБД.

BirkhoffЕсли да, то может расскажете что-то что вам кажется интереесным на эту тему?

Наличие собственного средства класса data mining (называется Teraminer), реализующего концепцию in-database data mining. То есть вместо того, чтобы выгружать данные из базы (как это делают другие инструменты), data mining выполняется на стороне СУБД.
Это, я Вам скажу, действительно, требует мощной платформы, поскольку я видел тот SQL. Руками такой не напишешь. Куча промежуточных таблиц. Естественно, всё это не очень индексируется. Но работает и выдаёт результаты.
Кстати, сейчас на Украине идёт проект, в котором используется этот инструмент. Интересно, что они там намайнят.

Что ещё можно интересного рассказать? Лучше спрашивайте. Так легче.


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

BirkhoffНу data mining в Oracle тоже на стороне СУБД, никуда ничего выкачивать не надо. :)

А я не утверждал обратного :)

BirkhoffА если уж об этом зашла речь, то какие алгоритмы mining поддерживаются?

Довольно много различных статистических методов (descriptive statistics, проверка гипотез и т.д.).
Есть алгоритмы преобразования и подготовки данных.
Есть регрессионный анализ (линейная, логистическая регрессия).
Деревья решений.
Кластеризация.
Affinity Analysis (он же Market Basket Analysis)
Sequence Analysis

Дальше на вскидку не помню. Но осталось не много. Всё основные, пожалуй, перечислил.
Нет нейросетей и генетических алгоритмов. Очевидно, их на SQL труднее реализовать. Да, и продукт сравнительно молодой. Лет 5-6 ему всего.


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

Коллеги,

может Вы свою тему перенесёте в форум по Оракл?
Здесь, на мой взгляд, всё-таки немного другое обсуждение.

Спасибо.

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