Выполнение PHP-приложений в Apache Geronimo

>да какая разница что там делает RAC, может он просто html рисует для веба (есть такое htmldb, теперь apex завется заменитель php по сути) или космические вычисления делает в pl/sql :) а как это называть grid cluster, failover cluster, load balancer решают маркетологи ... но как бы они не назвали суть не меняется.

Можно и паровозом орехи колоть, но если вы сейчас скажете что рисовать HTML из РСУБД (при этом иметь продукт другой как Oracle AS) это правильно, то лучше нам завершить беседу. Терминология в случае Grid существенна, т.к. появляется в схеме серверы приложений и другая байда. http://www.oracle.com/technologies/grid/grid_products.html

Понятное дело что Database при этом у Оракл первым в списках, т.к. это рабочая лошадка.

>я правильно понял вы наконец увидели в RAC cluster :) и здаетесь :) ?

Не совсем вы правильно поняли. Я прислал цитату с Оракл, т.к. вы начали делать из RAC что-то другое помимо кластерной РСУБД. Я не говорил что RAC вообще не кластер, а говорил что он условный (не больше и не меньше).

Я чтоли нарвался на фанатика Оракл :-) Могу успокоить - используем тоже, и не фанат DB2, хотя к нему тоже отношусь спокойно.

я ж специально вам кейвордс дал apex/htmldb, это именно компанента рсубд. типичный пример asktom.oracle.com, по сути это модифицированый апач с модулем pl/sql который вместо запуска php запускает pl/sql внутри субд. поймите любая современная субд это не просто набор плоских табличек, это еще и навороченый "сервер приложения" с несколькими языками: в оракле это pl/sql и java, в мс t-sql и .net и все это неотьемлемая часть движка субд. этими языками в ядре субд можно решать любую задачу, хоть 3D расчитывать ничего не складывая в таблицы. другое дело что некоторые задачи (например 3D) решать в субд по меньшей мере глупо, но это для нас неважно ...

P.S. я фанат рсубд, оракл просто самый навороченый. :)

Minotaurus.

>поймите любая современная субд это не просто набор плоских табличек, это еще и навороченый "сервер приложения" с несколькими языками: в оракле это pl/sql и java, в мс t-sql и .net и все это неотьемлемая часть движка субд. этими языками в ядре субд можно решать любую задачу, хоть 3D расчитывать ничего не складывая в таблицы. другое дело что некоторые задачи (например 3D) решать в субд по меньшей мере глупо, но это для нас неважно ..

Мы с вами не сойдемся во взглядах тогда. РСУБД должна решать свою основную задачу, AS - свои и друг друга не должны замещать, IMHO конечно, но не я один этого придерживаюсь. Языки в РСУБД (даже Java) существуют чтобы работать данными в РСУБД, а не html генерить :)

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

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

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

Minotaurus.

>присмотревшись "главного" мы там таки не нашли, единое хранилище у нас оказалос вполне законной опцией кластера, у нас будут еще аргументы по "условности" ?

Хех... Жалко LOR не позволяет аттачить картинки. Единое _распределенное_ по серверам хранилище - это возможная опция кластера, а в RAC'е оно выглядит как одна большая болванка (в основном массив-дисков) куда ходят все сервера кластера. Т.е. само хранение отнюдь не кластерное, а делается на уровне массивов дисков. Конечно еще можно (за счет других уже производителей, а не Oracle) собрать дисковые массивы кластерные, но будут сильно ограничены скоростью interconnect'a между собой. Это про первый пункт. Второй - RAC ограничен еще и тем, что при использовании одних и тех же ресурсов, будет работать глобальная служба блокировок, и опять уткнемся в interconnect но уже на уровне серверов RAC-кластера.

>а потом можно и пофилосовствовать на тему кто кого не должен замещать (к стате она у меня сейчас больная в связи с новой разработкой)

Насчет еще и этого философствовать думаю не надо.. Старый я уже... :) Да и лень писать много буковок.

Кстати - вопрос почитатем РСУБД Oracle/RAC. Можно ли хранение БД при RAC посадить на кластерную файловую систему, чтобы разбросить хранение? Если это возможно и не создаёт больших проблем, то я возьму свои слова обратно насчёт его условности, т.к. в этом случае он действительно будет кластером, правда будет 2-ная блокировка (одна на уровне ФС, другая самим Oracle) :(

s/будет кластером/будет классическим кластером/

Да вообще вспоминая возможность кэширования данных БД на каждом узле, отличия от классики мне теперь самому кажутся минимальными. :-)

да конечно можно на кластерную фс положить, но перфоменс будет соответствующий. у вас просто какой-то клинч с масивом, ну откройте top500.org, любой кластер там идет с отдельным масивом:

http://www.cs.sandia.gov/platforms/Thunderbird.html
http://www.nas.nasa.gov/Resources/Systems/columbia.html

Minotaurus.

>но перфоменс будет соответствующий

Ну это и есть большая проблема, т.е. нельзя получается. А в паре с partitioning интересно кто нибудь пробовал.

>у вас просто какой-то клинч с масивом,

Ну не красиво он кластерной схеме просто выглядит. Ок. Я согласен, что Oracle RAC это классическая схема shared-disc cluster (хотя производителей этой схемы не очень то и много). Вы удовлетворены? :)

Удолетворен :) но был бы просто счастлив если вы бы мне показали хоть один кластер из top500 в котором кому-то пришло в голову работать с кластерной файловой системой вместо масива. :)

>но был бы просто счастлив если вы бы мне показали хоть один кластер из top500

Ходить по этим спискам, откровенно мне лень, но т.е. хотите сказать, там все кластерам хочется работать с массивами дисков и им всем обязательно нужно хранилище?

Удолетворен :) но был бы просто счастлив если вы бы мне показали хоть один кластер из top500 в котором кому-то пришло в голову работать с кластерной файловой системой вместо масива. :)

>Ходить по этим спискам, откровенно мне лень, но т.е. хотите сказать, там все кластерам хочется работать с массивами дисков и им всем обязательно нужно хранилище?

конечно, зачем заниматся херней програмно, если масив это и есть по сути "кластер" просто полностью железный ...

>конечно, зачем заниматся херней програмно, если масив это и есть по сути "кластер" просто полностью железный ...

Возможно спорить не буду... Да и устал :-)