2Константин.
Не знаю разворачивали вы кластерные решения на Терадате, но я что-то сомневаюсь в эффективности автоматического хеширования данных кластерах sharing-nothing. Вы представляете гигабайты курсирующие между нодами согласно хешам? Эффективность ручной сегментации на порядок выше и как правило она уже сделана, нода в федеративных кластерах Microsoft это сервер филиала, значит там и данные филиала (остальное фильтруем).
Основной недостаток кластера Microsoft, что его нельзя "подложить" под работающую систему особенно класса ERP. Систему сразу нужно писать в кластерной архитектуре. Однако для DWH это не проблема, а даже скорее решение.

2Бикхоф. Кластер Oracle не поддерживает Sharing Nothing, т.к. дисковый массив все равно зависим и полного паралеллизма как в Терадате и MS не получить. Кластер sharing-nothing по определению не аварийно устойчивый, это цель - производительность. Но и вы года от него не 30% а 3000%.

2Birkhoff. Просто у Oracle аварийно-усточивый кластер и кластер для создания многосерверного паралеллизма одно и тоже.
У MS и Терадата это не так. Отдельно кластер сверхпараллелизма и отдельно аварийно-усточивый кластер (failover cluster). Можно 2 кластера использовать отдельно, можно не использовать любой на выбор.
Кластер Oracle дает выйгрыш до 30% при переходе от 1й ноды к 3м. Кластер MS дает тут примерно 300%. Однако кластер Oracle можно подложить под SAP R3, а кластер MS нет. Правда по SAP Benchmark лидирует MS SQL и без кластеров.

Автоматическое хэширование даёт несколько преимуществ:
1. Отсутствие перекосов в данных за счёт их равномерного распределения по узлам системы. Если распределение данных, например, производится по филиалам, то перекосы гарантированы, поскольку никогда не будет случая, когда во всех филиалах одинаковое количество данных (если, вы их, конечно, не агрегируете до одной строки). Соответственно, надо ждать результатов ровно столько, сколько обрабатывается самый большой набор данных = узкое место.

Вы меня не убедили. Разрезать на число нод до 10 лучше руками, в конце концов их не 100, ни какой хеш не сможет быть умнее человека.
Потом следует учесть, что в MS AS партиции ложаться слайсами, которые нужно для максимальной производительности задать вручную, соотвественно нужно знать как разрезаны данные по нодам. Можно конечно не задавать и надеяться на автомат, тогда потеряешь 10-15% скорости.

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

Судя по всему вы не запусками MicrosStrategy поверх кластера MS SQL, а зря -он силен. Там тоже будет одно чтение. При создании dview он запоминает в query plan как наложены check на ключах, поэтому полезет в одну ноду.

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

Вы меня не убеждаете. В SQL-серверах есть другой более важный фактор, это нахождение данных читаемых как правило одновременно рядом на диске. Это снижает seek и позволяет выиграть до 40% производительности (ноды). Чтобы этого достичь нужно по таким данным создать кластерный индекс, иными словами выполнить хеширование вручную.

4. Руками ничего не надо делать, данные распределяются автоматически = лёгкость администрирования.

А вот это действительно плюс. Во влияние на производительность, простите не верю. В кластере на 10 серверов всегда можно сделать лучше руками. Представте что такое кластер с сумарной мощностью 40 процессоров и 40 быстрых дисков, все юзется без повторов. Oracle может пойти погулять, там такая система будет в 5-6 раз дороже по металлу.

По поводу прогулок между узлами. Дело в том, что в массивно-параллельной конфигурации для соединения узлов между собой используется специальное устройство - коммутатор BYNET, который соединяет каждый узел с каждым. Общая пропускная способность получается гигантская. Поэтому перераспределение данных на другие узлы не являются проблемой.

Все это конечно здорово, но слегка забыли о транзакционной целостности. Для целостности распределенных транзакций нужен Distributed Trasaction Coordinator, т.е. совсем от центрального узла согласования транзакций не уйти или ... грязное чтений и no warranty. Неужели Терадата работает без координатора транзакций?

Кластер sharing-nothing по определению не аварийно устойчивый, это цель - производительность
Не знаю, как в MS, а в Терадате очень даже устойчивый, поскольку:
1. Существует механизм FALLBACK-таблиц. Грубо говоря, альтернативное распределение таблиц по узлам. При выходе узла из строя ничего с такой таблицей не случится, поскольку есть такой же кусочек таблицы, хранящийся на другом узле.

Согласитесь, тогда это не sharing-nothing, а sharing-"что-то" со всеми накладными расходами на поддержку дубляжа "чего-то". Возможно именно это "что-то" привело к тому, что Терадата полностью вылетела из рейтинга TPC.

2. Существует такое понятие, как "клика" (объединение узлов для автоматического восстановления после сбоя).

На это должен быть значительный накладняк.

3. Для mission critical систем существует режим Dual Mode, когда две системы стоят рядом и полностью дублируют друг друга.
В MS SQL это Failover-кластер, к слову он может быть не только дуальным, но и тетра-кластером.

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

Судя по тому, что вы пишите, для Терадаты это не так. Для поддержания аварийной устойчивости нужен серьезный накладняк. Чистого sharing-nothing в Терадате нет, как MS SQL. Но в MS SQL он тоже почти чистый, т.к. требуется работа только координатора DTC. MS SQL гарантирует не только производительность, но и высокий режим изоляции и надежности распределенных транзакций. Мне распределенный commit важненее, защиты от падения ноды.

Я уже поднял вопрос о "полном" параллелизме в MS. Его там, скорее всего, нет.

У меня сложилось обратное впечатление. Блеснув аварийной усточивостью, вы вскрыли серьезную арихитектурную проблему Терадаты. За все надо платить, в том числе производительностью.

Зачем тогда нужны хинты (которых, кстати, в Терадате нет), как не объяснять не очень продвинутому оптимайзеру, что запрос надо выполнять не как он решит, а как ему скажут?

Согласитесь наличие хинтов, лучше чем их отсутвия. Счастливо Терадате разобраться какой индекс взять на запросе связывающем 20 таблиц с сумарным числом индексов свыше 100 и по 3-4 всеьма схожих составных индекса на некоторых таблицах. В MS SQL я могу поправить оптимайзер, однако это делается весьма редко. Новички же в MS SQL вообще пишут не глядя на оптимизацию. MS SQL вытягивает в связанных запросах таблицы в 200 тыс записей вообще без индексов.

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

Вы вероятно редко сажаете MicroStrategy на MS SQL (или это сделать нельзя? или никто не хочет?), иначе бы вы знали, что особенно MS SQL Ent очень сильно использует параллелизм и без кластера. В Query Plan такие "синие этажерки" появляются. Не заметить - невозможно.

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

Плохой пример, точнее легкий для MS SQL. Он просто откеширует это дело и все. Давайте я вам расскажу как правильно ругать MS SQL. Пользователь 1 читает данные, Пользователь 2 - пишет. Все - задница, если Пользователь 1 не использовал грязное чтение, он блокирует Пользователя 2. Насколько я понимаю в Oracle такой проблемы нет (snapshot). Интересно есть ли snapshot в Терадате?

Нет, не отдельно. Всё вместе. По крайней мере у Терадаты.

Как я отмечал, это совсем не достоинство Терадаты и снижает ее производительность. Вероятно потому и неконкурентна она более в TPC.
Я как админ могу выбирать разные стратегии надежности, например могу сделать ставку на RAID в нодах, могу делать failover-кластер. Это мой выбор, не надо его делать за меня.

Я бы не ставил MS и Терадату рядом - разного класса продукты.
Может Юкон будет попродвинутее в плане поддержки хранилищ.

На мой взгляд MS SQL 2K и так не плох для DWH даже в 100G (хотите сверьтесь с TPC-H). Однако MS SQL и Терадата продукты действительно разного уровня. MS SQL универсальный SQL-сервер на котором днем могут работать сотни готовых приложений от 1С до SAP R3, а ночью может идти обсчет сложнейшего DWH. Лучше наворачивать 1н мощный сервер под MS SQL и Oracle, чем дублировать вложения в Терадату. Потом если используется MOLAP, особо больших требований к MS SQL нет. Это MOLAP будет хранить 7 млрд. фактов как в тестах Unisys. К слову в Cognos грузили только 1 млрд., интересно сколько в MicroStrategy+Терадата?

Удачи! В прочем с интересом бы еще послушал про Терадату.

Согласитесь наличие хинтов, лучше чем их отсутвия.
Не согласен. По двум причинам - хочу тратить время на разработку отчётов и бизнес-логики, а оптимизатор пусть сам разбирается. Второе - BI-тулзы, работающие напрямую с реляционными СУБД (Microstrategy, Business Objects, Cognos и др.) обычно не спсобны генерировать хинты. Соответственно, оптимизатор должен сам уметь разобраться.

Я думаю еще и Юра не согласится с пользой хинтов. Для чистого OLAP'щика это раздражающий фактор. Никой Imputu не сделать DWH так как сделает спец в TSQL, даже с 3х летним опытом. Спец с 5 летним опытом сделает заточенный DWH c использованием хинтов и др. особенностей MS SQL так, что он будет работать в 1,5-2 раза быстрее.

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

Это по-моему вторая серия по Oracle на 200 млн. фактов. Приведите пример SQL-запроса. Чудес на свете не бывает.

К тому же, как правило, Терадата требует меньше индексов, чем другие СУБД. Более того, она не боится фулл-сканов, поскольку они выполняются паралельно (всегда и безусловно).

Это воспринимать как оправдание слабости индексирования Терадаты? Счастливо вам full-сканом найти элемент в измерении на 2 млн. абонентов.

Сажал на DB2/400, Sybase ASE, Терадату, и на MS тоже.
Я слышал, что в Даноне связка Microstrategy на MS. Задайте вопрос, может расскажут как это у них.

К слову любонытно, какие у вас впечатления от производительности этих серверов. Я заметил, что в списке нет Oracle. Любопытно, что у нас MS SQL и Oracle это сервера номер один, затем Sybase и Interbase, все отсальное крайне редко. Под DB2 делали только один раз пока работали на IBM, сервер надо сказать понравился. Но спецов по нему ноль в РФ, потому и не игрок.

Снижает, конечно. За всё нужно платить. Однако, как я уже писал, механизм fallback-таблиц можно и не использовать.
В TPC конкурентна, просто тесты не публикует. Дело в том, что они достаточно искуственны и не совсем соответствют реальным приложениям. "Карта не есть территория" - правильно?

В к слову зря о TPC как о неком формальном тесте. Тест TPC эмулирует не некий академический тест. TPC это модель работы очень крупной торговой компании (ордер, оплата и т.д.). Таким образом, это модель тех самых крупных розничных сетей, где раньше все укладывала Терадата+MicroStrategy. Падение Терадаты ниже пола показывает, причем имеено на задачах целевого сегмента рынка, что универсальные SQL-сервера победили. Терадата вероятно замечательная система, но это уже прошлое.

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

Довольно часто видел. Хорошо сделанное хранилище может обновится за 4-6 часов даже на десятках миллионов записей. Иными словами это можно сделать за ночь. Работа DWH на том же сервере, что и ERP не только дешевле, но и быстрее, т.к. не нужно таскать данные по сети.

И что такое "обсчёт сложнейшего DWH?". По-моему, DWH - это периодическая или он-лайн загрузка плюс постоянный доступ со стороны пользователей и бизнес-приложений. Мне кажется, что совмещение хранилища и оперативной системы на одной платформе - не более, чем маркетинговый лозунг.
Тем не менее универсальные SQL-сервера победили и господствуют во всех сегментах и нишах. Я понял в чем ваши сомнения. При использовании ROLAP как MicroStratery или Discoverer конечно DWH нельзя класть рядом с ERP. Нагрузка велика. Однако при использовани MOLAP как MS AS такого нет. Он подкачался ночью и работает себе, SQL-сервер не трогает. Плюс учтите MOLAP очень мало берет ресурсов при работе (много при ночном процессинге), поэтому даже на одном сервере даже сам MOLAP может жить и не сильно мешать SQL-серверу, просто памяти добавте.

Дальше. Допустим, сделали партишионинг руками. Теперь добавляется новый узел. Что делаем? Останавливаем базу. Выгружаем наши терабайты назад и заново делаем партишионинг руками и грузим данные?
В случае Терадаты запускаем одну команду и ждём пока она сама перераспределит данные с учётом нового узла (опять-таки автоматически и равномерно).

Констатин, я рекомендую вам сделать пилот на кластере MS SQL. Вы будете приятно удивлены многим, в том числе что обычно не нужно ни чего выгружать и перегружать при подключении новой ноды.
Типовое использование кластера MS SQL это привлечение серверов административных подразделений большой компании для работы как кластер под DWH. Замечу, новых серверов под кластер покупать не нужно. Наверное поэтому у нас получился опыт построения крупных географически распределенных кластеров MS SQL в 15-18 нод. Обычно каждый узел отвечает сам за себя, т.е. кладет свои данные в локальный DWH, а вот он уже подхвачен distributed view.
У этой схемы только один недостаток, все ноды действительно должны работать всегда. При использовании интранета через спутник или свою GSM-подсетку или радиосет встает серьезная проблема тайм-аутов между нодами.
В принципе решаемо, но весьма геморойно и далеко от веселой рекламы Microsoft.