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

[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-соединения, желательно с открытым текстовым протоколом поверх него, все остальное - тяжкий кошмар.

[vp.livejournal.com]

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

[themech.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[vp.livejournal.com]

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

[alexclear.livejournal.com]

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

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

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

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

[alexclear.livejournal.com]

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

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

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

[metaclass.livejournal.com]

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

[alexclear.livejournal.com]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[alexclear.livejournal.com]

Вы пиздец какой опасный, "слив защитан", ололо.
Сразу видно профессионала.

[sergiej.livejournal.com]

У вас не было вопроса, на что отвечать? На то что "загрузка документа со сложной схемой прав на видимость атрибутов" это логика?
Или: Расчёт сальдо при истории хозопераций... круто, где там бизнес логика? Если можно сделать на базе запрос с аггрегацией - его надо сделать.
Вообще засчитывайте что хотите, я столько раз пытался объяснить людям которые всё делают на базе или которые наоборот всё делают на пользовательском интерфейсе зачем нужна трёхзвёнка что жалко тратить время, если человек сам не понял - значит оно ему не нужно было, и может быть что в его области оно и не нужно.

[sergiej.livejournal.com]

Какие контраргументы? Делать вместо аггрегационного запроса подсчёт на высоком уровне? Это надо быть психом.

[alexclear.livejournal.com]

Ага.
Сейчас изучу этот вопрос подробнее.

[alexclear.livejournal.com]

А, ну монитор безопасности это хорошая тема, сложная.
Я бы, пожалуй, начал с описания модели безопасности - какие есть объекты и субекты и как они должны соотноситься.
У нас модель безопасности была очень облегченной по ряду причин, тем не менее, были роли и группы ролей, вот только объектом был весь воркфлоу.
Что для системы с уклоном имено в документооборот вряд ли приемлемо.

[alexclear.livejournal.com]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[sergiej.livejournal.com]

Ага, круто, в первом случае "вызов ХП", внутри там ничего не происходит, просто в поставке оракла уже есть ХП "Списаниие товаа со склада по расходному документу". Круто, тогда конечно первый вариант.

[alexclear.livejournal.com]

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

[alexclear.livejournal.com]

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