|
|
Знаете ли Вы, что ... | |
...нарушения правил форума наказываются. Старайтесь их не нарушать. | |
<< Предыдущий совет - Случайный совет - Следующий совет >> |
Ответить |
|
Опции темы | Опции просмотра |
27.12.2008 17:29 | #41 |
|
Ничего о распределении нагрузки (то о чем шла тут речь) в ссылке я не нашел.
Распределение нагрузки, я так понял, всеж неразрывно связано с репликациями. Объясните тогда, как специалист неучам на пальцах, что еще надо, чтоб при полной взаимной репликации данных между двумя серверами в кластере они могли работать и самостоятельно решать задачи клиентов по вводу и обработке данных (или, что по моему одинаково, распределить нагрузку)? Какие еще технологии/процессы (кроме вами указанной репликации) используются в RAC и что не возможно реализовать при этом в Postgre нативными (родными) средствами (т.е. без сложного программирования)?
__________________
Тот факт, что медуза выжила 650 миллионов лет без мозгов, даёт надежду многим. |
|
Ответить |
27.12.2008 20:12 | #42 | ||||
MChJ "Fido-Biznes"
Руководитель отдела
Сообщений: 20
+ 3
6/6
– 0
0/0
|
Цитата:
Цитата:
Цитата:
Извините, но в моем сообщении нигде не было сказано о том, что в Oracle RAC используются механизмы репликации. Наоборот, было отмечено, что репликация(в терминологии баз данных) и Oracle RAC совершенно разные вещи. |
||||
|
Ответить |
Реклама и уведомления | |
27.12.2008 21:50 | #43 | |
Nihol
тех. специалист
Сообщений: 16
+ 0
2/2
– 0
0/0
|
Цитата:
«Репликация» обеспечивает расспространение (копирование) данных между Базами Данных в распределенной среде. Вы совершенно правы, когда речь заходит о распределении нагрузки (включая, доступность и «выживаемость»), то необходимо в первую очередь «разделить/распределить» данных. RAC обеспечивает «раздел данных» между несколькими Серверами на уровне единственной Базы Данных. А «репликация» обеспечивает «распределение данных» между несколькими Базами Данных. В свою очередь, существует два вида «репликаций», в части режима расспространения данных: синхронная и асинхронная. Так вот, PostgreSQL не обеспечивает, как Вы выразились «нативными» средствами, синхронную репликацию в Multimaster Replication Environment. |
|
|
Ответить |
"+" от:
|
28.12.2008 08:52 | #44 | |
Сообщений: 11,845
+ 1,339
5,806/3,144
– 64
125/105
|
Цитата:
Такое функциональное деление наглядно видно и на других программных продуктах той же Oracle. Например, те же Oracle Applications являются модульным продуктом, позволяющим свободно реализовать горизонтальное масштабирование приложений. В то же время использование Oracle RAC даёт возможность добавлять вычислительные узлы при необходимости, не вызывая потребности в изменении самого приложения.
__________________
DWBH Последний раз редактировалось Eldar Fattakhov; 28.12.2008 в 08:59. |
|
|
Ответить |
"+" от:
|
28.12.2008 20:06 | #45 | |
MChJ "Fido-Biznes"
Руководитель отдела
Сообщений: 20
+ 3
6/6
– 0
0/0
|
Оффтоп: Цитата:
Архитектура Oracle Applications состоит из трех уровней: уровень базы данных(Oracle DB), уровень приложений(Oracle Application Server) и уровень клиента (Java applet или веб-страница). Горизонтальное масштабирование можно реализовать только на уровне приложений, путем добавления новых узлов Oracle Application Server, что никак не связано с модульностью самого приложения Oracle Applications. Горизонтальное масштабирование на уровне базы данных без использования Oracle RAC не реализуется, несмотря на модульность. |
|
|
Ответить |
"+" от:
|
28.12.2008 20:13 | #46 | ||
Сообщений: 11,845
+ 1,339
5,806/3,144
– 64
125/105
|
Цитата:
__________________
DWBH |
||
|
Ответить |
28.12.2008 22:45 | #47 | |||
MChJ "Fido-Biznes"
Руководитель отдела
Сообщений: 20
+ 3
6/6
– 0
0/0
|
Цитата:
Могу добавить, что горизонтальное масштабирование приложений Oracle Applications (и любого другого приложения, связанного с БД) на уровне серверов приложений без горизонтального масштабирования на уровне базы данных во многих ситуациях не позволяет полностью решить проблемы, связанные с производительностью системы. Все запросы, все транзакции выполняет сервер базы данных. Если сервер БД не в состоянии обслужить в единицу времени требуемое количество пользователей, то сколько ни ставь серверов приложений, как не распределяй между ними нагрузку, эффекта от этого не будет. Цитата:
|
|||
|
Ответить |
29.12.2008 11:25 | #48 | |
|
Цитата:
С этой точки зрения, кстати, непонятно почему нужно пользоваться общей дисковой подсистемой. Почему нельзя поставить базу данных RACом без общей дисковой подсистемы? Что-то не то с журналированием?
__________________
Тот факт, что медуза выжила 650 миллионов лет без мозгов, даёт надежду многим. Последний раз редактировалось Nadir Zaitov; 29.12.2008 в 11:39. |
|
|
Ответить |
29.12.2008 11:46 | #49 |
|
Надыр, ничего не понял. Я извиняюсь, но г-н Vsevolod Usmanov очень понятно рассказал (в первую очередь Вам) о разнице между репликацией между stand-alone серверами БД и RAC.
В RAC (как и в других типах кластеризации) все вертится на разделяемом ресурсе и все сервера-узлы кластерной группы обращаются и "работают" над одной и той же БД. При чем тут кэш процессоров, контроллеров, памяти и прочего и проблема репликации данных находящихся на обработке в них? Я не понимаю. Хотя, возможно, я не уловил мысль. (Справка - основная нагрузка для СУБД лежит на считывании данных и последующей обработке результатов запроса чтения, а не на записи... ) |
|
Ответить |
Реклама и уведомления | |
29.12.2008 12:30 | #50 | |
|
Цитата:
Что мы хотим в случае кластеризации с распредлением нагрузки? Мы хотим, чтобы база данных давала одинаковые ответы в один и тот же момент времени при запросе с разных узлов кластера, что и говорит нам, что это одна и та же база данных! Это мое видение вопроса. Если кто-то внес единичные данные через один сервер, то это должно изменить результаты обработки всех серверов. Делать это через подсистему невозможно: другие сервера не будут знать что происходит изменение данных, так как читать данные не спешат - все есть в кеше. Значит есть механизм передачи (например обмен через высокоскоростное соединение) изменений между серверами до записи на дисковую подсистему, обеспечивающая синхронизацию данных в многочисленных кешах. А если есть этот механизм - зачем общая дисковая подсистема? Можно и поотдельности Это мое видение пояснения.
__________________
Тот факт, что медуза выжила 650 миллионов лет без мозгов, даёт надежду многим. |
|
|
Ответить |
|