whatsupbros

Отличный обзор, браво! Наконец глоток свежего воздуха после миллиарда этих дилетанских обзоров по типу «анбоксинга», где они в лучшем случае прочитали аннотации к плате, написанные на коробке.
Ещё раз — спасибо за отличный обзор отличной платы без этих ваших лампочек и радиаторов с вензелёчками и яркими цветами. Очень хочется видеть больше действительно качественных вещей для людей, которые не стремятся сделать из своего системного блока новогоднюю ёлку.

Сочувствую всей твоей команде, если ты в проде по десять версий кодовой базы держишь…

Ой, слушай, иди схемалесс жсоны в монгу пуляй :) Что ты вообще в Оракловом треде забыл?

1) Ага, то есть убивая ноды своего мидла, которые выполняли там какой-то длинный запрос в базе, ты конечно не вызываешь никаких ошибок у своих драгоценных пользователей.
2) Создай Хранимка_версия_2 и дергай в ОБНОВЛЕННОЙ ноде вторую версию. Или тебе надо пояснять за версионирование API?
---
Ты задолбал свои ярлыки развешивать, «из прошлого». Если ты весь из себя адепт контейнерной архитектуры, будь им, тебе никто этого не запрещает. Если ты не умеешь в версионность компонентов, просто признай это

Как же у тебя подгорает...
---
1) EBR
2) Твои ноды всё равно берут данные из одного источника. Тебе никто не запрещает по-прежнему спавнить свои ноды и дальше. Какая разница что у тебя будет отваливаться в Bad Weather Scenarios, запрос в базу или запрос на вызов хранимки.
---
Ты всё ещё не понимаешь что я имею ввиду и споришь сам с собой.

> Не совсем, віполняется на ресурсах базі с минимальной изоляцией от других
И? Запрос тоже выполняется на ресурсах базы. А еще можно врубить Function Result Cache, и твоя хранимка будет кешировать результат в памяти и отдавать его на инвокеров моментально. Или ты собрался таблицы целиком в кэш тащить? Ах да, даже в этом случае у Оракла есть in-memory опция, которая в колонкоориентированном формате данные в памяти держит, и ты за инвалидацию кеша не страдаешь.
--
> Так как могу отдать из кеша
Не городи ерунды, если у тебя СУБД лежит, ты не можешь гарантировать актуальности своего кеша никаким образом, и отдавать результат из кеша в данном случае — это выстрел себе же в колено.
--
> Кстати, скомпоновать хранимку, как отдельній образ и потом тиражировать ее — а? Как сделать?
А хранилище данных ты тоже тиражируешь? Зачем тебе её тиражировать, если источник всё равно один? Какую-то глупость опять в качестве примера привёл, и опять притянутую за уши откуда-то. Но даже если тебе это так надо сделать, так у СУБД есть способы горизонтального масштабирования тоже — у Оракла это RAC, Постгря из коробки в кластере умеет работать, и ты с реплики читать можешь. При этом тебе не надо ничего «тиражировать» руками — оно всё растиражировано уже за тебя. Воспринимай хранимку не как «код», а как «данные», и все встанет на свои места. Нет никакой разницы, дёргать данные запросом, или вызовом хранимки (с точки зрения потребителя).

Ладно, я устал с тобой спорить — я тебе про Фому, ты мне про Ерему.
---
Хранимка не создает нагрузки — это такой же враппер, как и метод твоей рест апишечки. Нагрузку создает запрос, который эта хранимка выполняет. Если у тебя один запрос кладет базу, ты хоть замасштабируйся свои микросервисы, ты уже огреб, никакая нода из твоих 100500 не будет возвращать результата. Здесь не о чем рассуждать.
---
И я ничего не говорил о больших монолитах. Хранимки чувствуют себя одинаково, что в большом монолите, что в маленьком датасторе микросервиса, они, так сказать, architecture agnostic.
---
Я попытался объективно показать, что у инструмента есть область применения, ты в ответ «канари деплоймент», «лучше вообще их не писать», «это косяк проектирования». Если ты не умеешь их готовить — не используй. Но это не означает, что инструмент говно.

Ситуация отделения одной хранимки от другой — это какой-то экстремальный кейс, если честно, когда действительно бизнес-логика целиком реализована в БД. Так делать не нужно, это действительно антипаттерн. Но есть разные уровни API реализованные на хранимом коде — почитай про TAPI, QAPI, XAPI. И выделение «жирного» нечитаемого запроса в гораздо более удобоваримую хранимку, которая работает с промежуточными выборками никак не относится к «вымирающему виду», в который ты всё пытаешься ткнуть меня носом.
---
Ну в корне ты не прав, если считаешь, что использование хранимок ограничивается «базой». Если речь про Оракл — любая хранимка легким движением руки превращается в REST endpoint примерно за минуту, если ты поставил ORDS (Oracle REST Data Services). И масштабировать ORDS горизонтально можно хоть до бесконечности, если тебе так надо. Другие программные интерфейсы тоже есть (JDBC, ODP.NET, cx_Oracle) — не понимаю в чем здесь проблема возникла. Все эти способы весьма «малой кровью».
---
К другим «набросам»:
* Стабильность — у хранимок она выше, чем у прямых SQL запросов, потому что пишут их обычно люди, которые знают как работать с данными
* Масштабируемость — скейлинг хранимок пропорционален скейлингу самой базы
* Безопасность — она выше у хранимок, это дополнительный уровень инкапсуляции, что позволяет навесить дополнительное логирование, обработчик ошибок и более точечно настроить права доступа при необходимости
* Возможность построить CI/CD — liquibase, flyway вам в помощь
* Возможность «низкого входа» — не очень понимаю сути этого тезиса, но я бы к базам профанов не подпускал и близко, тем более если речь идет об ынтырпрайзе — pay-per-loser здесь сильно выше в долгосрочной перспективе, чем условный «профит» от уменьшения pay-per-user
---
Архитектура не на хранимках, а с использованием хранимок. У каждого инструмента есть область его применения. Микроскопом забивать гвозди тоже можно, но не стоит, это очень дорого и неэффективно. Также как и совать HDFS-решения налево и направо. А рассуждаю я как раз с точки зрения System Architect, и понимаю что такое скейлинг системы со временем, и его меинтеинабилити.
---
По моему опыту схема, когда поддержкой работы с данными занимается команда, которая знает как работать с данными, гораздо эффективнее в общем случае, чем когда у тебя 100500 разных доменных команд, каждая из которых начинает пулять свои говно-запросы в базу и потом обрабатывать выборку построчно и параллельно рождая отдельный запрос на каждую строку выборки. Большинство Spring-разработчиков, херачащих свои рест-апишечки вообще не вдупляют как там запросы писать, им главное JSON в респонс-боди захерачить, и готово.
---
Мой мессадж был не в том, чтобы бизнес логику писать в базе, мой мессадж был в том, что «хранимки» как класс — это инструмент, имеющий применение, и даже в нашу эру очень интеллектуальных оптимизаторов запросов, порой эффективнее обработать данные в несколько шагов в PL/SQL, чем героически херачить монструозный SQL на 10 страниц, к которому оптимизатор не знает с какой стороны потом подойти.

Наверное ещё более неловко вам оттого, что сначала вы во главу угла ставите транзакции, размазанные по сервисам, и типа хранимки говно поэтому, а теперь про «слабую связность» компонент напоминаете. Непоследовательный вы какой-то.
---
Если ваша цель — понаваливать на хранимки ради того, чтобы понаваливать — окей. Компетенция «писателя хранимок» — это компетенция разработчика баз данных наряду с умением моделировать схему данных или оптимизации запросов — здесь нет ничего сверхестесственного.
---
О каком «нуле» при переиспользовании кода вы здесь говорите — мне тоже неясно. Как раз таки грамотно написанная хранимка — это ключ к переиспользованию кода другими компонентами, так как хранимки по определению — это инкапсуляция кода без изменения его интерфейса, это дополнительный уровень безопасности и оптимизации (так как хранимка лежит в базе в скомпилированном и распарсенном виде).
---
Надо вам дёргать хранимку как обычную таблицу в базе — Pipelined Table Functions вам в помощь.
--
Надо вам дёргать другой сервис в ходе транзакции — окей, дайте сервису-инвокеру нормальный фидбек, и дёргайте ваш сервис нотификаций/отправки емейлов. А лучше делайте это асинхронно — один сервис пишет транзакцию, другой мониторит некую табличку на факт необходимости отправки нотификации, и взводит флажок/флажки, что нотификашка ушла.

Я что-то если честно не очень понял сути спора — в обоих ваших случаях, что с хранимками, что без них и с вашим «новомодным» мидлом на спринге, у вас всё равно курсор запроса, хоть там, хоть там. И если у вас запрос настолько тяжёлый, что в резалтсете тащит терабайты записей, ну ничего вы с этим не сделаете. Другой вопрос, что юзкейс какой-то странный, хоть для кровавого ытнтырпрайза, хоть для чего.
---
В реальной жизни даже отчёты, которые ходят по очень большим объёмам данных для вывода результатов, обычно выводят не так уж много данных сами по себе. И PL/SQL нужен не там, где у вас вся база на клиента отправляется, а как раз в таких случаях. И решать вопросы PL/SQL на SQL это такое же извращение, как ходить по курсору FOR LOOP и для каждой строки запускать отдельный UPDATE.
---
PL/SQL или любые другие хранимки гораздо более эффективны, когда как раз надо реализовать древовидную логику обработки данных, когда на промежуточном результате одного запроса в зависимости от каких-то условий запускается следующий запрос. Таким образом вы исключаете оверхед по памяти, сети и вводу-выводу на несколько порядков.
---
И если вы так хотите размазывать транзакции по куче компонент — никто не запрещает этого делать — просто используйте эту хранимку как часть вашей распределённой транзакции.
---
Но если вы считаете, что «хранимки это прошлый век» только потому, что они не такие модные, как херачить пайплайны на Кафке — ну фигово, че. Всё зависит от уровня абстрации, на котором вы работаете. Слишком сложные SQL запросы станут таким же легаси через год, потому что никто не будет в них вникать. Ваша размазанная логика по десятку компонент станет легаси ещё раньше, так как компоненты меняются, и также никто не будет вникать в их связность уже через полгода. Такой подход копает яму вам куда глубже, чем использование хранимок для поддержания атомарности выполняемой транзакции.

Это также как они условный АльтЛинукс или Стар Линукс «отечественными операционными системами» сейчас называют, и «импортозамещают» везде.
--
Даже интересно сколько бы времени прошло до того момента как это появилось бы в следующем релизе «отечественной» ОС/СУБД, если бы во «вражеском» мастер-дистрибутиве (или оригинальном «чужом» потсгресе) в код какую-то закладку бы добавили.
--
Неужели они действительно не понимают, что называть форк системы с открытым исходным кодом «собственными» разработками это как минимум глупо? А может быть и опасно (смотри выше). Вряд ли они прям досконально изучают все изменения ядра при ребейзе их продукта.
--
И ладно бы собственных разработок не было, а так то они есть, особенно если говорить о СУБД — YDB, Clickhouse, Tarantool

Спорим, если разработчики оригинального «вражеского» Постгреса закинут закладку в код, то она через какое-то время появится в «отечественном» и импортозамещенном Постгрес Про? Сильно сомневаюсь, что они там все изменения ревьювят при ребейзе своего форка. В частности поэтому говорить об «отечественности» продукта здесь как минимум глупо, а как максимум может быть и опасно.

Я не знаю кто там у вас брал Оракл за поддержку, а в реальности Оракл всегда брали как раз за то, что это очень универсальная СУБД с гораздо более интеллектуальным оптимизатором запросов, нежели в Постгре.
--
Если бы вам довелось поработать в действительно крупной компании и поиметь дело с обеими СУБД, и с тем как например в них обеих организована та же мультиверсионность данных для реализации уровней изоляции транзакций, вы бы поняли о чем речь. А если коснуться оптимизатора с обратной связью от исполнителя запроса, что отсутствует напрочь в Постгре, то там вообще лес непаханный.
--
И это только то, что касается Core Database, потому что как здесь уже справедливо было замечено, Оракл это гораздо больше, чем просто СУБД, они предлагают полноценную платформу, также как и Амазон, например. Если взять только спектр работы с данными, то это как минимум Oracle Database, MySQL, Oracle Data Integrator, Oracle Exadata, Oracle Rest Data Services, Oracle Application Express, Oracle BI, Oracle GoldenGate и так далее.
Копнув глубже, вы осознаете, что Java, Oracle Linux, GraalVM, Virtual Box и куча других решений для мидлвари тоже они.
--
Так что можете радоваться дальше импортозамещению Оракла на «отечественный» Постгрес Про, хотя ничего хорошего все эти события, увы, не сулят.

"
пока на рынке не появится таких же весомых конкурентов с чисто российской СУБД, которые захотят оспорить. Но таковых пока нет
"
YDB — распределнная реляционная СУБД с полной поддержкой ACID, что делает ее сильно привлекательнее, чем тот же Постгрес в современных реалиях. Целиком разработка яндекса, действительно «отечественный» продукт, недавно выложенный в опенсорс — почему не хайпить ее? Сложнее миграция? Так вам всё равно добрые 80% переписывать.
--
Clickhouse — тоже разработка яндекса, опенсорс
--
Tarantool — разработка ВК/МейлРу
—
В принципе все сегменты покрыты вполне адекватными продуктами. Зачем называть немного допиленный форк СУБД с открытым кодом «отечественной разработкой»? Чтобы что? Утереть кому-то нос?