PostgreSQL: альтернатива Oracle Database и других коммерческих СУБД?

[Nadir Zaitov]

Сообщение от Vsevolod Usmanov

Для тех, кто интересуется сравнением функциональных

Ничего о распределении нагрузки (то о чем шла тут речь) в ссылке я не нашел.

Сообщение от Vsevolod Usmanov

В терминологии баз данных репликация - это процесс копирования (переноса) объектов одной базы данных в одну или несколько других базы данных.

Распределение нагрузки, я так понял, всеж неразрывно связано с репликациями. Объясните тогда, как специалист неучам на пальцах, что еще надо, чтоб при полной взаимной репликации данных между двумя серверами в кластере они могли работать и самостоятельно решать задачи клиентов по вводу и обработке данных (или, что по моему одинаково, распределить нагрузку)? Какие еще технологии/процессы (кроме вами указанной репликации) используются в RAC и что не возможно реализовать при этом в Postgre нативными (родными) средствами (т.е. без сложного программирования)?

[Vsevolod Usmanov]

Сообщение от Nadir Zaitov

Ничего о распределении нагрузки (то о чем шла тут речь) в ссылке я не нашел.

Вы что-то перепутали. В моем посте не шла речь “о распределении нагрузки”, а было высказано мнение в ответ на вопрос-ответ:

Сообщение от kdima71

1. Да, этот тип репликации может быть сопоставлен c технологией RAC, в части «load balancing and survivability»...
2. Нет, этот тип репликации реализован в ядре самого Сервера Базы Данных. Необходимо только соответствующим образом применять и/или использовать этот механизм.

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

Сообщение от Nadir Zaitov

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

Два или больше узлов кластера Oracle не реплицируют данные между собой. Они физически этого не могут делать, так как один кластер Oracle - это одна база данных. Механизм же репликаций предназначен для переноса(копирования) объектов одной базы данных в другие базы данных, а кластер (повторюсь) это - одна база данных.

Сообщение от Nadir Zaitov

Какие еще технологии/процессы (кроме вами указанной репликации) используются в RAC и что не возможно реализовать при этом в Postgre нативными (родными) средствами (т.е. без сложного программирования)?

Извините, но в моем сообщении нигде не было сказано о том, что в Oracle RAC используются механизмы репликации. Наоборот, было отмечено, что репликация(в терминологии баз данных) и Oracle RAC совершенно разные вещи.

[kdima71]

Сообщение от Nadir Zaitov

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

Какие еще технологии/процессы (кроме вами указанной репликации) используются в RAC и что не возможно реализовать при этом в Postgre нативными (родными) средствами (т.е. без сложного программирования)?

В Oracle RAC данные не реплицируются (копируются) между узлами кластера, а разделяются узлами, т.е. обеспечивается одновременный доступ (по «чтению» и по «записи») к одной и той же Базе Данных (RAC Database). В этом и заключается принципиальная разница между технологией Oracle RAC и «репликацией» как таковой.

«Репликация» обеспечивает расспространение (копирование) данных между Базами Данных в распределенной среде.

Вы совершенно правы, когда речь заходит о распределении нагрузки (включая, доступность и «выживаемость»), то необходимо в первую очередь «разделить/распределить» данных.

RAC обеспечивает «раздел данных» между несколькими Серверами на уровне единственной Базы Данных.

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

В свою очередь, существует два вида «репликаций», в части режима расспространения данных: синхронная и асинхронная.

Так вот, PostgreSQL не обеспечивает, как Вы выразились «нативными» средствами, синхронную репликацию в Multimaster Replication Environment.

[Eldar Fattakhov]

Сообщение от Nadir Zaitov

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

Чтобы серверы в кластере могли не только обеспечивать резервирование друг друга, но и выполняли при этом балансировку нагрузки, решений достаточно много (независимо от используемой СУБД). Здесь "самым простым способом" может быть разделение прикладной системы на модули. Таким путем однозначно "приходится" идти при использовании практически всех систем управления базами данных, кроме Oracle с функциональным расширением RAC.

Такое функциональное деление наглядно видно и на других программных продуктах той же Oracle. Например, те же Oracle Applications являются модульным продуктом, позволяющим свободно реализовать горизонтальное масштабирование приложений.

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

[Vsevolod Usmanov]

Оффтоп:

Сообщение от Eldar Fattakhov

Такое функциональное деление наглядно видно и на других программных продуктах той же Oracle. Например, те же Oracle Applications являются модульным продуктом, позволяющим свободно реализовать горизонтальное масштабирование приложений.

Sorry. Но…
Архитектура Oracle Applications состоит из трех уровней: уровень базы данных(Oracle DB), уровень приложений(Oracle Application Server) и уровень клиента (Java applet или веб-страница). Горизонтальное масштабирование можно реализовать только на уровне приложений, путем добавления новых узлов Oracle Application Server, что никак не связано с модульностью самого приложения Oracle Applications.
Горизонтальное масштабирование на уровне базы данных без использования Oracle RAC не реализуется, несмотря на модульность.

[Eldar Fattakhov]

Сообщение от Vsevolod Usmanov

Sorry. Но…
Архитектура Oracle Applications состоит из трех уровней: уровень базы данных(Oracle DB), уровень приложений(Oracle Application Server) и уровень клиента (Java applet или веб-страница). Горизонтальное масштабирование можно реализовать только на уровне приложений, путем добавления новых узлов Oracle Application Server, что никак не связано с модульностью самого приложения Oracle Applications.
Горизонтальное масштабирование на уровне базы данных без использования Oracle RAC не реализуется, несмотря на модульность.

Это - не оффтоп. Я вёл речь именно о горизонтальном масштабировании приложений Oracle Applications, отвечая на вопрос Надира: каким образом серверы решают задачи клиентов. Сервер баз данных в трёхуровневой системе не занимается решением задач клиентов. При этом ничто не мешает осуществить горизонтальное масштабирование и серверов баз данных (просто при этом нужно будет думать о репликациях, целостности данных, использовании одних и тех же справочников и т.п., если не использовать RAC; или "не думать об этом, если RAC используется - тут останется только считать стоимость лицензий и техподдержки).

[Vsevolod Usmanov]

Сообщение от Eldar Fattakhov

Я вёл речь именно о горизонтальном масштабировании приложений Oracle Applications, отвечая на вопрос Надира: каким образом серверы решают задачи клиентов.

В своем посте я хотел отметить, что горизонтальное масштабирование приложений Oracle Applications (с точки зрения реализации и при неиспользовании Oracle RAC) возможно только на уровне серверов приложений и никак не связано с его модульностью. Если не было бы модульности, то горизонтальное масштабирование все равно можно было бы осуществить.
Могу добавить, что горизонтальное масштабирование приложений Oracle Applications (и любого другого приложения, связанного с БД) на уровне серверов приложений без горизонтального масштабирования на уровне базы данных во многих ситуациях не позволяет полностью решить проблемы, связанные с производительностью системы. Все запросы, все транзакции выполняет сервер базы данных. Если сервер БД не в состоянии обслужить в единицу времени требуемое количество пользователей, то сколько ни ставь серверов приложений, как не распределяй между ними нагрузку, эффекта от этого не будет.

Сообщение от Eldar Fattakhov

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

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

[Nadir Zaitov]

Сообщение от kdima71

В Oracle RAC данные не реплицируются (копируются) между узлами кластера, а разделяются узлами, т.е. обеспечивается одновременный доступ (по «чтению» и по «записи») к одной и той же Базе Данных (RAC Database). В этом и заключается принципиальная разница между технологией Oracle RAC и «репликацией» как таковой. «Репликация» обеспечивает расспространение (копирование) данных между Базами Данных в распределенной среде. Вы совершенно правы, когда речь заходит о распределении нагрузки (включая, доступность и «выживаемость»), то необходимо в первую очередь «разделить/распределить» данных. RAC обеспечивает «раздел данных» между несколькими Серверами на уровне единственной Базы Данных.

Я думал, что RAC - это нечто более общее. В любом случае, как я понимаю, проблема распределения нагрузки на базу данных среди группы серверов - это проблема не только того, как получить доступ к данным в дисковой подсистеме паралельно с нескольких узлов, а сделать это корректно. Много различных данных "зависает" на различных этапах работы каждого сервера с ней: часть данных в кеше процессора, часть данных в кеше между процессорами, часть в операционной памяти, часть в обработке сетевого контроллера, часть в одном из контроллеров дисковой подсистемы (если их несколько), часть - уже на диске. То, что вы описали решает вопросы только с физическим диском, а что делать с остальным? Тут то и нужно качественно реплицировать сервера друг с другом о проделанной уже работой по вводу и выводу данных (как я понимаю, могу и ошибаться) ДО отправки данных на дисковую подсистему, иначе процесс совмесной работы с повторным чтением с дисковой подсистемы и отказом от кеш всех уровней займет столетия.

С этой точки зрения, кстати, непонятно почему нужно пользоваться общей дисковой подсистемой. Почему нельзя поставить базу данных RACом без общей дисковой подсистемы? Что-то не то с журналированием?

[Erkin Kuchkarov]

Надыр, ничего не понял. Я извиняюсь, но г-н Vsevolod Usmanov очень понятно рассказал (в первую очередь Вам) о разнице между репликацией между stand-alone серверами БД и RAC.
В RAC (как и в других типах кластеризации) все вертится на разделяемом ресурсе и все сервера-узлы кластерной группы обращаются и "работают" над одной и той же БД. При чем тут кэш процессоров, контроллеров, памяти и прочего и проблема репликации данных находящихся на обработке в них? Я не понимаю. Хотя, возможно, я не уловил мысль. (Справка - основная нагрузка для СУБД лежит на считывании данных и последующей обработке результатов запроса чтения, а не на записи... )

[Nadir Zaitov]

Сообщение от Erkin Kuchkarov

Надир, ничего не понял. Я извиняюсь, но г-н Vsevolod Usmanov очень понятно рассказал (в первую очередь Вам) о разнице между репликацией между stand-alone серверами БД и RAC. В RAC (как и в других типах кластеризации) все вертится на разделяемом ресурсе и все сервера-узлы кластерной группы обращаются и "работают" над одной и той же БД. При чем тут кэш процессоров, контроллеров, памяти и прочего и проблема репликации данных находящихся на обработке в них? Я не понимаю. Хотя, возможно, я не уловил мысль. (Справка - основная нагрузка для СУБД лежит на считывании данных и последующей обработке результатов запроса чтения, а не на записи... )

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

Что мы хотим в случае кластеризации с распредлением нагрузки? Мы хотим, чтобы база данных давала одинаковые ответы в один и тот же момент времени при запросе с разных узлов кластера, что и говорит нам, что это одна и та же база данных! Это мое видение вопроса.

Если кто-то внес единичные данные через один сервер, то это должно изменить результаты обработки всех серверов. Делать это через подсистему невозможно: другие сервера не будут знать что происходит изменение данных, так как читать данные не спешат - все есть в кеше. Значит есть механизм передачи (например обмен через высокоскоростное соединение) изменений между серверами до записи на дисковую подсистему, обеспечивающая синхронизацию данных в многочисленных кешах. А если есть этот механизм - зачем общая дисковая подсистема? Можно и поотдельности Это мое видение пояснения.