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

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

По личному опыту (и не только моему), EJB и производительность вообще мало совместимы и основные проблемы с производительностью живут в БД, поэтому нужно организовывать кэширование и очень хорошо продумывать стратегию персистанса.

Ну, совсем чистый JDBC - это плохо, тогда уж по крайней мере обернуть его с помощью Spring.
Впрочем, особых проблем в писании прямых запросов в нормально спланированной системе не вижу.
Их, по идее, очень мало и они должны быть простые.


Так как у нас требования по производительности были довольно существенные, от Hibernate и прочих ORM отказались сразу, так что про их код ничего сказать не могу. Впрочем, в процессе развития системы из всего J2EE остались только сервелеты и JDBC.

Судя по всему, для тебя главное - это организация кэширования используемых данных и обновление этих кешей внутри кластера. Решений для этого - довольно много.

Если данные меняются редко, то подумай над хранением в БД не нормализованных данных, а, например, сериализованных Java объектов (в блобах) - это может и упростить код и снять проблему оптимизации SQL запросов.

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

ну это будет автопортал, там будут в большинстве своем транзакции читающие данные, часть логики будет на стороне SQL сервера, например процедуры выборки по zip code
А вот от сложной логики на строне сервера - лучше избавится. От всего, что сложнее простого insert или update.

Предыдущий пост читать как:

А вот от сложной логики на стороне сервера БД - лучше избавиться. От всего, что сложнее простого insert или select.

(Брр, вот что бывает, если делать два дела сразу.)

1. Обычно в подобных системах узким место является БД и, реже, системы формирования HTML страничек (Struts, Tapestry и иже с ним). Второе сравнительно легко кластеризуется, а вот с эффективной кластеризацией БД при высоких нагрузках все гораздо хуже.
Так что лучше как можно меньше нагружать БД - т.е. использовать простейшие запросы, минимализировать блокировки, использовать кэширование и т.п.
В результате хранимые процедуры - это, скорее, зло. Как и сложные триггеры, например.
Потенциальная потеря производительности без какого-либа выигрыша.
В некоторых случаях без хранимых процедур сложно обойтись, но чем их меньше - тем лучше.

2. Про целостность - тут все сложнее.
Мы вообще в БД кладем сериализованные объекты, что снимает вопрос целостности полностью, да еще и сильно экономит требования к БД. Но не во всех случаях это возможно, сильно зависит от бизнес-логики.
Если же БД - нормальная нормализованная БД, где все сущности предметной области разложены по табличкам - то я бы на этапе разработки использовал бы FK (как вторую линию обороны при Unit тестах), а в production, если окажется, что FK начинают реально съедать производительность - их бы просто отключил.
Я не измерял реальные затраты на проверку foreign key constraint и не могу сказать, насколько плохо это сказывается на производительности. Подозреваю, что меньше, чем блокировки или чрезмерная любовь к update.

[quote]
Сразу вспомнил вроде на Amazon был пресс релиз где они говорили что используют только какието элементарные триггеры со стороны сервера БД.
[/quote]
Я когда читал описание eBay - очень веселился, у нас система за два года прошла значительную часть их пути и многие решения были один в один...

Каскадное удаление и аналогичные подсластители не использовал. Соображений несколько:
1. Если система сложная, то все равно логика удаления записи обычно нетривиальна и сильно затрагивает сервер (т.к. нужно удалить объект не только из БД, но и из кэшей - а это значит, что все равно по структуре объекта придется пройти).

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

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

Если картинки нужны для отдачи клиенту на веб, то, как правильно сказали, их имеет смысл кэшировать в ФС, Apache со статическим контентом обойдется лучше.


А по производительности - мы на тестах регулярно накидываем до 1E6 блобов от 10k до 10M - никаких замедлений не наблюдалось, разницы между 1E6 и 1E4 не наблюдается вообще. БД, как уже говорил, DB2 Express C. Что будет для MySQL - не знаю.
Мы вообще отказались в процессе развития от хранения нормализованной информации в БД - оказалось, что быстрее и проще работать с сериализованным представлением объектов предметной области. Но тут многое зависит от специфики задачи и количества межобъектных связей - нам удалось их сильно уменьшить.

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

В этом решении есть несколько подводных камней:
1. Многое зависит от скорости сериализации. Например, сериализация в XML, скорее всего, будет тормозить. Стандарный вариант сериализации тоже не очень быстрый (там все через reflection).
Писать свою сериализацию через readObject etc - достаточно сложно.
2. А что ты будешь делать при обновлении версии? Если в базе лежат сериализованные объекты от разных версий и, возможно, с разными структурами? Решений может быть довольно много, но их стоит продумать заранее. Вообще, смена версии в production - это всегда проблема.
3. Если объекты хранятся большие, а меняется в них какая-то мелочь, то приходится делать update всего объекта - что может быть слишком дорого. Нужно продумывать логику обновлений.
4. Отчеты... В особенности аналитические - их делать будет несколько сложнее.

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


Такой вопросик возник, а как принято с сессиями поступать? к чему ты пришел из опыта? в базе хранить данные сессии или всетаки через стандартный механизм??

Мы храним в распределенном кэше, но у нас в данном случае много специфических тонкостей, не уверен, так что смело рекомендовать не могу. У нас даже Web клиент очень толстый (AJAX) и, по сути, в сессии нужно хранить только ее id и очередь команд, которые нужно отправить на клиент. И вся эта информация, в общем, не имеет особой ценности и может быть потеряна.