Поскольку из 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 является то, что второй сервер можно использовать для записи, а недостатком - падение производительности обеих серверов при согласовании глобального кэша.