iv_an_ruПавел Новокшоновпропущено...
Система превоначально состоит их N узлов, добавили еще N узлов с диском, стало 2N. Виртульных процессов (AMP) в СУБД стало в 2 раза больше и масло на бутерброде (то бишь данные) размазаны более тонким слоем. При всех прочих равных условиях скорость запросов выросла в 2 раза.Если б всё было так просто.

Все именно так просто, как сказал Павел.

iv_an_ruУдвоив число узлов вы не только уполовинили объём данных на каждом узле, вы ещё уполовинили число клиентов, приходящихся на узел, удвоили общий размер ОЗУ кластера и удвоили cache/disk ratio.

А что по-вашему должно было произойти при увеличении числа узлов при прочих равных, данные и пользователи должны удвиться, а ОЗУ и диски уполовиниться? К чему это вообще было написано?

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

iv_an_ru Тут, кстати, бывает подляна, при полностью автоматическом (= ленивом) подходе к делу. Когда очень большой словарь заполняется большими логически связанными пакетами записей, primary key назначается из последовательности и, соответственно, почти все вставки --- "правофланговые", раскидывать надо по хэшу, не учитывающему сколько-то наименее значащих бит primary key, чтобы улучшить локальность.
Простите, вы проводили исследования алгоритмов вычисления хэшей испоьлзуемых в Терадате?

вспомним молодостьНу, скажем, что оптимизатор в терадате лучше по таким-то причинам.
Или, shared nothing позволяет добиться того-то, а в оракле с shared everything такое в принципе невозможно.

Масштабируемость. Чем больше совместно используемых ресурсов, тем хуже масштабируемость.

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


вспомним молодость1) автоматическое равномерное раскидывание данных по хэшу
- т.е. эдакий страйпинг по разным устройствам?
Есть ли ключевые преемущества перед страйпингом в Оракловом ASM?

Главный недостаток АСМа в том, что он распределяет данные на уровне блоков файлов данных, а не на уровне сегментов данных. Т.о. файла он раскидывает по дискам равномерно, но вот данные конкретных таблиц - это большой вопрос. Четкой методики определить насколько равномерно распределен сегмент конкретной таблицы по физическим дискам к сожалению нет, я пробовал проверять путем поиска соответствия между конкретными экстентами АСМа и блоками данных таблицы используя эту статью , результат показал, что равномерного распределения данных нет. Но конечно возможно, что я что-то не так сделал. Так что если есть какие-то мысли на этот счет - вэлкам. Однако даже по логике расномерного распределения данных на уровне сегмента таблицы АСМ гарантировать не может, т.к. он функционирует совсем на другом слое, а Терадата это именно гарантирует.

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

Про параллелизм Oracle - это отдельная история. Сейчас нет времени расписывать, потом выскажу свои мысли, если будет интересно.

iv_an_ruЭто классическая проблема для _всех_ хранилищ, у которых на все случаи жизни один "HASHROW" и один "HASHBUCKET". Хотите хэш универсальный и равномерный и сохраняющий локальность? Фигушки, выберите любые два из трёх.
Терпят эту проблему ровно по одной причине --- мало шансов, что кто-то из апп-девелоперов сначала сможет для конкретного случая выбрать хэши колонок лучше, чем они сделаны по умолчанию, а потом ещё и более разумную загрузку сделать, чем "универсальный" вариант от вендора. Зато убить производительность сможет легко, а хаять будет вендора, а не себя криворукого.
Терадатовцы себе не враги и приняли совершенно верное решение --- простейший неконфигурируемый интерефейс. Выжали равномерные 32 бита из строки, пережали в 16-битный номер корзинки, чтоб уменьшить размер таблиц поиска основного и резервного AMP по номеру корзинки, и всё. Просто и надёжно, как затвор калаша.
Т.е. на определенных значенияx ключей можно получить сильно неравномерное распределение?

iv_an_ruНаписано к тому, что изменение каждого из этих параметров даёт нелинейный эффект, и было бы удивительно, если бы их произведение случайно дало "ровно в два раза".

Павел написал "при прочих равных". Т.е. не поменялось ничего, а кол-во узлов увеличилось.

iv_an_ruРазве что у вас все данные укладываются в ОЗУ и сеть между узлами никогда-никогда не оказывается узким местом.

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

iv_an_ruТогда я рад за вас и за ваш богатый бюджет. Ну или наоборот, все данные безнадёжно холодные на дисках, процессоры медленные и малочисленные, а сеть не оказывается узким местом просто потому, что древние ящики не в состоянии её нормально загрузить. Тогда у вас черепаха тоже поползёт ровно в два раза быстрее. Но согласитесь --- большинство систем в эти крайности не впадают.
Вы сейчас про Терадату или какую-то абстрактную кластерную СУБД?

iv_an_ruApexТоже самое с сетью, пропускная способность интерконнекта увеличивается пропорционально кол-ву узлов в кластере, поэтому узким местом не является.Ну тогда я вам завидую, у нас клиенты, видимо, победнее будут. Старые 16-портовые 10GbE c неполными матрицами внутри и вертись как хочешь, циски SFS будут когда морально устареют :) А то и вообще 2xGbE на узел.
А я то тут при чем?:) У Терадаты просто своя технология для интерконнекта - BYNET .

Круто. А чего не пиаретесь? Я об этом Виртуозо знаю только потому что вы сказали:)

YURKAСистемы устаревают и поддержка для старых систем заканчивается.И если 4 года назад уже были закуплены 5540, то сейчас с ними уже никакое добавление нод практически нереально.13.10 на них не поставишь, а на 12 версию посаппорт заканчивается в след.году.(ЕМНИП)
Юра, привет. Это Саша из Сберовского проекта, помнишь такого?:)
Тут ты безусловно прав, однако это все равно лучше, чем то, что творит Оракл, у которого Exadata разных поколений в принципе не работают вместе. Достаточно вспомнить как Оракл красиво кинул заказчиков первых версий Database Machine. Терадата хотя бы между соседними поколениями совместимость дает.