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

[Eldar Fattakhov]

не менее дорогое удовольствие, чем покупать (точнее - не покупать) Oracle...
как минимум в 10 раз дешевле - считали
"Воскликнув" театральное "Не верю!", хочу помочь мне и другим сомневающимся развеять по возможности облака тумана.

Ситуация в финансовом секторе Узбекистана (Центральный банк, коммерческие банки, страховые компании и т.д., и т.п.) характеризуется однозначным превалированием одной единственной СУБД - Oracle Database. Понятно, что в мире существует достаточное количество альтернативных технологий (коммерческих, некоммерческих) - среди них и Microsoft SQL Server, и IBM DB2, и Sun MySQL. Еще одним кандидатом при обсуждении статьи проекта EastLinux была названа СУБД PostgreSQL.

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

Для того, чтобы оценить возможность не просто создания новых прикладных программных продуктов ("с нуля"), а обеспечить, при необходимости, миграцию существующих программных комплексов с коммерческих СУБД, необходимо понять: какова же существующая инфраструктура, которая сможет поддержать местных разработчиков при осуществлении миграции?

Для полноценной поддержки (в данном случае - СУБД PostgreSQL) считаю необходимым наличие следующих компонентов:
1) учебные центры - для подготовки разработчиков в среде СУБД, а также подготовки администраторов СУБД;
2) достаточно широкий круг специалистов (в первую очередь - в стране), вовлеченных в создание, эксплуатацию и поддержку прикладных программных комплексов на основе данной СУБД - для создания определенной конкуренции и возникновения здоровой рыночной ситуации;
3) поддержка со стороны производителей программных и аппаратных средств - для обеспечения оптимальных конфигураций ИТ-инфраструктуры.

Обладает ли кто-нибудь информацией по наличию в Узбекистане вышеуказанных ресурсов? Какие количественные характеристики могут описывать ситуацию с возможностью введения PostgreSQL в состав промышленно эксплуатируемых прикладных программных комплексов как в финансовой сфере, так и в других отраслях "народного хозяйства"?

[Игорь Бронников]

На voydod.uz сейчас используется Postgres, хотя курсы я не заканчивал, хватило документации и гугля в некоторых случаях.
Там нет нечего сложного. Кто захочет - разберется.

Насчет подобного полномасштабного внедрения нужно еще подумать есть ли в этом смысл? Создавать целые учебные центры, круги специалистов, поддержка?
Сколько такой учебный центр подготовит спецов? 50, 100? Кому они потом будут нужны?

[shumbola]

На voydod.uz сейчас используется Postgres, хотя курсы я не заканчивал, хватило документации и гугля в некоторых случаях.
Там нет нечего сложного. Кто захочет - разберется.

Насчет подобного полномасштабного внедрения нужно еще подумать есть ли в этом смысл? Создавать целые учебные центры, круги специалистов, поддержка?
Сколько такой учебный центр подготовит спецов? 50, 100? Кому они потом будут нужны?

Если они у Oracle есть, почему бы не иметь их и PostgreSQL? ;-)

Кто действительно разбирается в своей задаче и знает чего хочет, тот выберет и нужное, будто Oracle или PostgreSQL (или другая СУБД). А кто рассуждает примерно как "Oracle - это круто", и не умеет считать денежки (или умеет но не свои, или просто ворует), то выберет Oracle.

Я думаю, если бы те кто эксплуатируют ту или иную коммерческую СУБД ворованную, начали платить за нее денежки, появилась бы интерес и к другим не коммерческим СУБД, в том числе и к PostgreSQL (которая сама по себе неплохая).

[Eldar Fattakhov]

Насчет подобного полномасштабного внедрения нужно еще подумать есть ли в этом смысл?
Во внедрении любой системы в промышленную эксплуатацию всегда есть смысл! Сколько можно экспериментировать/пилотировать? :)

Тема выросла из обсуждения вопроса: "зачем платить за Oracle, если есть PostreSQL?" Если на сегодняшний день в Узбекистане разработкой и поддержкой систем на основе Oracle занимаются с десяток фирм-разработчиков, в которых трудится не менее пары сотен специалистов (тем или иным образом освоивших технологии Oracle) и если заказчик начнёт задумываться о переходе на более гуманные (в денежном отношении) альтернативные технологии , то он должен понимать и кто сможет оказывать ему соответствующие профессиональные (платные или бесплатные) услуги.

[Alexander Kuznetsov]

Обычно поверх СУБД ставится какая-либо система (CRM, СЭД и т.д.). А у таких систем имеются требования к СУБД. У самой же СУБД имеются определенные требования к железу. ИМХО, этим прежде всего руководствуются организации при выборе СУБД. А не потому, что Oracle или MS SQL круче.

[shumbola]

Если на сегодняшний день в Узбекистане разработкой и поддержкой систем на основе Oracle занимаются с десяток фирм-разработчиков, в которых трудится не менее пары сотен специалистов (тем или иным образом освоивших технологии Oracle)
Я бы хотел услышать какие именно технологии Oracle используются нашими фирмами-разработчиками? Тогда можно говорить об альтернативных технологиях, даже когда они не "более гуманные (в денежном отношении)"

[Erkin Kuchkarov]

Я бы хотел услышать какие именно технологии Oracle используются нашими фирмами-разработчиками? Тогда можно говорить об альтернативных технологиях, даже когда они не "более гуманные (в денежном отношении)"
SPATIAL, OLAP, HPC, MultiBlob...

[Eldar Fattakhov]

этим прежде всего руководствуются организации при выборе СУБД.
Они этим руководствуются при использовании "покупных" решений. У нас в стране доля самописных прикладных программных продуктов (в финансовой сфере, в первую очередь) критично высока.
какие именно технологии Oracle используются нашими фирмами-разработчиками?
Под технологиями Oracle подразумевались и средства разработки от Oracle (Forms и др.), и компоненты СУБД (по-крупному - partitioning, RAC, OLAP, ..., да мало ли их!), и IAS. Речь точно не идет о "готовых" решениях класса BI или о системах мониторинга транзакций Tuxedo и др.

[Игорь Бронников]

Насчет подобного полномасштабного внедрения нужно еще подумать есть ли в этом смысл?
Во внедрении любой системы в промышленную эксплуатацию всегда есть смысл! Сколько можно экспериментировать/пилотировать? :)

Тема выросла из обсуждения вопроса: "зачем платить за Oracle, если есть PostreSQL?" Если на сегодняшний день в Узбекистане разработкой и поддержкой систем на основе Oracle занимаются с десяток фирм-разработчиков, в которых трудится не менее пары сотен специалистов (тем или иным образом освоивших технологии Oracle) и если заказчик начнёт задумываться о переходе на более гуманные (в денежном отношении) альтернативные технологии , то он должен понимать и кто сможет оказывать ему соответствующие профессиональные (платные или бесплатные) услуги.
Я не имел в виду смысл внедрения самого Postgres, речь шла о внедрении инфраструктуры обучения, поддержки и т.п. Меня неправильно поняли.

Контекст моего предложения был таким:

Насчет подобного полномасштабного внедрения нужно еще подумать есть ли в этом смысл? Создавать целые учебные центры, круги специалистов, поддержка?
Сколько такой учебный центр подготовит спецов? 50, 100? Кому они потом будут нужны?


Где тут речь о Postgres? Речь об учебных центрах и поддержке

[Nadir Zaitov]

Я думаю, если бы те кто эксплуатируют ту или иную коммерческую СУБД ворованную, начали платить за нее денежки, появилась бы интерес и к другим не коммерческим СУБД, в том числе и к PostgreSQL (которая сама по себе неплохая). +1. А 14 лет назад, пока все это дело в банковском секторе развивалось на Oracle, пусть на ворованном "юридически не обснованно бесплатном", где был PostgreSQL? Правильно - его еще не было. Сегодня рынок заполнен решениями от Oracle и это еще сохранится какое-то время, пока банки не добирутся до самописного софта на PostgreSQL или не купят нормальный коммерческий софт.
ИМХО, этим прежде всего руководствуются организации при выборе СУБД. Не так все. Руководствуются этим фирмы-разработчики, а это попровимо если вопрос встанет о стоимости их продуктов в будущем. У меня лично есть другие аргументы, почему разработчикам импонирует Oracle, но уже принципы маркетинга и ценообразования, которые в этой теме не уместны.

[Eldar Fattakhov]

Где тут речь о Postgres? Речь об учебных центрах и поддержке
Извиняюсь за недопонимание.

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

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

[shumbola]

+1. А 14 лет назад, пока все это дело в банковском секторе развивалось на Oracle, пусть на ворованном "юридически не обснованно бесплатном", где был PostgreSQL? Правильно - его еще не было. Сегодня рынок заполнен решениями от Oracle и это еще сохранится какое-то время, пока банки не добирутся до самописного софта на PostgreSQL или не купят нормальный коммерческий софт.
Неправильно, посмотрите историю PostgreSQL (http://www.postgresql.org/about/history). Лично я до того как познакомился с Oracle, был уже знаком с PostgreSQL. Когда мне предлагали москвичи копию диска лицензионного Oracle за $50 я отказался и продолжал пользоваться PostgreSQL.
ИМХО, PostgreSQL не полноценная замена Oracle, но если бы у нас начали платить за Oracle, многие бы выбирали в качестве альтернативы PostgreSQL.

P.S. Почему у нас большинство ездять на Нексиях, а не на Мерседесах? :-)

[Erkin Kuchkarov]

P.S. Почему у нас большинство ездять на Нексиях, а не на Мерседесах? :-)
Честно? По статусу не позволено ;)

[Georgick]

Это у меня только сложилось такое впечатление, что в последнее время на многих профильных форумах с новой силой поднимаются темы про альтернативные бесплатные продукты? Финансовый кризис в действии?

Во внедрении любой системы в промышленную эксплуатацию всегда есть смысл! Сколько можно экспериментировать/пилотировать?

Сегодня биллинг Шарка в персональном кабинете как раз напомнил, что использует PosgreSQL в качестве БД (Can't connect to db и т.д)

[Nadir Zaitov]

+1. А 14 лет назад, пока все это дело в банковском секторе развивалось на Oracle, пусть на ворованном "юридически не обснованно бесплатном", где был PostgreSQL? Правильно - его еще не было. Сегодня рынок заполнен решениями от Oracle и это еще сохранится какое-то время, пока банки не добирутся до самописного софта на PostgreSQL или не купят нормальный коммерческий софт.
Неправильно, посмотрите историю PostgreSQL (http://www.postgresql.org/about/history). Лично я до того как познакомился с Oracle, был уже знаком с PostgreSQL. Когда мне предлагали москвичи копию диска лицензионного Oracle за $50 я отказался и продолжал пользоваться PostgreSQL.
ИМХО, PostgreSQL не полноценная замена Oracle, но если бы у нас начали платить за Oracle, многие бы выбирали в качестве альтернативы PostgreSQL.

P.S. Почему у нас большинство ездять на Нексиях, а не на Мерседесах? :-)
Из вашей ссылки:In 1996, Postgres95 departed from academia and started a new life in the open source world when a group of dedicated developers outside of Berkeley saw the promise of the system, and devoted themselves to its continued development. минус 14 лет - это год так 1994-й. Может я не прав, но мне кажется к 1996 году, когда Postgres95 полько родилась из материнского чрева в свободное плавание и ее еще никто серьезно не рассматривал, банковская система Узбекистана уже сформировалась на основе Oracle. Так что не правы Вы.

[Nadir Zaitov]

Это у меня только сложилось такое впечатление, что в последнее время на многих профильных форумах с новой силой поднимаются темы про альтернативные бесплатные продукты? Финансовый кризис в действии? Мы рассматривали бесплатные продукты еще до кризиса. Втянулся в Линукс и демонстрировал начальству 3D-кубик от Compriz еще в прошлом году. Сейчас в период кризиса сижу за ноутбуком и тихо матерюсь на того идиота, который купил в офис ноутбук с Vista Home.

[Akmal Bafoev]

Может я не прав, но мне кажется к 1996 году, когда Postgres95 полько родилась из материнского чрева в свободное плавание и ее еще никто серьезно не рассматривал, банковская система Узбекистана уже сформировалась на основе Oracle.

Поправка - только начиналась формироваться.
Реально это начало работать в 1996 году (я сам принимал активное участие в запуске межбанковской сети, пришлось по стране покататься)

[Nadir Zaitov]

Поправка - только начиналась формироваться. Реально это начало работать в 1996 году (я сам принимал активное участие в запуске межбанковской сети, пришлось по стране покататься) Извините за назойливость. А не о внедрении ли вы говорите? Значит выбор на должность Оракула в банковской системе уже имел место?

[Akmal Bafoev]

Поправка - только начиналась формироваться. Реально это начало работать в 1996 году (я сам принимал активное участие в запуске межбанковской сети, пришлось по стране покататься) Извините за назойливость. А не о внедрении ли вы говорите? Значит выбор на должность Оракула в банковской системе уже имел место?

однозначно)
сам готовил под него сервера))))

но помню сколько тогда глюков было в процессе внедрения, ужас :???:

[Eldar Fattakhov]

помню сколько тогда глюков было в процессе внедрения
Глюки были не только и не столько, связанные с Oracle. Учитывая большой пирог (абсолютно новое для страны железо + AIX/WINDOWS + Oracle + неоптимизированное на тот момент прикладное ПО). Если бы внедряли на одной площадке - вопросов бы не было. А тогда разворачивали по всей стране, несколько компаний-интеграторов, во всех банках, во всех отделениях...

[Nadir Zaitov]

Глюки были не только и не столько, связанные с Oracle. +1. Скорее всего так и было. К этому времени Oracle уже давно прошел путь от пробного проекта до промышленного освоения в США, раз добрался до Узбекистана.

Вместе с тем, мы отошли от темы. Так что с PostgreSQL? Готова она стать сегодня полноценной альтернативой Oracle на поставленных в банках задачах?

[Eldar Fattakhov]

Для информации: использование PostgreSQL, наряду с прочими базами данных, рассматривается в следующих продуктах:

HP System Insight Manager (HP SIM) - модифицированная компанией HP версия СУБД (hpsmdb) может быть использована для обеспечения работы базы данных управляющего сервера (Host Database for Central Management Server), базой данных обеспечивается поддержка до 500 систем и до 5000 событий;
HP Serviceguard for Linux - имеется свободный (free) инструментарий (Application Integration Toolkits) для интеграции приложений, разработанных на PostgreSQL, в кластерные системы под управлением HP Serviceguard;
HP C-Series MDS 9000 Storage Media Encryption (SME) Software - СУБД используется для работы приложения Cisco Fabric Manager.

[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. (источник (http://www.postgresql.org/docs/8.3/static/high-availability.html) - "PostgreSQL 8.3.5 Documentation", Chapter 25. High Availability, Load Balancing, and Replication).

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

[Alexander Fadeev]

(Can't connect to db и т.д)
поверьте, это претензия не к СУБД, а к сисадминам Шарка, там есть ещё что поправлять...

[Alexander Fadeev]

Глюки были не только и не столько, связанные с Oracle. +1. Скорее всего так и было. К этому времени Oracle уже давно прошел путь от пробного проекта до промышленного освоения в США, раз добрался до Узбекистана.

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

[Nadir Zaitov]

убегать перестанут на более высокие зарплаты в тот же Казахстан или в Россию... Как раз наоборот. Убегать начнут, так как появятся :)

[kdima71]

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. (источник (http://www.postgresql.org/docs/8.3/static/high-availability.html) - "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». Вот извлечение из официальной документации на этот счет:

Oracle Real Application Clusters Compared With Replication
The two major areas where you may need to consider whether Advanced Replication or Oracle Real Application Clusters better serves your needs are load balancing and survivability.

Load Balancing: Advanced Replication provides read load balancing over multiple databases, while Oracle Real Application Clusters provides read and write load balancing over multiple instances. Because each write must be performed at each replication site, replication does not offer write load balancing.

Survivability: Replication provides greater survivability protection with regards to natural disasters, power outages, or sabotage, or both because the remaining replication sites may be positioned in a geographically different region. Oracle Real Application Clusters operates on a cluster or other massively parallel system and is located in the same physical environment, and thus cannot protect against the physical problems that replication can protect against.

Interoperability: Advanced Replication can replicate data between different platforms and operating systems that are running Oracle. The instances in an Oracle Real Application Clusters environment must run on the same platform.


2. Нет, этот тип репликации реализован в ядре самого Сервера Базы Данных. Необходимо только соответствующим образом применять и/или использовать этот механизм.

[Nadir Zaitov]

Advanced Replication can replicate data between different platforms and operating systems that are running Oracle. Я не понял, а о чем речь? Advanced Replication это часть Oracle или всеж Postgre?

[kdima71]

Да, так как выше было подчеркнуто, что в СУБД PostgreSQL отсутствует технология Replication, речь идет о СУБД Oracle, поэтому чтобы реализовать Synchronous Multimaster Replication
в среде PostgreSQL, необходимы дополнительные усилия, включая разработку собственного механизма или адаптацию уже разработанных механизмов от сторонних компаний (если такие имеются).

[Nadir Zaitov]

Запутали еще больше. Поясните, пожалуйста, свое выражение:
Да, этот тип репликации может быть сопоставлен c технологией RAC, в части «load balancing and survivability». Вот извлечение из официальной документации на этот счет Официальная документация кого/чего (варианты Oracle, Postgre)? "Этот тип репликаций" кого/чего (варианты Oracle, Postgre)?
Я был бы еще более признателен, если б могли оставить ссылочку на документ или сделать сюда upload если документ не большой.

[kdima71]

Запутали еще больше. Поясните, пожалуйста, свое выражение:
Да, этот тип репликации может быть сопоставлен c технологией RAC, в части «load balancing and survivability». Вот извлечение из официальной документации на этот счет Официальная документация кого/чего (варианты Oracle, Postgre)? "Этот тип репликаций" кого/чего (варианты Oracle, Postgre)?
Я был бы еще более признателен, если б могли оставить ссылочку на документ или сделать сюда upload если документ не большой.

Смотрите мой предыдущий пост. Прошу прощения, что немного «запутал» Вас, не уточнив, что речь идет конечно же об Oracle.

[Ulugbek Umirbekov]

Глюки были не только и не столько, связанные с Oracle. +1. Скорее всего так и было. К этому времени Oracle уже давно прошел путь от пробного проекта до промышленного освоения в США, раз добрался до Узбекистана.

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

Александр, в который раз вижу от Вас посты с утверждением дешевизны того или иного решения (как минимум в 10 раз). Можете ли дать критерии по которым Вы оценивали стоимость? Почему именно 10 раз, а не 100? От чего отталкивались при расчетах? Учитывались ли такие вещи как совокупная стоимость владения, возврат инвестиций и т.п.? Дайте выкладки. Они у Вас судя по всему есть, раз уж считали.

специалистов со временем будет больше

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

убегать перестанут на более высокие зарплаты в тот же Казахстан или в Россию

Убегают совсем не из за того что знают Оракл. А от того что считают что их знания оцениваются тут недостаточно высоко. Теперь вопрос, специалисты по PostgreSQL, в той же ситуации что и убежавшие отсюда что будут делать? Так и будут считать себя недооцененными или предполагается, что им условия будут создавать гораздо лучше чем ораклоидам? Если нет, то я не вижу смысла специалистам вкладывать свое время/знания/ресурсы в систему, которая дефакто является гораздо менее распространенной в мире.

[Vitaliy Fioktistov]

P.S. Почему у нас большинство ездять на Нексиях, а не на Мерседесах? :-)
Честно? По статусу не позволено ;)

А по моему некорректно сформулировали: должно, ИМХО, звучать приблизительно так: почему у нас большинство ездят на Нексиях, а не на Боинг-757?

[Leonid Khrisanfov]

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. (источник (http://www.postgresql.org/docs/8.3/static/high-availability.html) - "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! :)

[Leonid Khrisanfov]

А если по теме, то все, более-менее внятные сентенции об альтернативности Postgres и иже с ними к Oracle упираются в сумму денежек. Но это сравнение велосипеда с автомобилем.
Postgres, по функционалу, следует сравнивать, например, с MS SQL Server или MySQL, но никак не с Oracle.
Конечно же есть вопрос рациональности использования чего-либо в применении к чему-либо, но это, согласитесь, совсем другой вопрос, из оперы "из пушки по воробьям или воробьями по слону" :)

[kdima71]

[quote=Eldar Fattakhov;164258]Я правда не являюсь специалистом в области СУБД, но для меня очевидно, что технология 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 своим пользователям такую возможность выбора предоставляет....

[Eldar Fattakhov]

Synchronous Multimaster Replication применима
Я тоже трактовал свой вопрос, исходя из полного совпадения с Oracle RAC, а из предпосылки сопоставления с технологией Oracle. Поэтому я изначально задавал вопрос о полноценной замене СУБД Oracle средствами других СУБД (в т.ч. PostgreSQL).

[Leonid Khrisanfov]

Я тоже трактовал свой вопрос, не(?) исходя из полного совпадения с Oracle RAC, а из предпосылки сопоставления с технологией Oracle. Поэтому я изначально задавал вопрос о полноценной замене СУБД Oracle средствами других СУБД (в т.ч. PostgreSQL).
Боюсь, что полноценной замены такой СУБД как Oracle в природе пока не существует. Увы и Ах. Впрочем, я не специалист, могу ошибаться :)

[Eldar Fattakhov]

не(?)
yes

[Vsevolod Usmanov]

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. (источник (http://www.postgresql.org/docs/8.3/static/high-availability.html) - "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/Comparison_of_relational_database_management_syste ms.
Если поискать, то можно найти более серьезные аналитические статьи со сравнением возможностей различных баз данных.

[Nadir Zaitov]

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

[Vsevolod Usmanov]

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

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

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

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


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


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

[kdima71]

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

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



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

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

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

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

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

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

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

[Eldar Fattakhov]

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

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

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

[Vsevolod Usmanov]

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

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

[Eldar Fattakhov]

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

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

[Vsevolod Usmanov]

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

Архитектура Oracle Applications состоит из трех уровней: уровень базы данных(Oracle DB), уровень приложений(Oracle Application Server) и уровень клиента (Java applet или веб-страница). Горизонтальное масштабирование можно реализовать только на уровне приложений, путем добавления новых узлов Oracle Application Server, что никак не связано с модульностью самого приложения Oracle Applications.
Я вёл речь именно о горизонтальном масштабировании приложений Oracle Applications, отвечая на вопрос Надира: каким образом серверы решают задачи клиентов.
В своем посте я хотел отметить, что горизонтальное масштабирование приложений Oracle Applications (с точки зрения реализации и при неиспользовании Oracle RAC) возможно только на уровне серверов приложений и никак не связано с его модульностью. Если не было бы модульности, то горизонтальное масштабирование все равно можно было бы осуществить.
Могу добавить, что горизонтальное масштабирование приложений Oracle Applications (и любого другого приложения, связанного с БД) на уровне серверов приложений без горизонтального масштабирования на уровне базы данных во многих ситуациях не позволяет полностью решить проблемы, связанные с производительностью системы. Все запросы, все транзакции выполняет сервер базы данных. Если сервер БД не в состоянии обслужить в единицу времени требуемое количество пользователей, то сколько ни ставь серверов приложений, как не распределяй между ними нагрузку, эффекта от этого не будет.


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

[Nadir Zaitov]

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

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

[Erkin Kuchkarov]

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

[Nadir Zaitov]

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

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

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

[Erkin Kuchkarov]

Если кто-то внес единичные данные через один сервер, то это должно изменить результаты обработки всех серверов. Делать это через подсистему невозможно: другие сервера не будут знать что происходит изменение данных, так как читать данные не спешат - все есть в кеше.
Так, я теперь понял. Раз Вы уверены в том что Вы написали - скажите пожалуйста сколько времени хранятся данные предназначенные для записи в кэшах контроллеров дисковых подсистем? (Потому как уповать на то что узлы кластера берут данные из кеша памяти, процессоров по крайней мере малопрофессионально ;) извините если обидел) Час два три? День два три? ;) Я то не знаю,и хотя очень много работал\работаю с дисковыми подсистемами и различными СУБД, но специальных исследований не проводил. Как то в голову не приходило.

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

Хотя... в "заоблачных" вычислениях Вами предложенное как раз и используется... как я понял :)

[Nadir Zaitov]

Раз Вы уверены в том что Вы написали - скажите пожалуйста сколько времени хранятся данные предназначенные для записи в кэшах контроллеров дисковых подсистем? (Потому как уповать на то что узлы кластера берут данные из кеша памяти, процессоров по крайней мере малопрофессионально извините если обидел) Час два три? День два три? Я то не знаю,и хотя очень много работал\работаю с дисковыми подсистемами и различными СУБД, но специальных исследований не проводил. Как то в голову не приходило. Не обидели. Все эти уровни кеш (а я понимаю, их еще больше) описывались для того, чтобы сказать, что каждый узел базы данных (физический сервер) изменив данные должен об этом сообщить другому узлу. Сообщать это через дисковую подсистему - наверное не правильно и это мое мнение непрофессионала.

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

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

[Nadir Zaitov]

И заметьте - нет риска получить несинхронизированную копию БД... потому что экземпляр БД один. Давайте по полкам все расставим.

Я процесс чтения данных в базе данных (в силу ограничений в умственных способностях упуская подробности управления памятью, дисками и т.п.) вижу в следующем виде:
Процессор за данными лезит:
В первую очередь, в собственный регистр, если "знает", что нужные данные в нем есть; если их там нет, то:
Лезит в L1 кеш - вдруг они есть тама; если их там нет, то:
Лезит в L2 кеш - вдруг они там есть; ; если их и там нет, то:
Лезит в L3 кеш - вдруг этот кеш имеется и данные там есть; если их и там нет, то:
Лезит в оперативную память, где они должны быть в кеше..., ; если блин там их тоже нет, то:
Идет в дисковую подсистему, а она говорит с нами через свой кеш, в котором данных этих точно нет (обычно и не бывает, так как этот кеш мааасенький в сравнении с оперативной памятью, хотя не всегда), то попадаем в область доступа к дискам.

И вот если мы где-то по дороге данные, нас интересующие нашли, то приходится апгрейдить все вышестоящие кеш-памяти. Ясно, что если чтения с дисковой подсистемы не происходит, то и кеш в оперативке держится нереально долго, как говорят экономисты "при прочих равных условиях".

Если б сервера синхронизировались только через дисковую подсистему, то все данные нужно было бы читать всегда только с диска или имелась бы ситуация типа "splited brain", когда каждый сервер располагает разными данными и живет обособленно, хотя и имеют вместе общую базу данных без риска получить несинхронизированные данные, так как это уже произошло :)

[Erkin Kuchkarov]

Все эти уровни кеш (а я понимаю, их еще больше) описывались для того, чтобы сказать, что каждый узел базы данных (физический сервер) изменив данные должен об этом сообщить другому узлу. Сообщать это через дисковую подсистему - наверное не правильно и это мое мнение непрофессионала.
Никто ничего не сообщает другому узлу при изменении данных и записей в БД. Незачем.
Теперь по поводу кешей (кешью надо купить к новому году на салат... жена прибьет... спасибо что напомнили... ) - возможность извлекать из кеша дисковой подсистемы - есть реализация отличительных особенностей "того или иного" оборудования, "того или иного" производителя, но... производитель оборудования гарантирует в этом случае идентичность записей БД на дисковой подсистеме для всех узлов высокопроизводительного кластера.
Никакие "дополнительные" функциональные возможности самого СУБД в этом случае не задействуются.
То, что кластер видится как один логический сервер - я могу понять, однако работу может получить любой (а, не каждый - не все) из узлов - физических серверов со своими процессорами, кеш, экземпляром операционки, кодом Oracle, куском данных и тут вы не передергивайте, как профессионал.
Работу получает любой незагруженый (до определенного порогового значения) экземпляр узла кластера. При чем тут ОС и кусок Oracle?
Касаемо сроков хранения данных в кеш. Если бы мы говорили об одном сервере отдельно (в кластере там уж точно не так), то в кеш данные хранятся столько, сколько они остаются актуальными и востребованными. Это может быть и годы, если нет потребности обновляться.
Кеш - не есть место хранения данных а "фича" позволяющая ускорить количественный показатель чтения\записи (ЫОПС).

[Erkin Kuchkarov]

Давайте по полкам все расставим.
По дисковым? ;)
Процессор за данными лезит:
Какой процессор, извините, и куда лезет? (я себе могу представить процессор куда то лезущий за данными из БД в единственом варианте - это текстовый процессор и возможностями автоматизации... хотя бы на уровне скриптов), но меня смущают уровни L1, L2 и L3.... ;)
Надо бы пораспрашивать Мурада Ибрагимова... может что и изменилось в фоннеймановской архитектуре ЭВМ.... ну это так - мысли вслух
В обход операционной системы (в современных СУБД) никто никуда не лезет.

[Erkin Kuchkarov]

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

[Nadir Zaitov]

По дисковым? Мы говорим о разных вещах. Для меня кеш - это кусок памяти любого где угодно (внутри процессора, перед процессором, в оперативке под контролем СУБД, в оперативке под контролем ОС, в контроллере дисковой подсистемы, у самого физического диска - мне по барабану, главное, что этот кусок памяти хранит информацию исходя из последних насущных потребностей вышестоящего уровня в реальном ЭВМ. И мне все по баробану, как Фон Нейман представлял ЭВМ в далеком начале 20 века...

[Nadir Zaitov]

Обращение к модераторам: Похоже мы немного оторвались от темы... давайте перенесем обсуждаемые вопросы в какой нибудь раздел прямо относящийся к кластеризации, дисковым подсистемам и оракле? Мы все еще в теме работы Oracle RAC как основного преимущества Oracle над PostgreSQL. Его и обсуждаем :)

[Erkin Kuchkarov]

Мда, слов из песни не выкинешь. ;)
...барабан был плох, барабанщик сдох...

Я тоже прекрасно знаю про кеш, однако я не понимаю при чем тут кеш применительно в кластерах высокой производительности организованной по технологии Oracle RAC?

[Nadir Zaitov]

Я тоже прекрасно знаю про кеш, однако я не понимаю при чем тут кеш применительно в кластерах высокой производительности организованной по технологии Oracle RAC? Не важно - кеш иль что-то другое: для согласования данных между узлами.

[Erkin Kuchkarov]

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

[Nadir Zaitov]

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

[Erkin Kuchkarov]

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

[Nadir Zaitov]

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

[Leonid Khrisanfov]

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

[Erkin Kuchkarov]

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

[Erkin Kuchkarov]

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

[Leonid Khrisanfov]

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

[Erkin Kuchkarov]

Причем здесь кэш процессора? Речь идет о работе с базой данных в параллельном режиме, не так ли?
Леня... я и сам хотел понять, но вот тут (http://www.uforum.uz/showthread.php?p=166241#post166241) все написано.
Теперь по поводу кеш фьюжн - имеется же ввиду механизм синхронизации распределеного кеша Oracle между узлами RAC (не кеш памятью процессора или контроллера дискового массива). Правильно? ;)

[Leonid Khrisanfov]

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

Sorry. Но…
Архитектура Oracle Applications состоит из трех уровней: уровень базы данных(Oracle DB), уровень приложений(Oracle Application Server) и уровень клиента (Java applet или веб-страница). Горизонтальное масштабирование можно реализовать только на уровне приложений, путем добавления новых узлов Oracle Application Server, что никак не связано с модульностью самого приложения Oracle Applications.
Горизонтальное масштабирование на уровне базы данных без использования Oracle RAC не реализуется, несмотря на модульность.
Это - не оффтоп. Я вёл речь именно о горизонтальном масштабировании приложений Oracle Applications, отвечая на вопрос Надира: каким образом серверы решают задачи клиентов. Сервер баз данных в трёхуровневой системе не занимается решением задач клиентов. :) При этом ничто не мешает осуществить горизонтальное масштабирование и серверов баз данных (просто при этом нужно будет думать о репликациях, целостности данных, использовании одних и тех же справочников и т.п., если не использовать RAC; или "не думать об этом, если RAC используется - тут останется только считать стоимость лицензий и техподдержки).
Для горизонтального масштабирования на уровне серверов приложений очень подходит Tuxedo (раньше BEA Systems, а теперь Oracle :) )
В идеале, сбалансированная по нагрузке и при этом очень надежная архитектура базы данных именно так мне и представляется:
СУБД Oracle с опцией RAC + Несколько серверов приложений в домене Tuxedo

[Leonid Khrisanfov]

Причем здесь кэш процессора? Речь идет о работе с базой данных в параллельном режиме, не так ли?
Леня... я и сам хотел понять, но вот тут (http://www.uforum.uz/showthread.php?p=166241#post166241) все написано.
Теперь по поводу кеш фьюжн - имеется же ввиду механизм синхронизации распределеного кеша Oracle между узлами RAC (не кеш памятью процессора или контроллера дискового массива). Правильно? ;)
Совершенно верно, "шелезячные" кэш-памяти здесь ни причем.

[Leonid Khrisanfov]

Обращение к модераторам: Похоже мы немного оторвались от темы... давайте перенесем обсуждаемые вопросы в какой нибудь раздел прямо относящийся к кластеризации, дисковым подсистемам и оракле? Мы все еще в теме работы Oracle RAC как основного преимущества Oracle над PostgreSQL. Его и обсуждаем :)
Поверьте, Оракулу, чтобы заткнуть за пояс Постгреса, не нужно вытаскивать из рукава Раков :)

[Nadir Zaitov]

Да нет, хочу понять почему Вы решили что HBA (Host Bus Adapter) для архитектуры SАN и SAN-switch перед записью данных в отведеный LUN для сервера или группы серверов, держат данные в своем кеше (там и кеша то нет совсем). Теперь по поводу кеш фьюжн - имеется же ввиду механизм синхронизации распределеного кеша Oracle между узлами RAC (не кеш памятью процессора или контроллера дискового массива). Правильно? Вот видите - сами все знаете, что речь идет только на уровне оперативной памяти (RAM по вашему), а меня с кешем контроллера и процессора дурачите. Я ведь вам сказал лишь то, что есть много уровней, на котором нужно синхронизировать. Если Oracle отрезал все на уровне операционной памяти, то уже все понятно, так как дальше (синхронизация кешей процессора) - дело операционки или архитектуры процессора и материнской платы, как я понимаю.

[Leonid Khrisanfov]

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

[Erkin Kuchkarov]

Вот видите - сами все знаете, что речь идет только на уровне оперативной памяти (RAM по вашему)
Какая еще оперативка (RAM по нашему)?
Ладно... все. Пусть будет по Вашему, Надыр.

[Erkin Kuchkarov]

Поподробней, пожалуйста, о "синхронизации кэшей процессоров"...
Леня, хватит :))))) Давай лучше пригласим спеца по постгри - Рустама Хамидова.:)

[Nadir Zaitov]

Поверьте, Оракулу, чтобы заткнуть за пояс Постгреса, не нужно вытаскивать из рукава Раков Так и выскажитесь об этом в фактах. Где они? Кроме опозданий на выход в корпоративный мир, пока других "проблем" с PostgreSQL здесь никто не озвучил. Есть сомнение, что аналог RAC тут сделать невозможно.

[Nadir Zaitov]

Поподробней, пожалуйста, о "синхронизации кэшей процессоров"... Как работает кэш процессора при смене данных в оперативной памяти другими устройствами/процессорами я не знаю, но могу поискать. Это обсуждалось в другой теме тут на форуме. Обсуждение началось здесь (http://www.uforum.uz/showthread.php?p=147835#post147835) благодаря вам же, однако Вы тогда самоликвидировались :). Продолжилась она правда уже здесь (http://www.uforum.uz/showthread.php?p=148016#post148016).

[Leonid Khrisanfov]

Поверьте, Оракулу, чтобы заткнуть за пояс Постгреса, не нужно вытаскивать из рукава Раков Так и выскажитесь об этом в фактах. Где они? Кроме опозданий на выход в корпоративный мир, пока других "проблем" с PostgreSQL здесь никто не озвучил. Есть сомнение, что аналог RAC тут сделать невозможно.
Да и нет желания копаться в проблемах с PostgreSQL. Нормальная СУБД, для своих задач. Только сравнивать её нужно с подобными ей. Как говорится: "Цезарю - цезарево, а слесарю - слесарево" :)
А аналога Oracle RAC - нету. Всякие там "репликации" и иже с ними - вообще из другой оперы.

[Eldar Fattakhov]

аналога Oracle RAC - нету
Явного аналога в PostgreSQL точно нет. Это - однозначно.

[Nadir Zaitov]

Только сравнивать её нужно с подобными ей. Что еще Оракула отличает от простых смертных других СУБД, например, от послеГре кроме этого (RAC):Явного аналога в PostgreSQL точно нет. Это - однозначно. Дайте ясное понятие.

[Eldar Fattakhov]

Дайте ясное понятие
Долго пытался выудить от кого-либо из специалистов по системам управления базами данных ясные и четкие (практические, не маркетинговые) заключения. Без какого-либо ощутимого результата. Поэтому остановлюсь на "маркетинговой" постановке вопроса: реальных аналогий технологическому решению Oracle Real Application Clusters (Oracle RAC) нет не только в PostgreSQL, но и в любой другой СУБД (попадавшейся мне в поле зрения в качестве потенциального кандидата на СУБД промышленной корпоративной информационной системы).

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

[Erkin Kuchkarov]

в любой другой СУБД
У любых других есть другие методы :)

[Eldar Fattakhov]

в любой другой СУБД
У любых других есть другие методы :)Совершенно согласен! :) Но другие. Я не о том веду речь, что ничего нет лучше Oracle (с её RAC). Вопрос только в готовности разработчиков прикладных комплексов и системных интеграторов реализовывать те или иные методы обеспечения доступности и отказоустойчивости прикладных комплексов, а также (при необходимости) балансировку приложений между узлами кластеров. На другой чаше весов - готовность заказчика платить за одни механизмы, или за другие (включая все составные части - обучение, сопровождение, развитие и т.п.)...

[Nadir Zaitov]

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

[Eldar Fattakhov]

Вместе с тем, я что-то не вижу других преимуществ Oracle....
Их много. В том числе - в продвинутых средствах бизнес-аналитики (даже на уровне самой СУБД, в виде дополнений к версии Enterprise). Нужно учиться всем - и разработчикам в первую очередь.

[Erkin Kuchkarov]

я что-то не вижу других преимуществ Oracle....
Ну скажем возможность хранить в одном BLOB поле несколько "сложных" объектов. Для начала

[Eldar Fattakhov]

приходит идея не рости уже в ширь, а только ввысь -стройнее будешь
Кошелёк тоже будет стройнеть. :) Отгрузим midrange или hi-end серверы с огромным удовольствием!

[Vsevolod Usmanov]

По дисковым? Мы говорим о разных вещах. Для меня кеш - это кусок памяти любого где угодно (внутри процессора, перед процессором, в оперативке под контролем СУБД, в оперативке под контролем ОС, в контроллере дисковой подсистемы, у самого физического диска - мне по барабану, главное, что этот кусок памяти хранит информацию исходя из последних насущных потребностей вышестоящего уровня в реальном ЭВМ. И мне все по баробану, как Фон Нейман представлял ЭВМ в далеком начале 20 века...
Данные для записи не хранятся в кеше (-ах). Они каким то чудесным образом модифицируют хранимые данные в БД. Иначе никто бы этим не пользовался - не было бы гарантий изменения данных в БД. И всякие там хьюлеты и паккарды, фуджики и сименсы совместно с емсями или нетапами не продавали бы хранилища централизованные и бедное циско не выступало бы в противовес брокейдам со своими сан свитчами... могу ошибатся
Да, они из кеш одного сервака в узле записываются в БД, да вот как потом БД как меняет кеш другого сервака, чтоб другой сервак отрабатывал уже измененые данные, а не перечитывал всю информацию с ДП, иначе на скорости чтения с ДП теряется весь смысл распрелеления нагрузки БД? Вы издеваетесь или проверяете на стойкость мои нервы? Всё верно. Приблизительно так всё и происходит, кэш-память общая, и название этому тоже имеется - "Cache Fusion" - одна из главных "фишек" RAC.

По поводу Cache Fusion, "кешей" различного рода и их синхронизации... Тоже самое кратко изложил в своих постах ранее г-н Erkin Kuchkarov, но, как мне показалось был не понят.

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

Oracle RAC состоит из нескольких узлов серверов базы данных. Каждый узел имеет набор своих процессов и свою структуру памяти – в том числе и буферный кэш.

Далее вырезка из документации Oracle (Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide).

Oracle RAC databases have two or more database instances that each contain memory structures and background processes. An Oracle RAC database has the same processes and memory structures as a single-instance Oracle database as well as additional process and memory structures that are specific to Oracle RAC. Any one instance's database view is nearly identical to any other instance's view within the same Oracle RAC database; the view is a single system image of the environment.
Each instance has a buffer cache in its System Global Area (SGA). Using Cache Fusion, Oracle RAC environments logically combine each instance's buffer cache to enable the instances to process data as if the data resided on a logically combined, single cache.
To ensure that each Oracle RAC database instance obtains the block that it needs to satisfy a query or transaction, Oracle RAC instances use two processes, the Global Cache Service (GCS) and the Global Enqueue Service (GES). The GCS and GES maintain records of the statuses of each data file and each cached block using a Global Resource Directory (GRD). The GRD contents are distributed across all of the active instances, which effectively increases the size of the System Global Area for an Oracle RAC instance.
After one instance caches data, any other instance within the same cluster database can acquire a block image from another instance in the same database faster than by reading the block from disk. Therefore, Cache Fusion moves current blocks between instances rather than re-reading the blocks from disk. When a consistent block is needed or a changed block is required on another instance, Cache Fusion transfers the block image directly between the affected instances. Oracle RAC uses the private interconnect for inter-instance communication and block transfers. The Global Enqueue Service Monitor and the Instance Enqueue Process manages access to Cache Fusion resources as well as enqueue recovery processing.

[kdima71]

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

Сравнивать ту или иную СУБД это не благодарный труд.

В Сети существует куча материала на это счет. И эта тема ни к чему как правило не приводит.

Специалисты Oracle остануться на своем, специалисты DB2 скажут что Oracle со своей версионностью достал уже всех. Oracle возразит и скажет, а у Вас в DB2 «читатель ждет писателя» по умолчанию, если не использовать уровень изоляции «чтение грязных данных», на что DB2 скажет, Вы со своими «сегментами отката» порождаете огромное количество redo информации. Или, у нас есть RAC, а у Вас что? А у нас есть, секционная База Данных!!!

Что касается, PostgreSQL (и других условно-бесплатных СУБД), то они просто пытаются повторить с некоторым опозданием ТЕХНОЛОГИИ старших братьев и все! Никаких НОВЫХ и ПЕРЕДОВЫХ технологий ОНИ не изобретают!

Кроме того, все понятно...бесплатно и открыто....а кто отвечать будет, если что случиться???

Еще один нюанс, та же самая репликация....Чтобы выиграть тендер...Исполнитель (PostgreSQL) "упал в цене и по срокам"....и вместо того чтобы писать "прикладуху" он будет вынужден тратить все отведенной время и за гроши на создание (или адаптацию какого-либо условно-бесплатного решения) механизма репликаций, так как в СУБД бесплатной этого нет! Не позавидую бедняге....

Друзья, поверьте никто не отменял поговорку..."Скупой платит дважды!"

[Nadir Zaitov]

Кошелёк тоже будет стройнеть. Отгрузим midrange или hi-end серверы с огромным удовольствием! Главное сравнить стоимость роста вверх и решения на основе RAC. Кстати, может RAC и не запуститься толком (встать RACом :))?
Тоже самое кратко изложил в своих постах ранее г-н Erkin Kuchkarov, но, как мне показалось был не понят.Это где? Я видимо его совсем не понял!!!

[kdima71]

Поздравляю Всех с наступающим Новым Годом!

Позвольте еще один "не технический довод" высказать.

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

Мало того, что на вопрос Заказчика: "А где Вы, братцы, внедрили еще свой ЭДО?", им нечего будет ответить, так еще им придется открыть другую "тайну" - ЭДО реализован на почти не известной и мало расспространенной в регионе СУБД и что они готовы на свой страх и риск поодерживать ее. Результат, будет я думаю плачевным для парней....

P.S. Специалисты "ясные и четкие (практические, не маркетинговые) заключения" выдают как правило, когда знают кому и зачем это нужно и что за это им будет! (шутка)

[Nadir Zaitov]

Кроме того, все понятно...бесплатно и открыто....а кто отвечать будет, если что случиться??? "Полубесплатный" саппорт. Он и у Oracle support и тоже платный.Не местные же головы и умы :)

[kdima71]

Кроме того, все понятно...бесплатно и открыто....а кто отвечать будет, если что случиться??? "Полубесплатный" саппорт. Он и у Oracle support и тоже платный.Не местные же головы и умы :)

Я понимаю, «кто не рискуют, тот не пьет...»

[Nadir Zaitov]

«кто не рискуют, тот не пьет...» Я как раз наоборот - консервативен. Где уже пьют, там я и рискую :)

[Eldar Fattakhov]

Главное сравнить стоимость роста вверх и решения на основе RAC.
Сравнить стоимость решений в лоб - достаточно тяжело. Я думаю, что ни HP (как производитель "железа"), ни Oracle (как производитель "софта") не будет противопоставлять оба типа масштабирования. :)

Учитывая специфику организации закупок, горизонтальное масштабирование может оказаться более удобным, т.к. 4 процессора в системах entry-level обойдутся заведомо дешевле 4 процессоров в системе mid-range или high-end. Разницу "подъест" стоимость лицензий на RAC... Третий узел улучшит разницу в цене, но добавит сложностей в управлении... И так и далее. :)

Поэтому, если есть возможность сразу увидеть место для "большой" системы - нужно брать mid-range и старше. Если же период "поглощения" ресурсов большой машины растягивается на два-три года, то имеет смысл обратить внимание на малые (2-4 процессора) системы. Это намного лучше, чем брать полупустую (или, что еще хуже) полную на одну четверть или одну восьмую "машину" (1-2 процессора из 8 возможных).

[Nadir Zaitov]

Разницу "подъест" стоимость лицензий на RAC... Надо отметить, что не просто подъест, а будет продолжать подъедать (22% в год);)

Кстати система на 4 процессорах entry-level уже не дешевая игрушка для Orace EE. Только лицензии на 4 процессора в системах entry-level (4 ядрышка считать?) стоят 47 000$/p x (1.22 support) x 4 (p) x 4 (c) x 0,5 (per core ratio for intel)=458 720$ и это без дополнительных опций Oracle. Итог кажется простым: в мусорку RAC, если при начальной комплектации стоимость начальных серверов перепрыгивает через mid range сервера (с меньшим количеством процессоров) в нормальной комплектации за пол стоимости Oracle (стоимость RAC! - 50% от стоимости Oracle EE). То на то вроде и выходит. Я согласен, что считать придется в любом случае :).