andrey_anonymous Константин, спасибо за Ваши комментарии относительно ТераДата.

Пожалуйста. Надеюсь, что они были полезными.


andrey_anonymous Я для себя вынес следующее, поправьте пожалуйста если я где-то неправ:
1) Количество разделов таблицы в ТераДата обязательно кратно количеству узлов, невозможно "вертикально" распределить вычислительные мощности в соответствии с потребностями приложений (например, днем 8 узлов операторам, 2 узла - batch, ночью наоборот).

Если под рзаделами вы понимаете hash buckets (разделы хжш-распределения таблицы), то их для каждой таблицы (включая таблицы системного каталога) ВСЕГДА 65536 (или 65535 точно не помню).
Они делятся между AMPами пропорционально количесту последних в системе.
Таким, образом, каждый AMP хранит и обрабатывает более одного бакета.
Степень параллелизма определяется не количеством бакетов, а количеством AMPов. Каждый узел конфигурируется так, что на нём обычно работает 8-10 AMPов.


Помимо этого, тбалица может иметь PARTITIONED PRIMARY INDEX (то есть, может быть партицированной помимо того, что она распределена по хэшу первичного индекса). Партишионов может быть до 65535 тоже. Этот партишионинг логический, он только определяет порядок логической сортировки записей внутри AMP.
Таким образом каждая таблица может быть логически разделена на 2^9 кусочков (если она достаточно велика для этого).


По поводу "вертикального" деления системы между приложениями - это совсем не нужно. Её можно спокойно разделить горизонтально. То есть, часть системы отдать под загрузку, часть - под отчётность, часть под data mining, часть - под тактические запросы. Причём всё это можно делать динамически. Я считаю, что это гораздо более правильный способ, нежели возиться с определением количества узлов, необходимого приложениям.


andrey_anonymous2) Основными конкурентными преимуществами ТераДата на сегодняшний день являются относительно простой синтаксис DDL, user-friendly вывод explain plan, программно-аппаратный комплекс ByNet, значительное количество реальных инсталляций с десятками и сотями узлов.

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


3) Основными недостатками ТераДата являются длительные простои при переконфигурировании, практическая непригодность для смешанных oltp+dss приложений, непригодность для систем 24х7 ввиду простоя во время резервного копирования (низкий коэффициент готовности). То есть область ее применения ограничена чистым DWH.

Я бы сказал так - наличие простоев, поскольку отсутствует определение "длительного" простоя. Ну, и нужно отметить, что от версии к версии длительность простоев для переконфигурирования сокращается.

По поводу OLTP - всё правильно, для OLTP Терадата никогда не позиционировалась - это специализированная СУБД для хранилищ данных. Однако, если говорить о нагрузке класса сложные DSS запросы + короткие запросы на чтение, то Терадата отлично поддерживает такой смещанный вид нагрузки. Например, систему можно сконфигурировать так, что на фоне тяжёлых аналитических запросов система будет выполнять короткие запросы типа "показать данные по одному конкретному клиенту" с заданным уровнем SLA.

По поводу 24х7 и коэффициента готовности системы. Нужно отметить, что очень многие клиенты Терадата используют её как mission critical систему.
Для обеспечения 24х7 существует такая конфигурация, как dual active - то есть две системы работающие параллельно, которые постоянно синхронизируются друг с другом.
Об этом можно почитать здесь .


andrey_anonymous Еще хотелось бы, если возможно, узнать про возможности системы по обеспечению load balancing и application failover.

А что именно? Я попробую рассказать.

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

nkulikovКонстантин, чем же DB2 сложнее Терадаты?

А где я это написал? Можно процитировать?

nkulikovНа ум приходит только подбор partitioning key. Который у же как года полтора можно выбирать с помощью wisard'a.
Который на основании схемы и workload позволит подкорректировать неправильный выбор

Возможно, для подобного сравнения Вам нужно детально ознакомиться с Терадатой, а мне с DB2 UDB.

Мне сейчас, если честно, немного не до этого. Может быть, коллеги, которые лучше меня DВ2 знают, что-то напишут.

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

Интересно также было бы обсудить возможности Dynamic Workload Management, раз уж вы эту тему затронули.
Какие в ядре DB2 существуют механизмы динамической приоретизации пользовательских сессий? Можно ли динамически изменять выделение ресурсами между сессиями (например, наказать пользователя путём уменьшения количества выделяемых на него ресурсов в единицу времени, если он превысил лимит определённых ресурсов, например ЦП или дисков)? Или для этого нужно пользоваться внешними утилитами (например, утилитами ОС)? И насколько это гибко?
Актуально для больших систем со смешанной нагрузкой и необходимостью обеспечить SLA для определённых коротких запросов на фоне тяжёлых DSS-запросов.

Кстати, а сколько в последней версии DB2 хэш-партишионов можно иметь на таблице? Это к вопросу о перекосах в данных.

А вышеописанный процесс реконфигурирования массивно-параллельной системы (например, добавление новых узлов) как выглядит?

И ещё, вот сравнил два FDR теста TPC-H. Один от DB2, один от Oracle. Увидел, что у Oracle оверхед по дискам 1 к 23, у DB2 - 1 к 11.78.
Как-то многовато, на мой взгляд на Терабайт данных 11 Терабайт сырвх дисков. Про 23 Терабайта - по-моему, очень даже, многовато...

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

Локшин МаркНУ так опять - заранее фиксированное число хэш ключей + негарантированное одно чтение. По сути, применимо только к таблицам с ограниченным с верху числом строк.

Да, похоже на то.

Oracle Enterprise Manager Database Tuning with the Oracle Tuning Pack Release 9.0.1The tables in the hash cluster are primarily static in size so that you can determine the number of rows and amount of space required for the tables in the cluster. If tables in a hash cluster require more space than the initial allocation for the cluster, performance degradation can be substantial because overflow blocks are required.



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