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

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

Давай на минутку представим несколько вариантов выполнения системы. Первый: бизнес логика на своем сервере, БД на своем сервере. Второй: бизнес логика в своем контейнере, БД в своем контейнере, сервер один, логика с сервером общаются по unix-сокету или другому IPC. Третий: бизнес логика и БД находятся на одном сервере и в одном пользовательском пространстве, но в разных процессах, общаются так же через IPC. Четвертый: бизнес логика и БД работают в одном процессе. но независимых потоках, IPC служит только для отправки сигналов меж потоками и синхронизации доступа к передаваемым блокам памяти (Firebird embedded). Пятый: бизнес-логика и БД являются одним и тем же приложением (SQLite).

Вопрос: в каком месте здесь внезапно появляется «куча проблем», которые «редко компенсируются скоростью»?

Чтобы не затягивать, сразу правильный ответ: нигде, всё зависит от конкретного инструмента, а не выбранной модели.

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

Проблема в том, что SQL по своему развитию застряло где-то в районе 80-х годов. Прежде всего, этот язык не тьюринг-полон, а значит ты можешь делать только те запросы, которые тебе позволено — для всего остального нужен тьюринг-полный оракл или другие расширения. Да, стандарт расширяют, недавно добавили рекурсивные запросы, но этого все равно мало — для тех же многомерных запросов приходится применять отдельный SQL-подобный (но не совместимый) язык. Я же и вовсе считаю, что у SQL на самом деле почти нет сфер применения, где он сияет, то есть, идеально подходит — это как бы общий знаменатель, ни тебе, ни мне, всем одинаково неудобно и никто не в обиде. Собственно, примерно под таким соусом мир захватил и x86 — не потому что он хорош, а потому что им одним можно как-нибудь покрывать миллионы задач.

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

Лично знаком с проектом, где посмотреть версию собственного софта весьма затруднительно. Так что это зависит от рук и инструментов.

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

Монгу не используете, постгрес не используете... а что вы используете тогда?

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

Проблема многих мамкиных архитекторов заключается в том, что им оракл или MS сказал «ACID — это хорошо и всегда нужно», и они послушались. Очень часто требования атомарности, изоляции, и надежности хранения не настолько жесткие, и их уже все равно пролюбили на уровне бизнес-логики или просто клиента, независимо от свойств используемой СУБД. Более того, даже всякие MySQL/PostgreSQL умеют работать в асинхронном режиме, который быстрее, но жертвует свойством Durability.

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

Ладно забей.

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

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

Странно что хранимки так скатились.

Вот сейчас выкатят какой-то современный ЯП, компилирующийся в WebAssembly, которые разбрасывает запрос по кластеру, собирает как scatter-gather, иерархический reduce, tunable consistency, встроенная безопасность, programmable per entity ACLs, REST API на Swagger или по gRPC, семантика Firebase, и все это на кубере, с поддержкой continuous deployment/integration, тестами, версионированием, canarying и все будут сцаться.

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