То, что "разработкой и профилированием запросов занимался специальный человек" - это есть правильно, вопрос снят.
Как говорит один мой коллега, "ну, мы же профессионалы".
По поводу кеша ситуация примерно такая. Пользователи постоянно работают с неким подмножеством документов (поскольку они завязаны в длинные цепочки плюс история изменений). Так вот если кешировать их с попаданием на уровне ОРП в районе 95%, то сервер понадобится с обьемами памяти, в разы превышаюшей память СУБД-сервера. По сути - еще одна мини-СУБД целиком в РАМ с обьектным интерфейсом.
Понимаю. Мы, кстати, этот кэш включили и отключили через день. Толку никакого, одно огорчение. У нас, правда, кэшей хватало и без этого.
Я даже не говорю про то, что такой кеш должно постоянно поддерживать в синхронном состоянии с базой данных, иначе работа других приложений с этой же базой в обход ОРП (например, отчетов) будет выдавать неверные или неактуальные данные.
Это Hibernate делает автоматом, этот кэш полностью прозрачен. Но вот только он не нужен для таких систем. Тем не менее, полезно бывает знать, что он есть.
По поводу нескольких запросов вместо одного - все прозрачно. Если вам одного не хватает, значит последуюшие будут использовать данные предыдуших.
А, речь идет именно о выборке.
Классика жанра: выбрать коллекцию и потом в цикле вызывать методы ее обьектов. В случае затыка (типа выбрали 1000 обьектов и дергаем по 5 вызовов на каждый) никаким "тьюнингом" сиквела здесь проблему не решить - требуется этот кусок полностью переписывать в виде хранимой процедуры.
Но зачем может понадобиться такая стремная задача? Это обработка по расписанию? Если да, то и фиг бы с ней, пусть тягает кусками по 1000 объектов и делает эти свои вызовы. Если же это что-то, что мы хотим пользователю показать, то куда ему 1000 сущностей-то? На экран они не влезут.
Логика размазывается между СУБД и СП. Четкие границы исчезают, как химера соответствующих архитекторов.
Ну, это тоже не страшно. Со слезами занесем логику в базу, если так уж надо. Но еще ни иазу не видел ситуаций, когда действительно было надо.
Наконец, толстая транзакзия должна выполняться максимально быстро, т.к. она блокирует работу других пользователей. При маштабировании с десятка на сотни пользователей приложению наступают кранты.
Блокирует работу? Каким образом? Разве optimistic locking что-то блокирует? Мне сложно представить себе ситуацию, когда EJB встал в блок на чужой транзакции, это чушь какая-то.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2009-04-29 01:04 pm (UTC)Как говорит один мой коллега, "ну, мы же профессионалы".
По поводу кеша ситуация примерно такая. Пользователи постоянно работают с неким подмножеством документов (поскольку они завязаны в длинные цепочки плюс история изменений). Так вот если кешировать их с попаданием на уровне ОРП в районе 95%, то сервер понадобится с обьемами памяти, в разы превышаюшей память СУБД-сервера. По сути - еще одна мини-СУБД целиком в РАМ с обьектным интерфейсом.
Понимаю.
Мы, кстати, этот кэш включили и отключили через день.
Толку никакого, одно огорчение.
У нас, правда, кэшей хватало и без этого.
Я даже не говорю про то, что такой кеш должно постоянно поддерживать в синхронном состоянии с базой данных, иначе работа других приложений с этой же базой в обход ОРП (например, отчетов) будет выдавать неверные или неактуальные данные.
Это Hibernate делает автоматом, этот кэш полностью прозрачен.
Но вот только он не нужен для таких систем.
Тем не менее, полезно бывает знать, что он есть.
По поводу нескольких запросов вместо одного - все прозрачно. Если вам одного не хватает, значит последуюшие будут использовать данные предыдуших.
А, речь идет именно о выборке.
Классика жанра: выбрать коллекцию и потом в цикле вызывать методы ее обьектов. В случае затыка (типа выбрали 1000 обьектов и дергаем по 5 вызовов на каждый) никаким "тьюнингом" сиквела здесь проблему не решить - требуется этот кусок полностью переписывать в виде хранимой процедуры.
Но зачем может понадобиться такая стремная задача?
Это обработка по расписанию?
Если да, то и фиг бы с ней, пусть тягает кусками по 1000 объектов и делает эти свои вызовы.
Если же это что-то, что мы хотим пользователю показать, то куда ему 1000 сущностей-то? На экран они не влезут.
Логика размазывается между СУБД и СП. Четкие границы исчезают, как химера соответствующих архитекторов.
Ну, это тоже не страшно.
Со слезами занесем логику в базу, если так уж надо.
Но еще ни иазу не видел ситуаций, когда действительно было надо.
Наконец, толстая транзакзия должна выполняться максимально быстро, т.к. она блокирует работу других пользователей. При маштабировании с десятка на сотни пользователей приложению наступают кранты.
Блокирует работу?
Каким образом?
Разве optimistic locking что-то блокирует?
Мне сложно представить себе ситуацию, когда EJB встал в блок на чужой транзакции, это чушь какая-то.