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

[Erkin Kuchkarov]

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

Не важно - кеш иль что-то другое: для согласования данных между узлами.

Данные в RAC существуют в единственном экземпляре - на разделяемом ресурсе (хранилище SAN или NAS ). Не понимаю почему их нужно "согласовывать".

[Nadir Zaitov]

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

Данные в RAC существуют в единственном экземпляре - на разделяемом ресурсе

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

[Erkin Kuchkarov]

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

[Nadir Zaitov]

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

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

Да, они из кеш одного сервака в узле записываются в БД, да вот как потом БД как меняет кеш другого сервака, чтоб другой сервак отрабатывал уже измененые данные, а не перечитывал всю информацию с ДП, иначе на скорости чтения с ДП теряется весь смысл распрелеления нагрузки БД?

Оффтоп:

Вы издеваетесь или проверяете на стойкость мои нервы?

[Leonid Khrisanfov]

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

Да, они из кеш одного сервака в узле записываются в БД, да вот как потом БД как меняет кеш другого сервака, чтоб другой сервак отрабатывал уже измененые данные, а не перечитывал всю информацию с ДП, иначе на скорости чтения с ДП теряется весь смысл распрелеления нагрузки БД?

Оффтоп:

Вы издеваетесь или проверяете на стойкость мои нервы?

Всё верно. Приблизительно так всё и происходит, кэш-память общая, и название этому тоже имеется - "Cache Fusion" - одна из главных "фишек" RAC.

[Erkin Kuchkarov]

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

Вы издеваетесь или проверяете на стойкость мои нервы?

Да нет, хочу понять почему Вы решили что HBA (Host Bus Adapter) для архитектуры SАN и SAN-switch перед записью данных в отведеный LUN для сервера или группы серверов, держат данные в своем кеше (там и кеша то нет совсем).
Вот не могу от Вас добится где Вы это прочитали.

[Erkin Kuchkarov]

Сообщение от Leonid Khrisanfov

Всё верно. Приблизительно так всё и происходит, кэш-память общая, и название этому тоже имеется - "Cache Fusion" - одна из главных "фишек" RAC.

Кеш чего? процессора?

[Leonid Khrisanfov]

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

Кеш чего? процессора?

Причем здесь кэш процессора? Речь идет о работе с базой данных в параллельном режиме, не так ли?

[Erkin Kuchkarov]

Сообщение от Leonid Khrisanfov

Причем здесь кэш процессора? Речь идет о работе с базой данных в параллельном режиме, не так ли?

Леня... я и сам хотел понять, но вот тут все написано.
Теперь по поводу кеш фьюжн - имеется же ввиду механизм синхронизации распределеного кеша Oracle между узлами RAC (не кеш памятью процессора или контроллера дискового массива). Правильно?

[Leonid Khrisanfov]

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

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

Для горизонтального масштабирования на уровне серверов приложений очень подходит Tuxedo (раньше BEA Systems, а теперь Oracle )
В идеале, сбалансированная по нагрузке и при этом очень надежная архитектура базы данных именно так мне и представляется:
СУБД Oracle с опцией RAC + Несколько серверов приложений в домене Tuxedo