General Purpose <=> Shared Server

Помогите советом.

Есть "основная" БД, появилось желание прикрутить к ней ВЕБ-часть, но количество одновременных соединений (от веб-пользователей) будет приблизительно 3000-4000. Нет желания пускать вебных пользотелей в "основную" БД - видиться решение - поднять Shared Server исключительно для вебных пользователей.

Но как организовать обмен данными м/у "основной" и "вебной" БД? Есть самодельная репликация (кусок другого проекта), которая без проблем вкрутится, но может существуют стандартные (другие) решения?

ПС: "основная" - версия 9, "вебная" - планирую поставить 10-ку.

3000-4000. Нет желания пускать вебных пользотелей в "основную" БД

Собственно, почему?


- видиться решение - поднять Shared Server исключительно для вебных пользователей.


БТВ, посмотри такую весчь как connection manager, в твоем случае может оказаться полезной


Но как организовать обмен данными м/у "основной" и "вебной" БД? Есть

Что значит "обмен данными"? Четко сформулируй задачу.

MacDuck

3000-4000. Нет желания пускать вебных пользотелей в "основную" БД Собственно, почему?

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

MacDuck

БТВ, посмотри такую весчь как connection manager, в твоем случае может оказаться полезной

а ссылку можно? или гуглить?

MacDuck

Что значит "обмен данными"? Четко сформулируй задачу.

Мне кажется, что поток "основная" -> "вебная" вопросов не вызывает, а в обратную сторону предпологается, что пользователи смогут вносить информацию, которая может оказаться весьма полезной в "основной" БД.

connection manager входит в поставку Oracle, так что гуглить не нужно, только читать доку

tru55

connection manager входит в поставку Oracle, так что гуглить не нужно, только читать доку

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

вопрос состоял с следующем: есть стандартные средства для репликации данных в "обе стороны" м/у "основной" и "вебной"?

zirex

tru55 connection manager входит в поставку Oracle, так что гуглить не нужно, только читать доку да-да, уже нашел - мне он не очень поможет, т.к. в "основной" будут висеть сессии из пула - получается - "те же яйца только в профиль" :(

Ты не понял, это не вместо твоей репликации, это отдельно. Просто можно мультиплексировать твои веб-коннекты где-то за файрволами/DMZ, а к базе просунуть одно dedicated-соединение.

3000-4000 одновременных соединений или одновременно работающих пользователей? Первое - это уровень какого-нибудь eBay :-)

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

Сэмка

3000-4000 одновременных соединений или одновременно работающих пользователей?

Конкурирующих сессий. Разрулить нагрузку по 2-3-4 серверам не проблема.

Сэмка

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

Проект не первый, проект такого масштаба - первый. Сотни соединений 100% не хватит.

вопрос все еще актуален, пока время есть :)

zirex

Конкурирующих сессий.

Вы имеете ввиду 3000-4000 одновременно выполняющихся команд? Тогда действительно уровень eBay... Или таки одновременно существующих сеансов?

Кроме того, http протокол "stateless". Вы собираетесь на каждый web-запрос выполнять connect? А оставшиеся после выполнения бесхозные сеансы пришибать по IDLE TIME в профиле и статусу 'SNIPED' в V$SESSION?

Короче, практичным (из ныне популярных) решением будет middle-tier, который заодно будет держать пул соединений с БД и переключать контексты для выполнения запросов конкретных пользователей.

Там же можно фильтровать SQL-injection и прочие полезные мелочи.

Про репликацию - если уж так надо разделить базы - Advanced Replication, Advanced Queueing, можно свое нагородить. Главное правильно оценить пропускную способность и разруливание конфликтов.

Всего

Ааз

Вы имеете ввиду 3000-4000 одновременно выполняющихся команд?

да.

Ааз

Кроме того, http протокол "stateless". Вы собираетесь на каждый web-запрос выполнять connect? А оставшиеся после выполнения бесхозные сеансы пришибать по IDLE TIME в профиле и статусу 'SNIPED' в V$SESSION?

за раздачу и закрытие сессий отвечает pool.

Ааз

Про репликацию - если уж так надо разделить базы - Advanced Replication, Advanced Queueing, можно свое нагородить. Главное правильно оценить пропускную способность и разруливание конфликтов.

вот поэтому ее и не получиться использовать.

Похоже придется прикручивать самописную репликацию...
Спасибо, Ааз.