st_sthttp://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
за 2006 год, oracle.

No business logic in database
- No stored procedures
- Only very simple triggers (default value population)
Move CPU-intensive work of applications
- Referential integrity
- Joins
- Sorting
Extensive use of prepared statements and bind variables

А теперь, вопрос: Что здесь делает Oracle (или любая другая клиент\серверная СУБД)?

kdvпри данной архитектуре системы, трехзвенной по факту, и особенно конкретной нагрузке, было бы глупо всю обработку логики кидать на сервер

Всю, это простите, какую!? Действительно, есть некая часть нагрузки, которую можно параллелить средним звеном. Но, извините, именно транзакионную часть, Вы как хотите, но никак не распараллелите на среднем уровне.

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


Да хоть 958 звеньев по середине. В любом случае СУБД (RAC или аналогичные решения) должна поддержать все это хозяйство.

ЗЫ. Давненько не всплывали темы про N-звенки...

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

Рискну спросить: что для "тупого отказоустойчигого хранилища" проще перемолоть:


или

kdvтакое впечатление что Вы не писали трехзвенных систем, или никогда в жизни не видели электронных магазинов.

Спасибо. Я ждал примерно такого пассажа.

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

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

kdvКроме того, не вижу особой связи между транзакционностью и бизнес-логикой. Какая разница, запустить пакет PL/SQL, или выполнить обработку в транзакции в среднем звене? Или что, на Оракле нельзя писать без PL/SQL ? Или PL/SQL намертво привязан к транзакциям?

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

kdvСобственно, "распараллеливание транзакционной части" на среднем звене не требуется и разумеется из СУБД вынесено быть не может. Но речь как раз о том, чтобы кроме как транзакциями и изменением данных Оракл не грузить, и чтобы вычислениями занималось среднее звено, а не Оракл.

А тут, собственно, никто и не спорит. Часть "вычислений", действительно, можно вынести на средний уровень и распараллелить (чем, собственно, и пользуемся). Но есть часть транзакционной нагрузки, которую, к сожалению, ну никак на среднем звене не распараллелить.

ЛПСчитая, что внутре хранимки находится та же самая последовательность селектов/инсертов/упдейтов - рискну предположить, что тупому отказоустойчивому хранилищу примерно одинаково. На то оно и тупое.

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

Ваша последовательность действий накатывания обновлений на "систему"? Естественно, это кластер, как минимум NLB на среднем уровне...

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

Для абстрактных данных и абстрактной их обработки ничего не "получится". Решение надо находить в каждом конкретном случае.

авторВобщем понятно в общих чертах, для разгрузки oracle, решили перенести обработку на сторону web-приложений.

Еще раз повторюсь. Часть нагрузки (в основном RO нагрузка) можно вынести на средний уровень и баллансировать там. Но в любом случаем саму процессинговую часть, "меняющую данные" в хранилище, никуда не унести.

авторКстати, а хранимые процедуры используют в вебе на крупных проектах?

Да. В полный рост. И не только хп. В "крупных проектах" вообще в большинстве случаев прямой доступ к таблицам закрыт.

авторА так конечно, в основном везде php + mysql, форумы, cms, интернет-магазины (oscommerce к примеру), пишут запросы внутри php-страниц и не задумываются ни о каких процедурах.

Какая то у Вас не полная математическая индукция. Даже этот форум не на пхп и не на майскуле.

авторИмеет ли смысл выделяться из общего потока и работать только с процедурами?

Хотите посоревноваться с лидерами этой отрасли рунета - "выделяйтесь и работайте".

авторТам asp.net + ms sql server

Как уже было сказано выше - не только там.

GrayStrannikВ массовых эл. магазинах на самом деле используется MySQL с движком вообще без транзакций. И с этим нет проблем, потому что транзакция там умещается в один неконкурентный запрос.

Давайте определимся с терминологией. Под термином "массовый" Вы понимаете кол-во интернет-магазинов или, все-таки, число клиентов одного интернет-магазина?

GrayStrannikДаже один из крупнейших интернет-магазинов Болеро на своём сайте официально пишет, что 2-3% заказов заканчиваются отказом в товаре - у них нет своего склада, нет информации по наличию на чужих складах товара и им в транзакции нечего резервировать.

Гм... Ну, значит, расти им еще и расти. Ни склада своего нет, ни данных о наличии у поставщиков, ни данных о... Кстати, принятие заказа (транзакция) <> резервирование товара под него (еще одна транзакция).

GrayStrannikТакова жизнь: проблема с отсутствием транзакций поглощается куда большей проблемой с физическим учётом наличия товара на складе.

Ну, если "учет наличия товара на складе" для кого-то проблема...

GrayStrannikИ много Вы знаете российских форумов, под которыми не MySQL?

Мне глубоко наплевать на статистику распределения СУБД по Российским форумам. Не потому, что они, Российские, а потому, что они форумы, и не имеют, за очень редким исключениме отношения к сабжу: "Высоконагруженные проекты".