Опять же на тему "готовых" решений

[metaclass]

В последних постах yakov_sirotkin про очередь асинхронной обработки задач упоминается, почему они отказались от "готового" решения в виде Oracle AQ: это дело есть только в определенных Edition оракла и при тестировании у них возникли какие-то баги в очередях.

А у меня в двух проектах есть такие задачи, с обработкой очередей. И вот я сразу себе представляю - приезжаем ставить софт, клиент сказал, что у него "есть Оракл", а по приезде оказывается что это Express Edition, а DBA, которые в случае глюков будут разбираться в них, вообще нет. "Сушите весла."

То же самое касается практически всех "готовых" решений для сложных задач, входящих в состав СУБД, ОС или там еще чего-нибудь инфраструктурного. Как только принято решение использовать что-то более сложное, чем базовые функции - с этой системы ты уже никуда не уйдешь и нужно изучать ее "вглубь" и надеятся, что в следующих релизах этот функционал не выкинут, не изменят условия лицензирования, и что он будет работать как надо в других окружениях, и что будет достаточное количество людей, его использующих, чтобы было с кем посоветоваться.

Comments

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

Увидел "не получится" но не увидел почему.

[sergiej.livejournal.com]

По ссылке много всякого про рефакторинг и про странных людей которые не любят писать SQL. Там нет ничего про то что трёхзвенная архитектура с чёткими границами и протоколами не получится. Я что предлагаю SQL не тюнить как ваши пациенты?

[sergiej.livejournal.com]

Никакого проблемного пересечения, приведённые у вас примеры с "логикой" запроса с аггрегационной функцией это банальная ошибка дизайна, места где бизнес логику надо пускать на уровень базы черезвычайно редки.

[sergiej.livejournal.com]

Не хочется флеймить, нравится вам всё на базе делать - делайте.

[vp.livejournal.com]

Хороший пример. Всегда было интересно, какие на него могут быть контраргументы в плане предлагаемой реализации.

[alexclear.livejournal.com]

Таких мест множество. Начнем с очевидного - монитора безопасности. Если вы не реализуете эту логику на уровне СУБД, то на ее клиенте предстоит всякий раз построчно проверять, надо ли показывать информацию в контексте данного соединения.

Звучит как угроза!
Но таковой не является, на самом деле, никакую логику не надо реализовывать на уровне СУБД, если речь идет о бизнес-логике, конечно.
Да, очень многие бизнес-логику фигачат прямо на PL/SQL или на T-SQL или что они там знают, но это от отсутствия культуры разработки и общей эрудиции.
А что было бы со стартапом, когда завтыкала бы бизнес-логика в движке сервера, а не извне? Люди цепляли бы профайлер к движку? Если они не умеют к своему собственному приложению профайлинг прицепить, как они сделают это к чужому?

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

[alexclear.livejournal.com]

Я понял только про 20 тысяч мелких SQL-запросов, но при чем же здесь ORM?
Кстати, в Hibernate есть магические слово "внешний кэш", в NHibernate оно, наверное, тоже есть. Его как, включали вообще?

Однако, запросы типа "выбрать сотрудников, зарплата которых в течение последнего года не превышала среднюю за предыдущий год" уже вызывают проблемы на уровне встроенного языка. Тогда разработчики идут зачастую единственно возможным путем: выбираем коллекцию объектов и в цикле ее фильтруем руками, вызывая методы связанных объектов. Количество небольших SQL-запросов к СУБД при такой обработке коллекций может исчисляться десятками тысяч.

Прекрасно, прекрасно.
Это не разработчики, а шлак, их гнать надо ссаными тряпками, а лучше - на мясо забивать.
Совершенно ведь неясно, для кого в ORM оставлена возможность исполнения native queries? Или они о ней просто не знали, о такой возможности?
Фильтровать на клиенте - это отлично, отлично. Это ноу-хау, практически.
Здесь не ORM, здесь голова виновата.

Внешний кэш не помог бы, кстати. Только расстрел.

[metaclass.livejournal.com]

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

[alexclear.livejournal.com]

Какой еще кеш при первой загрузке?

Не нервничайте так, я просто спросил, а Вы уже начали бой с тенью.

При последуюших, вы хоть слегонца представляете себе систему управления документооборотом?

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

Это будет кеш, в который надо впихнуть почти все обьекты. Смешно пошутили.

Я не пошутил, я просто спросил, мне стало интересно, разработчики документацию на Hibernate читали, или били вместо этого хуем о стол?
Вы, как я понял, тоже документацию не читали?

Прямые сиквел-запросы из ОРП?

Совершенно верно.
Более того, у нас разработкой и профилированием запросов занимался специальный человек.

Ваш коллега выше только что утверждал "трёхзвенная архитектура с чёткими границами и протоколами" - и все в шоколаде (http://metaclass.livejournal.com/366207.html?thread=2699391#t2699391).

Я не понимаю, чем даже десятизвенная архитектура помешает мне сделать native query, извините.

Привет четким границам :)

Между чем и чем?

А вы в курсе, что одного запроса скорее всего не хватит? :)

А что мне помешает сделать столько запросов, сколько я захочу?
Где здесь влияние ORM?

Простейший пример: списываем товар со склада. Считаем сальдо, смотрим, не отрицательное ли. Списываем. Все в "толстой транзакции" с высоким уровнем изолояции, иначе между вашей проверкой и списанием может проскочить списание манагера, сидяшего в соседней комнате.

Звучит пугающе, особенно про "толстую транзакцию". Но выглядит совсем не пугающе.
Ну толстая. Ну транзакция. И что?
Я обоссаться должен от страха?

[alexclear.livejournal.com]

То, что "разработкой и профилированием запросов занимался специальный человек" - это есть правильно, вопрос снят.

Как говорит один мой коллега, "ну, мы же профессионалы".

По поводу кеша ситуация примерно такая. Пользователи постоянно работают с неким подмножеством документов (поскольку они завязаны в длинные цепочки плюс история изменений). Так вот если кешировать их с попаданием на уровне ОРП в районе 95%, то сервер понадобится с обьемами памяти, в разы превышаюшей память СУБД-сервера. По сути - еще одна мини-СУБД целиком в РАМ с обьектным интерфейсом.

Понимаю.
Мы, кстати, этот кэш включили и отключили через день.
Толку никакого, одно огорчение.
У нас, правда, кэшей хватало и без этого.

Я даже не говорю про то, что такой кеш должно постоянно поддерживать в синхронном состоянии с базой данных, иначе работа других приложений с этой же базой в обход ОРП (например, отчетов) будет выдавать неверные или неактуальные данные.

Это Hibernate делает автоматом, этот кэш полностью прозрачен.
Но вот только он не нужен для таких систем.
Тем не менее, полезно бывает знать, что он есть.

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

А, речь идет именно о выборке.

Классика жанра: выбрать коллекцию и потом в цикле вызывать методы ее обьектов. В случае затыка (типа выбрали 1000 обьектов и дергаем по 5 вызовов на каждый) никаким "тьюнингом" сиквела здесь проблему не решить - требуется этот кусок полностью переписывать в виде хранимой процедуры.

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

Логика размазывается между СУБД и СП. Четкие границы исчезают, как химера соответствующих архитекторов.

Ну, это тоже не страшно.
Со слезами занесем логику в базу, если так уж надо.
Но еще ни иазу не видел ситуаций, когда действительно было надо.

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

Блокирует работу?
Каким образом?
Разве optimistic locking что-то блокирует?
Мне сложно представить себе ситуацию, когда EJB встал в блок на чужой транзакции, это чушь какая-то.

[alexclear.livejournal.com]

В этом типовом примере проблемы начинаются в самой постановке задачи.
Другие пользователи не должны начинать курить, пусть себе работают.
А если этот пользователь залочил документ, и его молнией убило?
Почему нельзя использовать optimistic locking, я не понимаю?

[alexclear.livejournal.com]

Нет, там никто никого не "залочил". Запустился процесс изменения состояния документа (пользователи инициировал или сервис, не важно), в процессе изменения требуется поддержать логическию целостность: пока процесс не завершился другие не могут делать что-то пересекающееся.

Это и есть "залочил".
Не скейлится.

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

А зачем?

Еще грубее: два манагера не могут продать по 5 банок краски, если на складе их всего 5 даже если их процессы запустятся одновременно.

И не продадут.
Кто первый успеет изменить состояние, тот и папа, а второй не успеет.
ЛОЧИТЬ НИЧЕГО НЕ НАДО.
Надо просто использовать Hibernate и дуракцих проблем с дурацкими блокировками не будет.
Ну, или не Hibernate, а, я не знаю, здравый смысл.

[alexshubert.livejournal.com]

пока процесс не завершился другие не могут делать что-то пересекающееся
меж тем на дворе шел 2009 год, версионность и рота красногвардейцев.

[alexshubert.livejournal.com]

Я бы не взял на работу автора.

[sergiej.livejournal.com]

Прямые запросы это некошерно, если надо делать на базе - ХП которая вызывается с высокого уровня.
"чёткие границы" очень просто устанавливаются, логика подсказывает что функция будет оптимальнее производится на уровне базы - она там и реализуется, ХП выставляет формализованный интерфейс (набор параметров, как вы говорите) вот она и граница. Программер логики не лезет в процедуру которая не на его уровне, программер базы не грузится тем что там наверху происходит - оптимизирует процедуру если надо. Вот и всё.