Поскольку из sybase топика нас попросили, выношу обсуждение в отдельный топик.
Давайте поговорим о масштабировании различных СУБД.
Предлагаю рассматривать промышленные СУБД, работающие на кластерах, архитектуры shared nothig (Informix XPS, DB2 EEE, Teradata , MS SQL server) vs shared disks (Oracle RAC, ??? ). Только для начала договоримся, что под масштабируемостью понимается что-то типа "scalability indicates the capability of a system to increase performance under an increased load when resources (typically hardware) are added...A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system." ( http://en.wikipedia.org/wiki/Scalability ) Т.е, говоря по-русски, в каком масштабе изменения в хардвере отражаются на изменении в производительности. Скажем, если добавили второй процессор и производительность (число транзакций в секунду) выросла в 1.99 раза - ай, маладца ! А если выросла только в 1.4 раза - буу, маздай !

Для затравки немного грязи, вылитой на конкурентов :
http://www-306.ibm.com/software/data/highlights/scalecluster.html

DB2 UDB out scales Oracle and Microsoft SQL Server
DB2 Data Management Software


Did you know that Oracle is only certified to scale to 8 nodes and Microsoft SQL Server does not have true clustering support? Here's an interesting quote from Microsoft's SQL Server VP:

"We'll do a ton of work in scalability around data warehouses in Yukon for partitioning your data, but it's all going to be focused on a single machine. It will take longer than that for us to really get the shared-nothing approach." Gordon Mangione, SQL Server Vice-President in eWeek interview Sept. 9, 2002
...
Note that the 1.8x scalability claimed by Oracle has a compounding effect. That is, every time you double the number of nodes you loose 20% of the capacity of the cluster. By the time you get to 8 nodes, you have only about 5 nodes worth of power. Modern SMPs scale much better than RAC is able to achieve across a cluster.


... и немного размышлений от фаната RAC :
http://blogs.sun.com/roller/page/dcb/?anchor=oracle_rac_s_secret

Local SGA memory access latency on an SMP node takes from 100 to 400ns (depending on the type of node). However, if that node is part of a RAC Cluster and it needs to access a memory block on another RAC node's shared SGA (via cache fusion) the latency to retrieve that block will be measured in micro-seconds, often 1000x worse!
...
And when you try to spread this out among even two nodes, you suffer the consequences of 1000x higher latency, and 100x less throughput.
..
So it is no wonder that RAC can run into scaling issues if the data is not highly partitioned, to reduce to a trickle the amount of remote references and cache fusion transfers. TPC-C is an example of a type of benchmark in which the work is split between each node without inter-node interaction. RAC scales wonderfully in that benchmark. The problem is that most ad-hoc databases that customers are attempting to use with RAC involve significant inter-node communications. You can imagine the challenge, even with Infiniband, which still has 1000x higher latency (according to Oracle's tests).
...
Okay... what does all this mean? Well, just that Oracle RAC, as I started out saying, is incredible technology that solves a particularly nasty problem that many customers face. But, you must enter the decision to deploy RAC with full knowledge of the engineering trade offs. RAC can be made to perform well in many environments, given a proper design and data/query partitioning and proper skills training. But in general, if there is appreciable inter-node communications, then you should consider using fewer RAC nodes (eg: 2 or 3), in which each node is larger in size. This keeps memory accesses as local as possible.

Yo!!вы похоже так и не прочли мой пост, попробуте еще раз. главный поинт в нем - scalability никак не связана со скоростью:

Scalability - The ability to scale hardware and software to support larger or smaller volumes of data and more or less users. The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services.

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

то что у db2 udb можно данные размазать на 1000 нод вызывает только удивление, с какой целью ??

1. вы попробуйте проанализировать ваше определение (непонятно, где вы его взяли) - и вам станет ясно, что "to support volumes of data" == "увеличить число транзакций в секунду", а "cost-effective" == "за стоимость второго процессора получаем примерно удвоение производительности". Число юзеров для СУБД вещь нерелевантная - для больших количеств юзеров придумано мультиплексирование.
2. Ухудшение времени реакции с увеличением нагрузки -вещь, вполне достижимая и при немасштабируемой системе :-))).
3. Я не специалист в Oracle, но ваше утверждение "установив oracle RAC у вас система сможет ослуживать гораздо больше пользователей" вызывает у меня подозрения, что вы о RAC знаете еще меньше меня.
4. То, что вы не понимаете, зачем размазывать базу на 1000 нод, меня в моем мнении только укрепляет. Попробуйте помедитировать над понятиями "пропускной канал", "время доступа в локальной памяти vs время доступа к глобальному кэшу", "отказоустойчивость и single point of failure", "фрагментация данных и распараллеливание их обработки".

Yo!!я смотрю вы тут новенький :) тогда убедительная просьба воспользоватся поиском, там всего страниц на 20 флейма, как прочтешь - отвечу, а то рассказывать чем view на partitioned nodes оличается от RAC утомительно.

на счет определения - берем 10К юзеров, я беру лочу все таблицы для одного пользователя и генерю им немерено tps в посути одно-пользовательском режиме. tps немеряно, а маштабируемость нулевая.

а вот "to support volumes of data" даже если на албанский перевести не получется "увеличить число транзакций в секунду" ;)

Во-первых, не надо фамильярничать с человеком, который на форуме на год больше вас.
Во-вторых, приведенный умозрительный пример с одним юзером таки доказывает, что про БД у вас сведения очень... абстрактные. tps для одного юзера будет на порядки меньше, чем для сотни - 1) потому, что выполнение транзакции содержит шаги, которые невозможно распараллелить (установление коннекта, идентификация, синтаксический разбор и оптимизация запроса, отдача результатов, посылка подтверждения) 2) потому, что этапы выполнения транзакции загружают разные подсистемы (сеть, цпу, диск, цпу, сеть) - соответственно, при одном юзере подсистемы будут простаивать.
В-третьих, "to support larger volume of data" и есть "увеличить число транзакций/запросов в секунду". Потому что покупка и установка второго винта для хранения исторических данных, равно как и покупка десятка лент, сотни болванок или тысячи дискет врядли относится к масштабированию.
В-четвертых, TPC benchmark меряется в транзакциях, а не в юзерах, и знаете почему ? Потому что юзер сам по себе нагрузки практически не создает, пока он сидит и ковыряет в носу. О размерах средних транзакций как-то сумели договориться, а о размере носа среднего юзера - ну никак. Вот и меряют в tps, а не в оборотах пальца в носу минуту .

Yo!!да ... предлагаете мерятся списком кастомеров ? мне это не интересно.
RAC работает и в отличии от shared-nothing на реальных OLPT задачах, у реальных кастомеров

Не-оракл кастомеры в таких случаях используют HADR (high-availibility data replication). Работает надежней, поскольку а)нет single point of failure - дисковой подсистемы; б) можно разнести географически; в) второй сервер вполне можно использовать для запросов.
Преимуществом RAC является то, что второй сервер можно использовать для записи, а недостатком - падение производительности обеих серверов при согласовании глобального кэша.

Yo!! vybegallo
Не-оракл кастомеры в таких случаях используют HADR (high-availibility data replication).

да наверно mysql/sybase/mssql кастомеры тоже так поступают, это не фича субд, oarcle8 так через атлантику реплицировала еще в 2003-м.

vybegallo
Работает надежней, поскольку а)нет single point of failure - дисковой подсистемы;

продублируйте дисковую подсистему также как это приходится это делать ibm в shared-nothing и будет счастье.

vybegallo
б) можно разнести географически;

нельзя, OLPT загнется. только как файловер.

vybegallo
в) второй сервер вполне можно использовать для запросов.

ну так только фоспро не умеет, mssql, sybase и оракл все умеют.

преимущество RAC в том что ненадо сразу выкладовать на весь сервер, можно взять 2 ноды и через 2 года добавить еще 2 дешовые ноды, а не брать 32х голового монстра сегодня.

1. HADR это таки фича СУБД, вас дезинформировали. Вы, очевидно, под этим термином понимаете что-то свое. Информикс имел эту фичу в незапамятных девяностых, начиная примерно с 6й версии.
2. насчет "нельзя разнести географически, OLTP загнется" - WalMart-у расскажите. Они, дураки, не знают, целый дублирующий центр в другом штате держат. (осторожно, вкрадчиво) - или вы полагаете, что HADR заключается в пересылке логов по мере их заполнения ?
3. HA позволяет использовать достаточно дешевые дисковые массивы, в то время как RAC, как я понял, весьма требователен к оборудованию. Опять повторю - репликация устойчива к катастрофам, а ваши дублированные массивы накроются одним торнадо.
4. И через четыре года вы упретесь в потолок (RAC сертифицирован для max 8 нод, верно ?) при этом ваши 8 нод будут реально давать производительность 5ти. В то время как процессоров доставить много ума не надо, а производительность в SMP растет практически линейно.

Практический вопрос - у вас сколько кластеров в RAC ?

Yo!!не знаю что такое HRDF, я посчитал что это что то типа этого http://zdnet.ru/?ID=308209
так можно хоть фокспро реплицировать, но какое отношение это имеет к кластерам ? просто ни чем не примечательный стендбай. давайте вернемся к кластерам.

дальше, в SMP я например не умею пихать 8 процов, где 4 дырки, если вы так умеете - научите.

ЗЫ. а сколько у меня должно быть кластеров ? как гондонов как минимум пачка ?
ЗЗЫ. я с кластерами никогда не работал, но года через 2 похоже прийдется разворачивать.

Если вы не знаете, что такое High Availibility Data Replication - то не бросайтесь спорить на эту тему.
Про способы наращивания серверов / обмена серверов с доплатой вам уже рассказали.
Жаль, конечно, что все ваши знания кластеров пока чисто теоретические, а представления об их возможностях почерпнуты из бенчмарков. Хотелось бы поговорить с практиками. Вот, к примеру, что практики пишут в comp.databases.oracle.server :
----
I've done it and the one thing I can tell you is that RAC has what
I call the 'spotlight' effect: It is extremely good at pointing out
very poorly written code. And often with the result that performance
goes down rather than up.
----
bad code is bad code and hurts. But bad code with RAC
is poison.
----
One warning - someone else made the comment that
the manuals say "if is scales on one node it will scale
on RAC". What the manuals actually says is "if it
won't scale on one node it won't scale on RAC".
----
My advice based on my experiences with RAC is never use RAC, if there
is any way how to do the job without it! If you're unable to tune your
single instance database, then on RAC you will not be able to tune it
at all.
----
Here a short general rule of thumb for RAC:

(1) If you need PERFORMANCE - scale vertically (put more cpu's,
memory, etc.) in your database machine.

(2) If you need HIGHAVAILABILITY scale horizontal means - use a cluster.

It is true that if you add cluster nodes instead of scaling vertically -
you will gain some more performance BUT - not as much as scaling
vertically - and at a higher cost (hardware + more administration)
----

В таком вот аксепте

Yo!!2vybegallo
умоляю, не нужно встревать в технический разговор с аргументами на уровне детского сада, петька с соседнего двора имел секс со шлюхой и ему не понравилось и он считает, что дрочить лучше. мне действительно на такое нечего ответить.

У кого что болит...

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

Кстати, петьки из comp.databases.oracle.server подозрительно дружно утверждают, что RAC ведет себя тем лучше, чем сильнее разграничены данные между нодами. Мне это почему-то напоминает эмуляцию архитектуры "shared nothing" , нет ? Или, думаете, врут петьки, не нужно переписывать приложения и перекраивать базы ?

Yo!!2vybegallo

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

Да это я уже понял. Грабель вы еще и издали не видали. Жвль, что действительно специалисты по RAC себя не обнаруживают - хотелось послушать людей от сохи, теоретиков мне и коллеги ЧАЛа больше чем достаточно.