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

[metaclass]

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

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

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

Comments

[lionet.livejournal.com]

Поэтому нужно использовать решения, которые базируются на открытых _протоколах_, а не API. Чтобы можно было имплементацию заменить.

AMQP этому удовлетворяет: есть несколько имплементаций. Oracle AQ — нет.

[metaclass.livejournal.com]

А, ну вот и отличный критерий отличия того, что можно использовать,а что нельзя :)
SQL для CRUD операций во всех СУБД весьма похож, с мелкими различиями - его можно использовать.
P/SQL везде разный - использовать на свой страх и риск, будучи уверенным, что потом придется переучиваться все равно.
Все дальше этого - есть или "только в Оракле", или "только в MSSQL" или еще где-нибудь - следовательно отправляется в лес.

Межпроцессное взаимодействие - в разных ОС похожим образом работают только две вещи - конвееры между stdin/stdout и TCP-соединения, желательно с открытым текстовым протоколом поверх него, все остальное - тяжкий кошмар.

[sergiej.livejournal.com]

А потом к тебе приходят умельцы и ноют что дженерное решение по производительности намного хуже их супезатуненого для PL/SQL и что ты вообще не знаешь как крут PL/SQL и лезешь со своими протоколами высокого уровня, которые "просто не могут быть быстрее"

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[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, я не понимаю?

[alexshubert.livejournal.com]

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

[sergiej.livejournal.com]

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

[vp.livejournal.com]

Тут еще разные ситуации. Одно дело, когда надор "теоретизирует в ЖЖ", но у них есть лишние полгода-год, чтобы разобраться, сделать что-то совместимым и т.п. И в противовес этому - когда "деньги оплачены, вам 36 часов чтобы развернуть систему или верните деньги плюс штрафы". Разная постановка, разная мотивация.

[themech.livejournal.com]

волков бояться... ;-)

[sergiej.livejournal.com]

Ну разве что готовое решение хорошо и недорого поддерживается производителем.