Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
 Поговорим о масштабировании  [new]
vybegallo
Guest
Поскольку из 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.
23 авг 05, 22:55    [1811838]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
вы похоже так и не прочли мой пост, попробуте еще раз. главный поинт в нем - 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 у вас система сможет ослуживать гораздо больше пользователей, но среднее время реакции (читай скорость) вполне может уменьшится.
-------

на счет кластеров - у мс кажется есть только failover cluster, поэтому остается только db2... и тут у нас хохма. db2 for os/390 как я понимаю - shared-disk, db2 udb - shared disk.
смотрим SAP SD Parallel Standard Application Benchmark Results
там еще в 2002-ом 4 x AlphaServer ES45 Model 2, 4-way SMP, Alpha EV6.8CB (21264C), 8MB L2C на oracle9 RAC на 40-50% опережает лучший результат db2 os/390 (shared-nothing тут не канает) т.е. документик от ibm немного устарел :)

то что у db2 udb можно данные размазать на 1000 нод вызывает только удивление, с какой целью ??
23 авг 05, 23:43    [1811874]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
У SQL Server 2000 данные можно размазать по нескольким серверам и объединить их через представление. Он это называют - federated cluster.
В Юконе, к сожалению не знаю пока, нет времени заняться.
23 авг 05, 23:56    [1811885]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
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", "фрагментация данных и распараллеливание их обработки".
24 авг 05, 01:09    [1811963]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
я смотрю вы тут новенький :) тогда убедительная просьба воспользоватся поиском, там всего страниц на 20 флейма, как прочтешь - отвечу, а то рассказывать чем view на partitioned nodes оличается от RAC утомительно.

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

а вот "to support volumes of data" даже если на албанский перевести не получется "увеличить число транзакций в секунду" ;)
24 авг 05, 01:34    [1811978]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
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, а не в оборотах пальца в носу минуту .
24 авг 05, 02:50    [1812012]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
c127
Guest
AAron
У SQL Server 2000 данные можно размазать по нескольким серверам и объединить их через представление. Он это называют - federated cluster.
В Юконе, к сожалению не знаю пока, нет времени заняться.


Это не кластер, это все умеют уже лет триста как, мелкософт как обычно намеренно вносит путаницу в терминологию. Кластер это когда приложение не знает что оно размазано. Кластер на уровне ОС - СКЛ сервер не знает, кластер на уровне СКЛ сервера - пользовательское приложение (не путать с клиенской частью) не знает.
24 авг 05, 04:02    [1812022]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
к проблеме RACа (озвученной vybegallo - internode communication & latency) я бы добавил
проблему определения, что одна из нод действительно засбоила, и возможность катастрофических последствий, если через какое-то время она "оживет"

Ну и по поводу необходимости 1000 узлов - уже есть клиенты с более чем 500 узлами (db2 ese)
Технически можно перешагнуть и 1000 рубеж.
24 авг 05, 08:58    [1812177]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
vybegallo

Во-первых, не надо фамильярничать с человеком, который на форуме на год больше вас.

ну у меня это стандартная реакция на людей у которых "подозрения что знаете еще меньше меня" ;)

по второму вопросу - попробуйте не вникать в каждое слово а уловить смысл всей фразы. мой пример элюстрировал что tps в отрыве от кол-ва пользователей ни какой полезной нагрузки не несет, т.е. tps есть, маштабируемости - нет.
дальше - зайдите на tpc.org и откройте любой отчет, вы там найдете и кол-во юзеров и время реакции на каждую подзадачку. Oracle app benchmark просто мериет в юзерах + Response Time.
да и вы похоже путаете скорость (Response Time) с tps
24 авг 05, 10:36    [1812377]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
вот у sap более грамотное определение:

Scalability is the ability of a system to efficiently utilize the available
hardware resources, and to increase the potential throughput by
adding extra hardware.
A scalable system fulfills the following two requirements
􀂄 resource consumption increases linearly with load
􀂄 response time remains stable with increasing load
Scalability can be limited on any level
􀂄 single process
􀂄 single machine
􀂄 cluster / multiple machines

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/events/sdn-meets-labs-walldorf-05/Performance%20and%20Scalability.pdf
24 авг 05, 10:46    [1812410]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
vybegallo - даш мыло, пришлю интересный док по теме
24 авг 05, 12:01    [1812789]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну и как я писал в соседнем треде, есть еще и нагрузка, которую привносит GCS (Global Cache Service) и которая достигает 12% CPU utilization на каждую ноду
Правда, это следствие первой причины - inter-node communication.

Ну и называть sysplex (кластеризация на mainframe) disk share - это уже перебор.
Диски там - одна из малеьких и неприметных фич.
Кстати, sysplex наверное и был могильщиком остальных производителей mainframe (off-topic такой)
24 авг 05, 13:55    [1813377]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
ggv
ну и как я писал в соседнем треде, есть еще и нагрузка, которую привносит GCS (Global Cache Service) и которая достигает 12% CPU utilization на каждую ноду
Правда, это следствие первой причины - inter-node communication.

Ну и называть sysplex (кластеризация на mainframe) disk share - это уже перебор.
Диски там - одна из малеьких и неприметных фич.
Кстати, sysplex наверное и был могильщиком остальных производителей mainframe (off-topic такой)


IBM offers both a shared-nothing (for Unix, Linux, and Windows) and a shared-disk (on the mainframe only) approach. Shared-nothing made sense for the distributed platforms because IBM wanted a portable code base and because IBM doesn't control the underlying operating system and hardware for most of those platforms. Years of joint development between the DB2 and the OS/390 and z/OS operating system software teams and the S/390 and zSeries hardware teams went into making the shared-disk approach, normally the less-scalable option, successful on the mainframe.

(C) Craig S. Mullins is director of DB2 technology
http://www.db2mag.com/db_area/archives/2002/q1/mullins.shtml

объяснять про RAC желания нет - уже с вами обсуждали, а вот про ibmвский shared-nothing есть впрос - допустим большая система, там таблички clients, invoices, orders, как я должен их размазать по 500 нодам, чтоб хоть что-то при этом работало и как вы это свяжете с маштабируемостью (определение у нас есть :) ) ?
24 авг 05, 14:32    [1813582]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
и не смотря на приведенную ссылку, sysplex это гораздо больше, чем совместное использование дисков, вернее это в последнюю очередь совместное использование дисков.
Но точнее токо документация поможет, так как опыта нету - в РФ всего одна инсталляция.

По поводу RAC и не надо ничего пояснять - не работаюшая архитектура на более чем 4 узлах, и проблемно работающая на 4.

По поводу как DPF работать будет - надо спрашивать Deutsche Telekom, Sprint PCS, State Farm Insurance, JPMorganChase и других.
Или читать доку, на худой конец.
Там (в обзоре архитектуры) написано, как размазываются данные, и как "масштабируются" запросы (распаралелливаются), и даже можно вычитать, как распаралеллить мелкий запрос, который ну никак не хочет занимать больше одного CPU, а нам надо чтобы занял.
24 авг 05, 15:19    [1813872]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
да ... предлагаете мерятся списком кастомеров ? мне это не интересно.
RAC работает и в отличии от shared-nothing на реальных OLPT задачах, у реальных кастомеров, где shared-notning тесты SAP SD-paralel ? нешмогли ?
да и поскольку у меня плохо с худыми концами и осоьенно с концами в Deutsche Telekom может все же просветите как размазывание на 50 узлов упомянутых 3х табличек скажется на маштабируемости OLPT системы ?
24 авг 05, 16:00    [1814095]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
на сколько я знаю, shared nothing практически не используется для OLTP, и как раз по причине того, что приложения должны быть заточены под такое окружение - ну то же самое, что мы читали выше о проблемах с RAC and latency
Было официальное высказывание - развитие мощности SMP идет опережающими темпами, и существующие можности систем не могут быть освоены клиентскими OLTP приложениями (косвено и последние TPC-C тесты это подтверждают. Да и не косвено), и особого смысла городить кластер OLTP нет - все равно потеря производительности большая (несмотря на sharing/не-sharing) по сравнению с SMP.
Ну и опять же - ограничение масштабируемости shared disk.

(только не надо затрагивать вопрос стоимости - был бы смысл в построении хотя бы мало узлового RAC'a мало-процессорных дешевых машин если бы не лицензионные отчисления)
24 авг 05, 16:50    [1814382]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
ggv
на сколько я знаю, shared nothing практически не используется для OLTP, и как раз по причине того, что приложения должны быть заточены под такое окружение - ну то же самое, что мы читали выше о проблемах с RAC and latency

да-да :) и я четко представляю почему. НО в отличии от shared nothing у оракла есть тьма реальных тестов/инсталяций RAC для OLPT задач, от SAP до OEBS.

ggv

Было официальное высказывание - развитие мощности SMP идет опережающими темпами, и существующие можности систем не могут быть освоены клиентскими OLTP приложениями (косвено и последние TPC-C тесты это подтверждают.

не знаю что за заявление, но явно не оракловое. но я вижу что 10g RAC с процами на 100Mhz слабее оказался быстрей чем новейший MSSQL2005 на TPC-C.

ggv

особого смысла городить кластер OLTP нет - все равно потеря производительности большая (несмотря на sharing/не-sharing) по сравнению с SMP.

могу свалить тучу саксес стори месных (российских) банков которые объясняли зачем им файловер + балансер в виде RAC понадобился и как им было плохо без него. в связи с "10grid" их тьма, вы читать будете ? :)
24 авг 05, 17:17    [1814511]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну заявление было от IBM - и про их Power , так что MSSQL не в тему.
По поводу failover - есть и лучше решение, чем RAC, и у других, и у самого оаракла.
RAC при сбое ноды дает
1) большое время перераспределения ответсвенности
2) снижение производительности

То есть "два в одном флаконе" (и failover и balancer) чуда не сотворяют.
Так что вполне можно заменять такие чудесные двух-нодовые кластера на один SMP с faiover - снижения производительности не будет (повышение может быть)

Можно также DPF (shared nothing) с OLTP- но приложение надо писать именно с учетом такой работы (не так уж сложно впрочем)

Интересно было бы таки написать такое приложение (адаптировать существующее) и провести замеры. Хм, идея самому понравилась.... Железо/софт есть.... Время надо.

PS вопрос стоимости опять таки опущен
24 авг 05, 17:32    [1814574]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
ggv
ну заявление было от IBM - и про их Power , так что MSSQL не в тему.

дык оно и понятно, кто ж в рекламе признается что мы не можем OLPT на кластере, приходится рассказывать что не нада ...

ggv

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

1. вас ввели в заблуждение, 3-5 секунд я наблюдал на демонстрации + зайдите на оракловую ветку, там куча вопросов на эту тему обсуждалось.
2. практически любой уважаемый производитель в течении дня вам заменят вышедшую из строя ноду и работа на это время не остановится.
3. у shared-nothing еще печальней, нужно или дублировать каждую ноду или с тормозами распихивать избыточные данные по нодам и после получить такую же недостачу в нодах.

ggv

Можно также DPF (shared nothing) с OLTP- но приложение надо писать именно с учетом такой работы (не так уж сложно впрочем)

не видел, не верю.

ЗЫ. в след раз всетаки запощу саксес стори кому и зачем нужен RAC :)
24 авг 05, 17:49    [1814655]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
Ну IBM можно и поверить - в OLTP их SMP делает любые кластера пока. Не вижу оснований для сомнений

По поводу 3-5 секунд - вранье, то есть позвольте усомниться. Время определения Instance failure задается параметром, по умолчанию 15 сек, минимум 6 сек.
Плюс время на все остальное. Но 6 сек - самоубийство DBA. Если нода оживет - кирдык.

Ну а по поводу печальности дублирования каждой ноды для failover - так ничего печального. Каждая 9 после запятой стоит денег, и расходу растут нелинейно. Лицензионно дублирование ноды - одна лицензия, значит расходов только на хард
Но мы ведь не ведем дискуссию о стоимости. А раз так - то ничего печального ни с failover, ни с производительностью.
24 авг 05, 18:11    [1814729]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
особенно порадовало - замена ноды в течении дня.... Вот это действительно печально. Действительно ужасная скорость восстановления.
24 авг 05, 18:12    [1814736]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
я с секундометром не стоял, может и 6 секунд :)
дальше, задержку в несколько секунд почуят только юзера упавшей ноды которые просто будут перекинуты на соседнии ноды, не зависимо оживет упавшая или нет.
если нода оживет, то ничего не случится - с нее все юзера будут всеравно сняты.

на счет лицензий, в oracle standart edition RAC включен бесплатно. никаких дополнительных лицензий не требуется. так что кластер на оракле может леко быть на порядок дешевле SMP решения ibm.
на счет востановления ноды я не вижу большого горя если юзеры обнаружат что одна из 4х нод упала и приложение оставшийся день на 25% работает медленее.
24 авг 05, 18:34    [1814819]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
Database Recovery in ORAC environment
The Database Instance relies on all of these components to implement instance
recovery for failed instances, in addition to handling normal database operations.
When a database instance or a node in the cluster fails, Oracle cluster database
needs to do recovery for the database just as it does for a single instance database.
Since other nodes in the cluster is still providing services to the clients, Oracle
cluster database makes sure the recovery time is as little as possible through
concurrent recovery operations.
The global cache service (GCS) maintains global cache resources status to insure
the consistency of database. If a node fails, it needs to rebuild the global cache
resource information. Recovery cannot start until the GCS finishes rebuilding the
information. Effectively, the whole database is “frozen” during this time. Since the
cache resources for database blocks are distributed among the cluster nodes, the
time needed for rebuilding GCS information is minimized. Only the cache
resources that reside or are mastered by the GCSs on the failed nodes need to be
rebuilt or re-mastered. This phase takes only a few seconds on average.

http://otn.oracle.com/products/oracle9i/pdf/rac_building_ha_rel2.pdf
24 авг 05, 18:56    [1814881]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vygegallo
Guest
Yo!!
ggv
ну и как я писал в соседнем треде, есть еще и нагрузка, которую привносит GCS (Global Cache Service) и которая достигает 12% CPU utilization на каждую ноду
Правда, это следствие первой причины - inter-node communication.

Ну и называть sysplex (кластеризация на mainframe) disk share - это уже перебор.
Диски там - одна из малеьких и неприметных фич.
Кстати, sysplex наверное и был могильщиком остальных производителей mainframe (off-topic такой)


IBM offers both a shared-nothing (for Unix, Linux, and Windows) and a shared-disk (on the mainframe only) approach. Shared-nothing made sense for the distributed platforms because IBM wanted a portable code base and because IBM doesn't control the underlying operating system and hardware for most of those platforms. Years of joint development between the DB2 and the OS/390 and z/OS operating system software teams and the S/390 and zSeries hardware teams went into making the shared-disk approach, normally the less-scalable option, successful on the mainframe.

(C) Craig S. Mullins is director of DB2 technology
http://www.db2mag.com/db_area/archives/2002/q1/mullins.shtml

объяснять про RAC желания нет - уже с вами обсуждали, а вот про ibmвский shared-nothing есть впрос - допустим большая система, там таблички clients, invoices, orders, как я должен их размазать по 500 нодам, чтоб хоть что-то при этом работало и как вы это свяжете с маштабируемостью (определение у нас есть :) ) ?


Моя точка зрения, в том числе на указанную статью :
1. Shared disk архитектура относительно нормально масштабируется при использовании специализированного оборудования (межнодной шины/коммуникатора) - что есть на мэйнфремах и чего нет у Оракла.
2. Пользователи Oracle используют RAC в первую очередь для failover, а не для повышения общей производительности, которая растет совершенно нелинейно с добавлением нодов.
3. MMP архитектура подходит для DSS систем и не подходит для OLTP систем.

2 ggv : мое мыло vybegallo03 эт яху дот ком
24 авг 05, 19:07    [1814898]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
Yo!!
да ... предлагаете мерятся списком кастомеров ? мне это не интересно.
RAC работает и в отличии от shared-nothing на реальных OLPT задачах, у реальных кастомеров


Не-оракл кастомеры в таких случаях используют HADR (high-availibility data replication). Работает надежней, поскольку а)нет single point of failure - дисковой подсистемы; б) можно разнести географически; в) второй сервер вполне можно использовать для запросов.
Преимуществом RAC является то, что второй сервер можно использовать для записи, а недостатком - падение производительности обеих серверов при согласовании глобального кэша.
24 авг 05, 19:12    [1814911]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить