Еще немножко про DIA и Hiload

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

Чувак, беги оттуда. Логика в хранимых процедурах – это метастазы рака мозга разработчиков.

SQL это стандарт

Это стандарт на который все клали огромный член.

Почему возникли серверы приложений?

Чтобы кучу лапши каждый раз не писать.

которое реализует бизнеслогику внутри СУБД на хранимых процедурах, что, по словам производителя, дает сумасшедшую производительность

да и надежность тоже

зачем вообще нужны все эти серверы приложений

а это ты как админ поймешь, когда попробуешь эту опердень обновить

Нас учили писать хранимые процедуры, и говорили что по другому быть не может

Ты не настолько старый. Видимо, шарашка была совсем убогая. Трёхзвенная архитектура давно известна.

зачем вообще нужны все эти серверы приложений

Тебе примеры из реальной жизни или просто логическое обоснование? Если стараться одним единственным аргументом бить, то достаточно сказать, что БД плохо масштабируется, а приложения хорошо.

Ок

Сервер приложений - он для логики и есть. Тупые ретрансляторы пишут только тупые вайтишники. Плюсов вагон, один шардинг чего стоит.

Млин, опять попался

метастазы рака мозга разработчиков

Только если на них целиком вся логика написана.

А так, это предубеждение родилось в головах современных неосиляторы РСУБД. Те, кто умеет готовить MySQL/PostpgreSQL встречаются всё реже, а бестолковые монго-клоуны всё чаще.

по словам производителя, дает сумасшедшую производительность

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

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

И, да, неужели необходима такая вот производительность ценой сопровождаемости решения?

Скажите, это что, откопали стюардессу?

Скорее не смогли закопать. У логики в бд есть куча проблем, очень редко скорость работы способна их скомпенсировать.

Только если на них целиком вся логика написана.

Да нет. Даже небольшой пачки хранимых процедур достаточно, чтобы поиметь лулзов и головной боли с миграциями. Если версию софта, который у тебя запущен, посмотреть довольно тривиально – во всех нормальных проектах есть API для этого, то какая именно версия процедурок у тебя в базе – сходи да посмотри.

Так что нет, чувак. Базы данных – они для данных.

Те, кто умеет готовить MySQL/PostpgreSQL встречаются всё реже, а бестолковые монго-клоуны всё чаще.

Илитка подъехала. Я почти нигде не видел живой монги, потому что слава у неё так себе. Но в тех полутора проектах, где она была, особых проблем не случалось. А вот на кривонастроенный постгрес и быдло-DBA, из которых понты прямо рекой льются и база которых еле кряхтит и с трудом тянет, я видел довольно много.

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

Сначала пытался понять, а потом увидел автора. Уволься, пройди нормальные курсы (foxminded, например), устройся на нормальную работу. Обсуждать просто бессмысленно, у тебя лютая каша в голове.

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

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

если тебе еще под соусом хайлоада такое будут предлагать, то это дно беспросветное.

посмотреть довольно тривиально – во всех нормальных проектах есть API для этого

Абсолютно аналогично, только выплёвывает не только версию приложения, но и версию БД. Само же приложение либо на старте дёргает библиотечную функцию, которая выгребает версию из таблички миграций и падает, если что-то не так, либо перед стартом сначала пускает мигратор. Всё тривиально.

Я подхватывал и капитально перерабатывал ИС с кучей процедур, а потом ещё усугублял (на самом деле нет) всё триггерами, и разрабатывал идемпотентный мигратор к этому. Разрабатывал антифрод совсем без процедур. Даже в разработке очень амбициозного ETL-велосипеда успел поучаствовать. Короче, чуть-чуть в БД разбираюсь. Процедурофобию за это время так и не подхватил.

Илитка подъехала

Что поделать. Когда узнаю, что люди статистику в монге считают, меня корёжет. Да и постгрес с кучей ненужных индексов и внешних ключей, перезаписывающий в цикле миллионов по 200 записей в час (балк инсерт с апдейом при конфликте — фактически постоянная перезапись, потом дроп спустя какое-то время), я тоже видел.

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

хайлоада такое будут предлагать, то это дно беспросветно

Тут лорчую.

Но ты не обобщай. БД далеко не только для веб-бекендов используют.

это подход 15-тилетней давности. тогда машины были не такие быстрые как сейчас

Когда вам надо посчитать средний чек за месяц по базе заказов в которой (ну например) 10 миллионов заказов в день, вы вытаскиваете все 300 миллионов в свой правильный микровсервис и там считаете?

Нет конечно - вы, внезапно, начинаете использовать те же самые sum/avg/min и прочее, которое есть ничто иное как те же самые «хранимки» (ага, хранимые оконные функции, просто они есть в некоем «стандарте»).

Или как всегда - #вынепонимаете #этодругое ?

Дно беспросветное это когда путают бизнес-логику в хранимых процедурах и элементарные операции (по сути библиотеку), типа кастомных типов данных и расширений

Когда я учился, нам говорили клиент-серверное приложение это когда приложение шлет запросы к реляционной СУБД

Я не понял, все выщеотписавшиеся серьёзно смогли прочитать дальше этой фразы?

Дорогой Шульман, найди себе простую работу «делай раз / делай два» в зарубежной конторе. Где все объяснят и покажут. Позаработаешь, подучишься, при попытках поговорить помалкивай, кашу в голове не демонстрируй. Самообразуешься, тогда иди в философию и архитектуру.

Ну не особо то и удачное обобщение.
sum/min это что-то не относящееся к доменной области бизнеса и не имплементирует какие-то бизнес процессы.
С тем же успехом в субд может быть расчёт графов, географических координат и тому подобные функции. А если они ещё и будут в этом вашем «стандарте» будет ещё проще, ведь эти функции можно будет вызывать без привязки к субд.

А вот всякая дичь, уровня бизнес логики - это рак.

Это однозначно другое.

все выщеотписавшиеся серьёзно смогли прочитать дальше этой фразы?

Это же Штульман, я ни капли не удивился.

какая именно версия процедурок у тебя в базе – сходи да посмотри

вот как нехрен вообще, если логика в биде родилась не сама по себе, то уж контроль версий предусмотреть не проблема

Почему возникли серверы приложений?

По моему невеликому опыту пользователя, проще один раз настроить и админить сервер приложений, чем каждый раз настраивать клиент Оракла на каждой машине сотрудников.

Скажите, это что, откопали стюардессу?

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

SQL это стандарт и в принципе приложение можно научить работать с несколькими реализациями СУБД?

Ага. А иксовые приложения можно делать с интерфейсами и Qt, и GTK одновременно :)

Новые версии стандарта поддерживаются частично (и, естественно, разные базы поддерживают разные части), а скорость одной и той же операции может сильно отличаться на разных серверах БД.

Это не бизнес логика, а аналитика. Это совершенно другой, узкоспециализированный класс задач. Это первое, а второе - вы сейчас функции высшего порядка к хранимым отнесли. Это, мягко говоря, не корректно

Это, кстати, очень большая проблема - контроль версий исходников хранимых процедур. В свое время даже оракл ничего внятного не предложил. Все костыляли как могли внешними скриптами. Как сейчас на этом фронте даже не представляю. Никто сейчас решения на хранимках не делает

Когда я учился, нам говорили, что «клиент-серверное приложение это когда приложение шлет запросы к реляционной СУБД», например MS SQL 2000 или Interbase (было это уже давненько и другого мы тогда не знали, ах да был еще божественный Oracle).

В какой заднице ты обитал и учился?

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

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

После этого я арендовал криокамеру и она потекла когда во всю орудовали серверы приложений

X.Org, между прочим, тоже не монолитное ПО, хоть и не работает с СУБД. Как же долго ты спал, Филипп Дж. Фрай?

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

В калабаню такого работодателя. Сам задолбаешься решать проблемы при малейшей несовместимости, так ещё и наверняка там в директорах типичный НР, который ни бум-бум в компьютерах и считает, что программист пишет программы в Word.

Почему возникли серверы приложений?

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

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

где там очень большая проблема?

В миграциях.

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

далекие 15 лет назад, когда деревья были выше, а трава зеленее, разработка логики в хранимых процедурах была нормой. для этого даже свои IDE были. беда только в том, что редактор кода работал с базой напрямую и валидация,тестирование и дебаггинг были через сохранение этого кода в саму базу. т.е. это было ни разу не редактирование файла,который бы можно было сразу же коммитить в какой-нибудь svn, это значит нужно было вручную сохранить это в файл и потом уже проводить все необходимые манипуляции. если вы работали с большими проектами, то знаете, где таких хранимок достаточное количество (в моем случае это было 2 или 3 сотни), а если часть из них еще и увесистые (в моем случае это в районе 1К строк на хранимку), то масшаб возни с файлами и svn/git просто запредельный. вот в этом не просто очень большая проблема, а просто ГИГАНТСКАЯ проблема. это вам не миграции по добавлению или удалению нескольких строчек написать. масштаб другой. я эту боль проходил, так что пишу это не с чьих-то слов, а имея достаточный опыт судить об этом.

ПС: да, я уже не говорю про проблемы масштабирования такого подхода. в те времена были вынуждены использовать mat.view для этого, но они имел свойство ломаться (мы, конечно подпирали костылем в виде полного рефреша раз в несколько часов, но это была боль, как ни крути). так что, извиняюсь, но ни один довод сейчас меня не убедит использовать хранимые процедуры. только штатные функции аналитики sql для выборки данных.

ППС: ой, совсем же забыл про деплой. это же отдельная сказка. стоит только чуть-чуть упустить из виду мелочь, которая инвалидирует твою процедуру как все зависимые объекты инвалидировались и нужно было рекомпилять весь этот колхоз вручную. извиняюсь, но в это ад обратно я не вернусь, а если контора скажет заниматься этим мазахизмом - сорян, это будет поледний день работы в этом болоте.

Когда вам надо посчитать средний чек за месяц по базе заказов в которой (ну например) 10 миллионов заказов в день, вы вытаскиваете все 300 миллионов в свой правильный микровсервис и там считаете?

Ты вот правда сейчас предлагаешь хранить вот это всё в ОДНОЙ базе? Без кластеризации и партишонинга?

Да нет, в миграциях есть очень большая проблема. Например, не всегда миграции можно нормально откатить.

были вынуждены использовать mat.view для этого, но они имел свойство ломаться

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

Ооо, вспомнил этот ужас, какое счастье, что сертифицированный oracle dba нас покинул, а программист, нежно любящий всё это говно - спился.

прям исповедь неосилятора какая-то

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

PL/SQL Developer никуда не делся

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

где-то тут эмоции перевесили содержание. гнусный редактор не давал коммитить не глядя или что?

файл и потом уже проводить все необходимые манипуляции. если вы работали с большими проектами, то знаете, где таких хранимок достаточное количество (в моем случае это было 2 или 3 сотни), а если часть из них еще и увесистые (в моем случае это в районе 1К строк на хранимку), то масшаб возни с файлами и svn/git просто запредельный

каждый день все 2-3 сотни хранимок по 1К строк переписывать — сложно, да. хорошо, что никто так не делает.

извиняюсь, но ни один довод сейчас меня не убедит использовать хранимые процедуры. только штатные функции аналитики sql для выборки данных.

а я никого не пытаюсь убедить, вообще-то. вопрос не в том, хочется кому-то вернуться туда, где с логикой в базе работали через одно место, а в цитата, «очень большой проблеме» контроля версий исходников и я пока не увидел, где же тот фатальный недостаток, который не дает хранить версии в SVN

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

может быть это очень большая проблема хранения версий исходников? тоже не похожа, если честно.

define нормально откатить. можно вообще не написать rollback скрипт и никак не откатить, а можно написать его неправильно и откатить ненормально. но где та очень большая проблема, которая мешает написать его нормально и нормально откатить?

Классическую субд сложно масштабировать вширь. Условно говоря ты купил два сервака с 2х56 головыми ксеонами, кучей памяти, nvme или сетевыми хранилками и соорудил из них реплику. Пока этого хватает для рабочих нагрузок - все ок. Но что делать когда перестаёт хватать? У крупных производителей типа oracle есть решения и кластерные и через эмуляцию одного большого сервака через пачку лезвий, но это стоит больших денег и ты привязан к вендору. Альтернативное решение - запихать в сервер приложений бизнеслогику, а базу использовать как простую хранилку. Сервер приложений(если подумать об этом на этапе разработки) можно масштабировать докидывая новый сервер, а если ещё и базу шардировать, то можно и ее таким же образом масштабировать(правда добавляется этап переноса кусочка данных на новый сервак при добавлении нового). Но для некоторых задачек и некоторых масштабов хранимки дают бОльшую производительность за счёт локальности данных, т.е. их не надо дополнительно гонять по сетке между базой и приложением и при этом заниматься сериализацией/десериализацией

прям исповедь неосилятора какая-то

вся индустрия неосилила и пошла дальше, но у вас на этот счет свое собственное мнение. не вопрос, жажды переубеждать нет :). успехов вам в делах ваших.

каждый день все 2-3 сотни хранимок по 1К строк переписывать — сложно, да. хорошо, что никто так не делает.

вы откровенно передергиваете. признак отсутствия аргументов.

забей, человек застрял лет 10 назад в технологиях и ему там комфортно.

вся индустрия неосилила и пошла дальше

прям вся? я вот практически каждый день пользуюсь сервисами, у которых под капотом хранимки и миллионы людей вместе со мной. прям начиная с утреннего созвона и заканчивая смской о начислении зарплаты.

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

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

вашему островку самобытных решений
ваш подход в разработке
будете старыми дедовскими методами вытягивать бегемота из болота

не рекомендую

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

где та очень большая проблема, которая мешает написать его нормально и нормально откатить?

Есть миграции, которые удаляют данные. Есть миграции, которые просто очень долго и дорого запускать, и поэтому откатывать-накатывать в живой среде – так себе затея. Добавь к этому тот факт, что баги оооооочень часто находятся не сразу. Можешь ли ты откатить миграцию, после которой был ещё десяток? Сомневаюсь. git revert сделать гораздо проще.

И вот из-за всего этого писать логику в хранимых процедурках – крайне дерьмовая идея.

Есть миграции, которые удаляют данные.

то есть сама идея «физически удалять данные в базе» тебя не смущает, понятие deleted флага тебе тоже не знакомо?

Есть миграции, которые просто очень долго и дорого запускать, и поэтому откатывать-накатывать в живой среде – так себе затея

я начинаю сомневаться, что ты хоть раз видел вживую систему с логикой в биде. кто ж тебе даст туда-сюда откатывать-накатывать просто так, максимум — накатили, отроллбэчили, накатили пофикшенную. на четвертый раз пробудится Древнее зло из DB архитекторов и выгонит всех из избушки

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

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

то есть сама идея «физически удалять данные в базе» тебя не смущает, понятие deleted флага тебе тоже не знакомо?

А ты их не удаляешь, что ли? Вообще никогда? А если миграция, наоборот, добавила какую-то колонку, что тогда делать?

на четвертый раз пробудится Древнее зло из DB архитекторов и выгонит всех из избушки

Хахахаха! Господи, вера во всесильных и мудрых архитекторов баз данных – это так мило! ergo там выше всё правильно расписал.

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

Код приложение одинаков и на компьютере разработчика, и в CI, и в продакшене. Базы данных – нет. Покрыть его типами и тестами и хоть как-то удостовериться в его корректности проще и дешевле выходит.

Да мне не интересно вам что-то советовать. Я скорее для других читающих даю пищу для подумать. Есть шанс, что поймут насколько это полная дикость в 21году делать решения с бизнес логикой бд. В вашей палате все хорошо и без меня 😄

А ты их не удаляешь, что ли? Вообще никогда?

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

А если миграция, наоборот, добавила какую-то колонку, что тогда делать?

если тебе добавленная колонка ломает миграцию или роллбэк — дело явно не в бобине

Код приложение одинаков и на компьютере разработчика, и в CI, и в продакшене.

а данные нет и что с того?

Базы данных – нет.

а если да?

Покрыть его типами и тестами и хоть как-то удостовериться в его корректности проще и дешевле выходит

и это, конечно же, очень большая проблема миграции?

ну и насчет «дешевле» — я с удовольствием посмотрю на сравнение стоимости реализации (или не дай ТНБ переписывания) к примеру биллинга в базе и на любом ЯП на твой выбор. ну или на то, в какую сумму тебе обойдется реализовать обработку данных в сервере приложений с приемлемой для, например, трейдинга задержкой

Позвольте я отвечу за господина, которому вы тычете биллингами. Просто именно их я разрабатывал больше 10 лет и именно в те времена эксплуатировалась история с логикой в бд. И ровно по той причине, что я имел счастье и боль разрабатывать/обслуживать биллинг ШПД Билайна на всю страну (не считая ещё и биллинга для IP voice), могу сказать, что самая боль именно в разработке и именно в росте нагрузки была именно бд. Но тогда были другие инструменты. Будь на дворе год так 2009-2010, я бы был в этой дискуссии на вашей стороне. Но сейчас все ушло сильно дальше, посему эти подходы сейчас скорее антипаттерн. Нравится вам это или нет.

Боюсь, вас не пробить ни одним доводом или аргументом, засим кланяюсь и удаляюсь.

ну и насчет «дешевле» — я с удовольствием посмотрю на сравнение стоимости реализации (или не дай ТНБ переписывания) к примеру биллинга в базе и на любом ЯП на твой выбор. ну или на то, в какую сумму тебе обойдется реализовать обработку данных в сервере приложений с приемлемой для, например, трейдинга задержкой

Извиняюсь, забыл на это ответить- мой ответ: легко. С масштабированием и лейтенси достаточным обслуживать 500k-1000k rps. С современными технологиями это очень легко делается. В качестве доказательства посмотрите мой бенчмарк на гитхабе где показываю 260к синхронных запросов в секунду на ноуте. (github.com/halturin/ergo). Эта технология невероятно легко масштабируемая и выдать ТТХ что вы запросили весьма несложно

ПС: речь про ААА, разумеется для радиуса или диаметра

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

что касается «ушло сильно дальше» — уход в прошлое систем с логикой в БД вызван не появлением каких-то супер-инструментов или супер-отсталостью БД. единственное, в чем реально проигрывают БД-ориентированные системы — это в легкости обслуживания и апгрейда обезьянами. в 2020х дорого не обслуживать базу, дорого держать на постоянке штат людей, которые смогут заниматься ею в случае чего, а платить им постоянно. иметь штат людей, которые могут «и на жабке пописать и лендинг подправить» тупо удобнее, чем иметь отдел сумрачных бидешников, которых ни уволить ни заменить.

очень хочется позубоскалить на тему того, для чего использует одна там компания cloud platform to enrich services а для чего хранимые процедуры, но это будет некорректно и наверное нарушением NDA