НиколайTPC - это правила игры. Да он не оптимален, но дает хоть какое-то представление о системах и БД.

А вот, что, кстате Oracle пишет про тест TPC-C:

автор...Consequently, a TPC-C benchmark implementation is really nothing more than a
number of mostly independent databases running mostly local transactions. By
amassing huge numbers of CPUs in loosely coupled configurations, various
vendors have obtained very large TPC-C numbers. It is difficult to find this kind
of workload in real-world applications – neither the data nor the transactions can
be shoehorned to fit neatly into well-defined partitions.


Видишь, не только Терадата придерживается такого мнения о тестах TPC.


Ну я тоже могу закинуть 10 инсталяций DB2 больше 20ТБ c туевой хучей конкурентных пользователей и запросами такими что 5 терабайт во временном пространсве мало :). Это не показатель.
И там будет и telco и retail, но это опять все маркетинг.

Было бы интересно посмотреть. Не думаю, что всё маркетинг.
Реальные работающие внедрения говорят о чём-то, не так ли?


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

Yo!db2 cluster vs RAC
http://www.oracle.com/technology/products/database/clustering/pdf/RACvDB2.pdf

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

Во-первых:
With only two real parallel database choices to pick from, Oracle9i Real
Application Clusters and IBM’s DB2 Universal Database ESE V8.1, the choice
should be easy.

С точки зрения маркетинга - отлично. Типа "больше никого нету, а сейчас и этих опустим".
Наверное не знали, что бывает Терадата и Informix. IQ тоже параллельный, вроде. В общем, технически выглядит не очень профессионально.


Дальше:
авторShared nothing database systems may use a dual ported disk subsystem so that
each set of disks has physical connectivity to two nodes in the cluster with a
notion of “primary and secondary disk ownership.” Such a configuration protects
against system unavailability due to node failures. It requires two node failures to
render the system unavailable. While this is unlikely to occur, a single node
failure may cause significant performance degradation. This is due to the fact that
the one node (in some n node cluster) is now processing roughly twice the work
that any other node is processing and it is on the critical path for transaction completion.

Думаю, что это не совсем так. Рассуждая по аналогии с Терадатой, в которой узлы можно объединять в клики, которые служат для перераспределения нагрузки в случае падения узла клики, думаю, в DB2 тоже должно быть что-то такое. Если, скажем, в клике 4 узла, то при падении узла, нагрузка на 3 оставшихся узла клики будет равномерно распределена. Где тут twice the work не очень понятно.


Дальше:
A benefit of the shared disk approach is it provides unmatched levels of faulttolerance
with all data remaining accessible even if there is only one surviving
node. If a node in the shared disk cluster fails, the system dynamically redistributes
the workload among all the surviving cluster nodes. This ensures
uninterrupted service and balanced cluster-wide resource utilization.

А если этот shared disk из строя выйдет, то вся система накроется, так что ли?
Объясните, пожалуйста.

Дальше:

авторIn addition to requiring a great deal of
expensive manual intervention, the
partitioned approach creates significant
difficulties in capacity planning,
performance tuning and availability.

А разве в DB2 патишионинг не автоматически выполняется? Это же хэширование, как в Терадате.
Правда, где-то читал, что хэш-бакетов поменьше (вроде бы 4К против 64 у Терадаты), ну, ещё, вроде бы, тэйблспейсы надо руками создавать (в Терадате не надо). Ну, остальное-то, наверное DB2 сам делает? Или нет?

А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?


Дальше:
In summary, shared nothing databases usually require that you manually partition the data for optimal performance.

Это при условии, что весь партишионинг в Терадате выполняется полностью автоматически. Вывод - не надо обобщать. Получается очень непрофессионально.


Кстати, дальше по поводу кэша, про размер которого тут шла дискуссия:
авторOracle uses direct reads and direct writes to disk to avoid cache coherency overhead in DSS applications.

Вот так.



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

А если этот shared disk из строя выйдет, то вся система накроется, так что ли?
Объясните, пожалуйста.

выше в треде это уже обсуждалось. Возьмите любой ящик от Хитачи, EMC , etc - у него полное дублирование всех компонентов. Если не хватает - нужен еще такой же ящик.

Понятно.

>А, вот в Oracle с партишионингом как интересно? Я слышал, что надо сильно колдовать над ним. Есть опыт у кого?

Что вас интересует?


В Терадате чтобы создать базу надо только написать:

CREATE DATABASE mydb
FROM dbc
AS
PERM = 2000000
SPOOL = 5000000
FALLBACK
ACCOUNT= 'ACCTG'
NO AFTER JOURNAL
DUAL BEFORE JOURNAL
DEFAULT JOURNAL TABLE = mydb.journals;

Потом чтобы создать таблицу можно написать:
CREATE TABLE mydb.mytable
(
col1 INTEGER,
col2 .....
)
UNIQUE PRIMARY INDEX( col1);


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

А как это выглядит в Oracle?




>Кстати, дальше по поводу кэша, про размер которого тут шла дискуссия:
автор
Oracle uses direct reads and direct writes to disk to avoid cache coherency overhead in DSS applications.


Я извиняюсь, если ошибся, но по-моему вы не поняли, что речь в предложении выше шла про кэш ОС а не Оракла. Это разные вещи. Пользы от кэша ОС практически нет.


Не очень понимаю, что такое cache coherency тогда. Мне почему-то казалось, что речь идёт о когерентности кэшей инстансов Оракла.
А разве кэш инстансов операционки может быть когерентным. И зачем? Разве ОС нодов знают о существовании друг друга?

Ещё - разве Оракл пользуется вводом-выводом операционки, а не напрямую с дисками работает?


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

onstat
Противоречие получается, мы как-то уже начинали разговор
о партиционировании и я говорил что отсоединяю 20 000 000 от
100 000 000 таблицы за 10 -20 минут, помните?

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


Извините, вылетел ненадолго из дискуссии.
Да, противоречие есть, согласен.
Тут нужно сделать уточнение. Такая штука возможна при использовании PARTITIONED PRIMARY INDEX. Это двухуровневый партишионинг когда один уровень - хэширование, а второй определяется руками (наиболее распространённое применение - партишионинг по датам).
Если используется PPI, то отсоединение партиции - секундное дело.
Если PPI не используется, то партиции недоступны напрямую пользователю и удаление будет происходить в обычнои режиме.
Естественно, что если критерий удаления - первичный индекс, то такое удаление будет происходить тоже достаточно быстро.
Про PPI я уже приводил ссылку выше.

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

Я для себя вижу смысл партиционирования
для того чтобы разделить данные по каким то критериям.
За критерии партиционирования и производительность должен
отвечать ДБА, а продукт
должен предоставить механизмы, а не решать за человека.

Я согласен отчасти. Это вопрос правильной балансировки нагрузки между DBA и машиной. На мой взгляд, выигрывает подход, когда машина выполняет большинство задач автоматически. Вам нужно только сесть за руль, повернуть ключ и нажать педаль газа :) Если педалей очень много, в один прекрасный момент становится вопрос о втором пилоте, ну и так далее. Опять таки, ИМХО.

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


С ваших слов складывается впечатление, что терадата это
просто easy way. Не буду сравнивать, хотя на языке одна извесная
софтверная компания.
:)


В принципе, да. По крайней мере рычагов и кнопочек у неё значительно меньше. Архитектура просто очень хорошая.
Похоже, к сожалению, здесь это не все понимают. Другая известная компания очень хороший маркетинговый отдел имеет :)

Или вы хотите доказать кастомерам, что купив терадату можно экономить
на зарплате ДБА.
При продаже - это на последнем месте. Сейчас продаются решения, а не платформы. А решения у Терадаты есть и довольно хорошие.
Что касается ДБА - действительно Терадату очень легко администрировать.

если флеймить так уж флеймить
Да, но только, если это на пользу. Иначе только время будем зря терять.

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

Константин, хорошим показателем прототы администрования является количество гигабайт на одного DBA???

Даже знаю следующую ссылку, которая последует на мой ответ на этот вопрос :)

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


Кстати обещанный список DB2 инсталяций

Deutche Telecom - 90 ТБ
Sprint Telecom - 86 ТБ
StateFarm Insurance - 72 TB (Marketing)
JP Morgan Chase - 50 TB
StateFarm Insurance - 36 TB (Actuarial)
Bank One - 35 TB (3 DBA)
Kroger - 24 (2 DBA)

Николай, а если не секрет, на каких платформах все эти инсталляции?

Могу еше.

Не сомневаюсь :)
Думаю, что все уже попадали в обморок от рефернсов, которые мы с тобой привели. У меня уже тут пара человек возле офиса тусуются. Жаждут ещё :) Скандируют и трясут транспорантами.
Посмотри, может к тебе тоже уже клиенты выстроились :)


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

2 Павел Новокшонов:

Павел, а сколько у вас администраторов Терадаты на 1 ТБ?

_DogПросто AC Nielsen case: 24ТБ данных цчаты до 12Гб в IQ
Это в 2000 раз что ли? А это не сказка?

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