Моё меню Общее меню Пользователи Правила форума Все прочитано
Вернуться   uForum.uz > ИКТ и телеком > IT-индустрия > Софт > OpenSource
Знаете ли Вы, что ...
...для каждой темы существует свой раздел. Изучите структуру форума. Если соответствующего раздела нет, то всегда есть раздел "Разное" :)
<< Предыдущий совет - Случайный совет - Следующий совет >>


Ответить

 
Опции темы Опции просмотра
Старый 26.12.2008 13:02   #31  
Аватар для kdima71
Оффлайн
Nihol
тех. специалист
Сообщений: 16
+ 0  2/2
– 0  0/0

Uzbekistan
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Запутали еще больше. Поясните, пожалуйста, свое выражение:
Цитата:
Сообщение от kdima71 Посмотреть сообщение
Да, этот тип репликации может быть сопоставлен c технологией RAC, в части «load balancing and survivability». Вот извлечение из официальной документации на этот счет
Официальная документация кого/чего (варианты Oracle, Postgre)? "Этот тип репликаций" кого/чего (варианты Oracle, Postgre)?
Я был бы еще более признателен, если б могли оставить ссылочку на документ или сделать сюда upload если документ не большой.
Смотрите мой предыдущий пост. Прошу прощения, что немного «запутал» Вас, не уточнив, что речь идет конечно же об Oracle.
Ответить 
Старый 26.12.2008 13:24   #32  
Real ID Group uParty Member
Аватар для Ulugbek Umirbekov
Оффлайн
Сообщений: 2,627
+ 1,941  1,815/885
– 29  25/20

Uzbekistan
Цитата:
Сообщение от Alexander Fadeev Посмотреть сообщение
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Глюки были не только и не столько, связанные с Oracle.
+1. Скорее всего так и было. К этому времени Oracle уже давно прошел путь от пробного проекта до промышленного освоения в США, раз добрался до Узбекистана.

Вместе с тем, мы отошли от темы. Так что с PostgreSQL? Готова она стать сегодня полноценной альтернативой Oracle на поставленных в банках задачах?
Ответ на Ваш вопрос положительный, - при соотвествующей оплате местным специалистам (которые в этом форуме всё же отметились, наряду с продавцами), при правильной постановке задачи => и будет это всё равно существенно дешевле покупки готового по небесным ценам + появятся условия для возникновения СВОИХ наработок в этой области... + и специалистов со временем будет больше, убегать перестанут на более высокие зарплаты в тот же Казахстан или в Россию...
Александр, в который раз вижу от Вас посты с утверждением дешевизны того или иного решения (как минимум в 10 раз). Можете ли дать критерии по которым Вы оценивали стоимость? Почему именно 10 раз, а не 100? От чего отталкивались при расчетах? Учитывались ли такие вещи как совокупная стоимость владения, возврат инвестиций и т.п.? Дайте выкладки. Они у Вас судя по всему есть, раз уж считали.

Цитата:
специалистов со временем будет больше
В течении какого периода времени их станет больше и насколько?

Цитата:
убегать перестанут на более высокие зарплаты в тот же Казахстан или в Россию
Убегают совсем не из за того что знают Оракл. А от того что считают что их знания оцениваются тут недостаточно высоко. Теперь вопрос, специалисты по PostgreSQL, в той же ситуации что и убежавшие отсюда что будут делать? Так и будут считать себя недооцененными или предполагается, что им условия будут создавать гораздо лучше чем ораклоидам? Если нет, то я не вижу смысла специалистам вкладывать свое время/знания/ресурсы в систему, которая дефакто является гораздо менее распространенной в мире.
Ответить 
"+" от:
Старый 26.12.2008 13:36   #33  
Real ID Group uParty Member VITUS
Аватар для Vitaliy Fioktistov
Оффлайн
FOM Group
руководитель отдела разработки ПО
AKA:Vitus
Сообщений: 3,976
+ 2,659  2,138/1,101
– 123  21/18

UzbekistanОтправить сообщение для Vitaliy Fioktistov с помощью ICQОтправить сообщение для Vitaliy Fioktistov с помощью Skype™LiveJournalМой мирFacebook
Цитата:
Сообщение от Erkin Kuchkarov Посмотреть сообщение
Оффтоп:
Цитата:
Сообщение от shumbola Посмотреть сообщение
P.S. Почему у нас большинство ездять на Нексиях, а не на Мерседесах? :-)
Честно? По статусу не позволено
А по моему некорректно сформулировали: должно, ИМХО, звучать приблизительно так: почему у нас большинство ездят на Нексиях, а не на Боинг-757?
__________________
Почему в конце денег остается еще так много месяца?
Ответить 
Старый 26.12.2008 13:41   #34  
Open ID Group uParty Member
Аватар для Leonid Khrisanfov
Оффлайн
Asia Systems
Инженер
Сообщений: 639
+ 274  281/165
– 0  0/0

Uzbekistan
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Synchronous Multimaster Replication
In synchronous multimaster replication, each server can accept write requests, and modified data is transmitted from the original server to every other server before each transaction commits. Heavy write activity can cause excessive locking, leading to poor performance. In fact, write performance is often worse than that of a single server. Read requests can be sent to any server. Some implementations use shared disk to reduce the communication overhead. Synchronous multimaster replication is best for mostly read workloads, though its big advantage is that any server can accept write requests — there is no need to partition workloads between master and slave servers, and because the data changes are sent from one server to another, there is no problem with non-deterministic functions like random().

PostgreSQL does not offer this type of replication, though PostgreSQL two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.
(источник - "PostgreSQL 8.3.5 Documentation", Chapter 25. High Availability, Load Balancing, and Replication).

Вопрос к специалистам в области СУБД: насколько я понимаю, именно упомянутый выше тип репликации (Synchronous Multimaster Replication) может быть сопоставлен с технологией Oracle Real Application Clusters (Oracle RAC)? Верно ли я понимаю, что реализация этого типа репликации возлагается на сторонних разработчиков (в части приложений и промежуточного ПО)?
Я правда не являюсь специалистом в области СУБД, но для меня очевидно, что технология Synchronous Multimaster Replication с RAC не сопоставима.
Да, она удобна в том смысле, что не нужно голову ломать как распределить запросы на запись и чтение между серверами, но "... modified data is transmitted from the original server to every other server before each transaction commits", т.е транзакция на изменение данных не завершится пока не "пройдет" по всем серверам, что вызывает "...Heavy write activity can cause excessive locking, leading to poor performance". Следовательно, Synchronous Multimaster Replication применима только (!) в приложениях с "...mostly read workloads". Для банковской сферы, что касается платежной системы, это, увы, не подходит.
Oracle RAC rules!
__________________
И казалось мне, без моих идей мир не сможет прожить и дня (c)А.Романов/Воскресение
Ответить 
Старый 26.12.2008 14:00   #35  
Open ID Group uParty Member
Аватар для Leonid Khrisanfov
Оффлайн
Asia Systems
Инженер
Сообщений: 639
+ 274  281/165
– 0  0/0

Uzbekistan
А если по теме, то все, более-менее внятные сентенции об альтернативности Postgres и иже с ними к Oracle упираются в сумму денежек. Но это сравнение велосипеда с автомобилем.
Postgres, по функционалу, следует сравнивать, например, с MS SQL Server или MySQL, но никак не с Oracle.
Конечно же есть вопрос рациональности использования чего-либо в применении к чему-либо, но это, согласитесь, совсем другой вопрос, из оперы "из пушки по воробьям или воробьями по слону"
__________________
И казалось мне, без моих идей мир не сможет прожить и дня (c)А.Романов/Воскресение
Ответить 
Реклама и уведомления
Старый 26.12.2008 14:30   #36  
Аватар для kdima71
Оффлайн
Nihol
тех. специалист
Сообщений: 16
+ 0  2/2
– 0  0/0

Uzbekistan
[quote=Leonid Khrisanfov;165708]
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Я правда не являюсь специалистом в области СУБД, но для меня очевидно, что технология Synchronous Multimaster Replication с RAC не сопоставима.
Да, она удобна в том смысле, что не нужно голову ломать как распределить запросы на запись и чтение между серверами, но "... modified data is transmitted from the original server to every other server before each transaction commits", т.е транзакция на изменение данных не завершится пока не "пройдет" по всем серверам, что вызывает "...Heavy write activity can cause excessive locking, leading to poor performance". Следовательно, Synchronous Multimaster Replication применима только (!) в приложениях с "...mostly read workloads". Для банковской сферы, что касается платежной системы, это, увы, не подходит.
Oracle RAC rules!
Конечно нельзя рассматривать эти технологии (RAC и/или SMR) как равноценные или взаимозаменяющие. Только в особых случаях может быть рассмотрен вопрос о возможности использования и применения одной технологии взамен другой и то, только в некоторых ее аспектах.

И СУБД Oracle своим пользователям такую возможность выбора предоставляет....
Ответить 
"+" от:
Старый 26.12.2008 14:33   #37  
Real ID Group uParty Member Ultimate
Аватар для Eldar Fattakhov
Оффлайн
Сообщений: 11,845
+ 1,339  5,806/3,144
– 64  125/105

Uzbekistan
Цитата:
Сообщение от Leonid Khrisanfov Посмотреть сообщение
Synchronous Multimaster Replication применима
Я тоже трактовал свой вопрос, исходя из полного совпадения с Oracle RAC, а из предпосылки сопоставления с технологией Oracle. Поэтому я изначально задавал вопрос о полноценной замене СУБД Oracle средствами других СУБД (в т.ч. PostgreSQL).
__________________
DWBH
Ответить 
Старый 26.12.2008 14:44   #38  
Open ID Group uParty Member
Аватар для Leonid Khrisanfov
Оффлайн
Asia Systems
Инженер
Сообщений: 639
+ 274  281/165
– 0  0/0

Uzbekistan
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Я тоже трактовал свой вопрос, не(?) исходя из полного совпадения с Oracle RAC, а из предпосылки сопоставления с технологией Oracle. Поэтому я изначально задавал вопрос о полноценной замене СУБД Oracle средствами других СУБД (в т.ч. PostgreSQL).
Боюсь, что полноценной замены такой СУБД как Oracle в природе пока не существует. Увы и Ах. Впрочем, я не специалист, могу ошибаться
__________________
И казалось мне, без моих идей мир не сможет прожить и дня (c)А.Романов/Воскресение
Ответить 
Старый 26.12.2008 15:26   #39  
Real ID Group uParty Member Ultimate
Аватар для Eldar Fattakhov
Оффлайн
Сообщений: 11,845
+ 1,339  5,806/3,144
– 64  125/105

Uzbekistan
Цитата:
Сообщение от Leonid Khrisanfov Посмотреть сообщение
не(?)
yes
__________________
DWBH
Ответить 
Старый 27.12.2008 16:20   #40  
Аватар для Vsevolod Usmanov
Оффлайн
MChJ "Fido-Biznes"
Руководитель отдела
Сообщений: 20
+ 3  6/6
– 0  0/0

Uzbekistan
Цитата:
Сообщение от kdima71 Посмотреть сообщение
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Synchronous Multimaster Replication
In synchronous multimaster replication, each server can accept write requests, and modified data is transmitted from the original server to every other server before each transaction commits. Heavy write activity can cause excessive locking, leading to poor performance. In fact, write performance is often worse than that of a single server. Read requests can be sent to any server. Some implementations use shared disk to reduce the communication overhead. Synchronous multimaster replication is best for mostly read workloads, though its big advantage is that any server can accept write requests — there is no need to partition workloads between master and slave servers, and because the data changes are sent from one server to another, there is no problem with non-deterministic functions like random().

PostgreSQL does not offer this type of replication, though PostgreSQL two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware. (источник - "PostgreSQL 8.3.5 Documentation", Chapter 25. High Availability, Load Balancing, and Replication).

Вопрос к специалистам в области СУБД: насколько я понимаю, именно упомянутый выше тип репликации (Synchronous Multimaster Replication) может быть сопоставлен с технологией Oracle Real Application Clusters (Oracle RAC)? Верно ли я понимаю, что реализация этого типа репликации возлагается на сторонних разработчиков (в части приложений и промежуточного ПО)?
1. Да, этот тип репликации может быть сопоставлен c технологией RAC, в части «load balancing and survivability». Вот извлечение из официальной документации на этот счет:

2. Нет, этот тип репликации реализован в ядре самого Сервера Базы Данных. Необходимо только соответствующим образом применять и/или использовать этот механизм.
Решение PostgreSQL Synchronous Multimaster Replication и технология Oracle Real Application Clusters никак не сопоставимы.

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

Технология Oracle Real Application Clusters – это одна база данных и несколько экземпляров (набор процессов Oracle) и т.д.

Согласно документации PostgreSQL, решение Asynchronous Multimaster Replication, сопоставимо в части репликации с решением Oracle Streams(репликация одна из возможностей) и Oracle Advanced Replication (есть возможность синхронной репликации).

В части Synchronous Multimaster Replication документация PostgreSQL между строк говорит, что если вы так неудачно спроектировали приложение, что вам необходима синхронная репликация, то вот вам two-phase commit, который позволит вам реализовать ваши планы. То есть механизм Synchronous Multimaster Replication не реализован. Видимо, разработчики посчитали, что не стоит тратить силы и время на реализацию очень редко используемых вещей (при необходимости two-phase commit вполне хватит).

Для тех, кто интересуется сравнением функциональных возможностей различных баз данных для начала можно посмотреть (некоторые характеристики мне показались спорными) - http://en.wikipedia.org/wiki/Compari...gement_systems.
Если поискать, то можно найти более серьезные аналитические статьи со сравнением возможностей различных баз данных.
Ответить 
Ответить
Опции темы
Опции просмотра




Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Advertisement System V2.5 By Branden
OOO «Единый интегратор UZINFOCOM»


Новые 24 часа Кто на форуме Новички Поиск Кабинет Все прочитано Вверх