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

[Nadir Zaitov]

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

Только сравнивать её нужно с подобными ей.

Что еще Оракула отличает от простых смертных других СУБД, например, от послеГре кроме этого (RAC):

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

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

Дайте ясное понятие.

[Eldar Fattakhov]

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

Дайте ясное понятие

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

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

[Erkin Kuchkarov]

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

в любой другой СУБД

У любых других есть другие методы

[Eldar Fattakhov]

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

У любых других есть другие методы

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

[Nadir Zaitov]

Оффтоп:

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

Но другие.

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

Вместе с тем, я что-то не вижу других преимуществ Oracle....

[Eldar Fattakhov]

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

Вместе с тем, я что-то не вижу других преимуществ Oracle....

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

[Erkin Kuchkarov]

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

я что-то не вижу других преимуществ Oracle....

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

[Eldar Fattakhov]

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

приходит идея не рости уже в ширь, а только ввысь -стройнее будешь

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

[Vsevolod Usmanov]

Оффтоп:

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

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

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

Всё верно. Приблизительно так всё и происходит, кэш-память общая, и название этому тоже имеется - "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]

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

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

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

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

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

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

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

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

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