Годные альтернативы для MS SQL и Oracle RDBMS

Переезд с базы на базу всегда боль и больше зависит от приложения которое эту базу использует, может там есть orm и все ок, а может sql с специфичным синтаксисом. Врапперы - ни разу не встречал и не думаю что это жизнеспособно опять же из-за специфичного синтаксиса.

объёмом базы порядка пары миллионов (миллиардов)

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

числом пользователей до 100-1000 человек (клики мышкой через веб-морду)

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

В остальном вроде выше правильно сказали, что сильно зависит как от приложения, так и от того, что лежит в базе. Если вы заранее обмазались orm или генераторами sql, то это сильно облегчит переезд, но при этом ddl напрямую всё равно не перенести. Если у вас есть логика в БД, в виде, например, хранимок, то тут всё еще хуже, придется переписывать. Для постгреса есть официальные гайды по переносу кода с pl/sql на PL/pgSQL, но это всё равно придется делать ручками.

говорят ещё Firebird используют

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

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

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

1. utf-8 занимает константно три байта на символ (даже если строка в ascii).
2. 1000 байт на PK, были проблемы когда в PK входят несколько колонок включая например VARCHAR.
3. 64 килобайта совокупно на строку таблицы, если в исходной табилцы 15 колонок с VARCHAR(2000 CHAR) то это за пределами mssql.

Миграция с Oracle на PostgresSQL и MSSQL необходимости в реорганизации структуры базы или обрезания данных не потребовала. И еще субъективные впечатления остались, что PSQL и MSSQL круты но последняя делала выборки быстрее. Тюнингом баз не занимался.

А еще опыт подсказывает что не все СУБД позволяют посмотреть историю запросов или хотя бы вывести топ самых тяжелых запросов, а ведь это помогает диагностировать проблему. Прямо сейчас загуглил инфу об mysql похоже там получить историю запросов можно только окольными путями. С postgres лучше, но тоже не все гладко. В общем не рекомендую mysql/mariadb.

Мастер-мастер уже завезли нормальный?

Куда, в оракл? Не знаю.

в оракл?
Не знаю

но мнение имеешь, как это мило

1. utf-8 занимает константно три байта на символ (даже если строка в ascii).

Есть же опция ASCII. Ну и сейчас лучше utf8mb4 использовать.

64 килобайта совокупно на строку таблицы, если в исходной табилцы 15 колонок с VARCHAR(2000 CHAR) то это за пределами mssql.

Есть же TEXT.

Есть же TEXT.

он же LONG

но мнение имеешь, как это мило

Но я пытался, честно. Даже Master-Slave репликацию делать. Там всё убого через dblink.

Ну более мило бы было, если бы ты поделился своим опытом.

через dblink

а не через archivelog ?

archivelog это что-то типа wal log в постгре. На практике всё плохо получается. Везде куча нюансов.

postgres, естественно

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

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

Какие есть альтернативы базам данных MS SQL и Oracle?

На память приходит только PostgreSQL и MariaDB/MySQL.

Тут на днях xbase++ обсуждали. Откопали Clipper, порвали два баяна.

Владимир

Да в harbour разработчик - гений /и это не сарказм/.
Из prg кода получать си код - ИМХНО хорошая мысль.
Да vm у него хорошая.

PS: Ни к тому, что Clipper является «языком моей мечты».
В core разработчик предоставил много хорошего API /если кто понимает о чем идет речь/.

гибко переключаться между базами СУБД

Ни в коем случае.

данные с кучей пустых колонок

Это в итоге денормализации или просто отсутствие DBA? Постгрес умеет экономить место если пустая колонка — NULL, но в постгресе " != NULL (как в оракле) со всеми вытекающими

пары миллионов (миллиардов) записей

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

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

ODBC как обычно

MySQL/Maria в режиме key-value или PostgreSQL, где ключевые данные кидаются в полноценные столбцы, а вспомогательные - составным типом или тупо одним текстовым/блоб полем. У обоих подходов есть плюсы и минусы, и оба подхода лучше MS SQL/Oracle.

И еще субъективные впечатления остались, что PSQL и MSSQL круты но последняя делала выборки быстрее. Тюнингом баз не занимался.

Это правда, постгрес работает немного медленнее MS SQL. Но за те деньги, которые просит мелкософт, обычно вопроса выбора не возникает. Это буржуи в транснациональных компаниях могут позволить себе выкинуть $50k на сервак для своей фирмы на 100 человек, а в СНГ немного другая ситуация.
Так-то да, MySQL несерьезная база вообще, но просто я не совсем знаю, что нужно ОП-у, вдруг там что-то несложное и мускуль прокатит.

Она уныла.

Мастер-мастер уже завезли нормальный?

Master-master - это довольно проблематичная штука сама по себе, на самом деле. Если делаешь асинхронное, то получаешь поломанные базы. Если делаешь синхронное, то получаешь задержку, и, внезапно, два мастера работают медленнее одного. И зачем это нужно?
Больше похоже на маркетинг, чем на реальное решение проблемы. Типа шеф сказал «репликацию хочу! Шоб до конца недели была репликация!», и что ты ему докажешь? Он же денежку платит, если он окажется неправ - ты не пострадаешь, если он окажется прав - ты будешь молодец. А если пойдешь против и окажешься неправ, то ты бездарь и во всем виноват.

Так-то да, MySQL несерьезная база вообще, но просто я не совсем знаю, что нужно ОП-у, вдруг там что-то несложное и мускуль прокатит.

Да я просто думаю, на что могли бы заменить MSSQL в гос.организациях.

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

А стандарта SQL как обычно не хватает для полноценных СУБД?

Я просто давно его читал, лет 20 назад.

Да я просто думаю, на что могли бы заменить MSSQL в гос.организациях.

«Просто думаю»? Тогда я тебе дам информацию для размышлений: в гос организациях нет квалифицированных людей и в гос организациях основная форма доходов - это распилы и откаты. Соответственно, на постгресе и мускуле не откатишь, а квалификация для работы с ними нужна. Потому, только MS SQL и оракл. Причем, продавцы этих продуктов хорошо знакомы с ситуацией. У MS абсолютно точно есть утвержденный откатный бюджет.

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

У меня были лишь некие подозрения на этот счёт.

1. Организация купила лицензионные WinXP, по факту в коробках лежали Basic. Потом АИС за > 1 млн.руб. До этого была АИС за 55 т.р.

2. В другой - распил 2 млрд.руб. за три года - поставили сырую энтерпрайз-систему на Oracle (несколько серверных стоек), и срочно начали искать специалистов под неё. До этого всю работу выполнял обычный 2-ядерный стационарник +софт из другого региона (не ДС).

3. Неэффективная АИС, по которой стоимость контракта на доработку SQL-кода в разы превышала годовую зарплату двух штатных программистов, которые могли бы всё сделать сами быстрее и лучше. Порядка сотни сотрудников сидели на виндах, якобы лицензионных. И мощный сервер на MSSQL. До этого всю работу выполняла обычная машинка, стационарник +софт из пары регионов (не ДС).

И т.п.

Но доказательств конкретных нет. Всё гладко.

Видимо, у проверяющих организаций нет другого выхода, кроме как плюнуть на всё это дело? Или ДС/ДС2 заруливает этот вопрос в нужном направлении?

Видимо, у проверяющих организаций нет другого выхода, кроме как плюнуть на всё это дело? Или ДС/ДС2 заруливает этот вопрос в нужном направлении?

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

У обоих подходов есть плюсы и минусы, и оба подхода лучше MS SQL/Oracle.
Так-то да, MySQL несерьезная база вообще, но просто я не совсем знаю, что нужно ОП-у, вдруг там что-то несложное и мускуль прокатит.

что-то у вас файлы не сходятся, молодой человек

Потому, только MS SQL и оракл.

потому что квалификация не нужна?

Потому, только MS SQL и оракл.

потому что квалификация не нужна?

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

дошколят, знакомых с ораклом/MSSQL, проще найти

спасибо, поржал с ыксперта

https://youtu.be/d1vRLfuF-wM

А я поржал с тебя. Ты подумал, что объегорил папку, ведь ты знаешь, что в яслях работают за еду на PHP+MySQL, но ты упускаешь из виду, что MySQL - это не база данных, потому выпадает из ряда PostgreSQL-Oracle-MS SQL.
Я не спорю, что государственные сайтики прекрасно пишутся на связке PHP+MySQL с бюджетом 500 рублей, но базы данных с большим числом клиентов и продвинутой серверной логикой в таком режиме уже не напишешь, а нужно хоть как-то отчитаться за распиленный бюджет, потому нужно нанимать более квалифицированных дошколят, которые могут мышкой написать приложение на делфи для работы с ораклом.

что за дошкольную дичь я сейчас прочитал? наблюдаю я таких продвинутых папок периодически, так вы же кроме как apt-get install db_name и не знаете нихера про базы.

в постгресе есть foreign data wrappers, например.

а вообще, при проектировании приложения надо закладывать абстракцию от БД, если тебе требуется её «горячая замена»

например, JPA в джаве для этого.

например, JPA в джаве для этого.

+1, а иначе свой JPA делать, со своим query language, с построителем запросов, для каждой базы свой «диалект». Кста, я такую штуку писал, точнее мы в команде год писали. Потом помню студент пришел и мы начали описывать проект и тут он говорит - «так эта штука просто чтоб передать по сети данные из одной базы в другую?», неловкое молчание и потом пару минут веселья, ведь действительно год потратить на такую простую вещь :)

Зато RAC завезли

Мастер-мастер уже завезли нормальный?

Такой пойдет?

Постгрес под эти цели подойдёт более чем. Mysql - я трогал только пятую версию и не очень часто, и если честно не понравилось. В 8 версии там по красивее все стало вроде бы как, теже with блоки в sql появились.

Какие пригодны для использования в масштабах организаций с числом пользователей до 100-1000 человек (клики мышкой через веб-морду), и с объёмом базы порядка пары миллионов (миллиардов) записей (в основном, «жидкие» данные с кучей пустых колонок)?

Любая СУБД, база данных небольшая. Главное железо хорошее и быстрое.

А я поржал с тебя.

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

MySQL - это не база данных, потому выпадает из ряда PostgreSQL-Oracle-MS SQL.

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

Я не спорю, что государственные сайтики прекрасно пишутся на связке PHP+MySQL с бюджетом 500 рублей

Похоже твой опыт только этим и ограничивается.

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

Опять пустобрехство? Кто или что у тебя «клиенты», заказчики или подключения. Для первых открой для себя, что каждому заказчику нужна система для себя, а что ты там для других накорябал им до лампочки, и данные чужие им тоже не нужны, так же и свои данные они другим светить не захотят. Для второго открой для себя «ПО промежуточного слоя», «пул подключений», «масштабирование», «горизонтальное/вертикальное дробление БД», «репликацию», «кэширование». Забудь о логике в БД, как бы тебе не нравился костыльPL/SQL. Забудь о PHP! Потом открой фейсбук(ни разу не госсайтик), оцени их масштаб, вспомни, что у них как раз PHP+MySQL, начинай плакать, что ты совсем не профпригоден…

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

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

Иди доучивайся, дедуля.

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

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

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

Для второго открой для себя «ПО промежуточного слоя», «пул подключений», «масштабирование», «горизонтальное/вертикальное дробление БД», «репликацию», «кэширование».

У нас бигдата в треде - все в микросервисы!
А если серьезно, то ПО промежуточного слоя - это либо просто тонкий слой между базой и клиентом для ограничения возможностей хакерья, либо костыль вместо так нелюбимого тобой PL/SQL (PL/Python, PL/Tcl, etc). Конечно, если ты не какой-нибудь яндекс. Вот стану яндексом - начну думать о том, что у меня один сервер не может справиться с сотнями тыщ запросов в секунду.
Как ты думаешь, где логика исполнится быстрее: в процессе, который непосредственно крутит сырые данные, или в другом процессе, пусть даже на этом же компе, который по сокету гоняет данные взад-вперед для выполнения той же логики?
Я в курсе, что все эти проблемы не волнуют юных бигдатавцев, которые еще не слышали о целостности данных, но уже знают про репликацию и масштабирование; которые уже выше структурирования данных, но которые еще не знают, какие же данные у них реально лежат в базе и как с этим винегретом теперь работать в «ПО промежуточного слоя» на Node.js. Система дай бог если на миллион, а позиционируется минимум на миллиард.

Забудь о PHP! Потом открой фейсбук(ни разу не госсайтик), оцени их масштаб, вспомни, что у них как раз PHP+MySQL, начинай плакать, что ты совсем не профпригоден…

Судя по всему, ты еще не слышал, что фейсбуку пришлось сделать статическую типизацию для пыха ( https://en.wikipedia.org/wiki/Hack_(programming_language) ), и сделать собственный движок для мускуля ( https://code.fb.com/core-data/myrocks-a-space-and-write-optimized-mysql-datab... ), который, по сути, превращает мускуль в NoSQL. Фейсбук выплачивает проценты по «technical debt», поскольку вовремя не перестроил свою архитектуру.
Таким образом, фейсбук имеет мало чего общего с сайтостроением для самых маленьких, просто, в то время, когда фейсбук только начинался, не было таких развитых NoSQL баз, и эту роль взвалили на плечи MySQL, которое в то время даже не имело транзакций и было больше похоже на MongoDB. Молодежи пример MongoDB будет более близок для понимания ситуации с MySQL в то время, поскольку монга скопировала маркетинговую модель, так же нанимая индусов, ничего не соображающих в построении SQL баз данных, для создания популярного продукта для индусов.

сейчас ты и дошколят не найдёшь со знаниями дельфи

В СНГ - валом. На западе дорого каждому индусу покупать по лицензии.

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

Там вон чел в соседнем свежескошенном треде на ноде вычислял квартплату с требованиями к нагрузкам и удаленной доступности - надо будет у него поинтересоваться.

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

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

под своим логином писать было бы лучше.

Для этого надо регистрироваться

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

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

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

У нас бигдата в треде - все в микросервисы!

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

А если серьезно, то ПО промежуточного слоя - это либо просто тонкий слой между базой и клиентом для ограничения возможностей хакерья, либо костыль вместо так нелюбимого тобой PL/SQL (PL/Python, PL/Tcl, etc).

Всё ясно, с этого и надо было начинать. Твоя ошибка, что ты подменяешь понятия, в наших реалиях ничего серьёзного в одной базе с костыльPL не сделаешь, при этом не надо даже яндексом быть, просто потому, что данные размазаны по разным базам, и не просто по разным базам, а под разными версиями СУБД, по разным СУБД, по разным сервисам, по разным NoSQL. Если у тебя сейчас реалии не такие, я тебя поздравляю, можешь всё делать всё логику в базе, заказчик пусть постоянно наращивает мощь одного компа, просто потому что ты изначально не закладывался на масштабирование. Оно может и хорошо, работа другим программистам, которые будут скорей всего новую уже систему писать.

Конечно, если ты не какой-нибудь яндекс. Вот стану яндексом - начну думать о том, что у меня один сервер не может справиться с сотнями тыщ запросов в секунду.

Просто у людей есть опыт в высоконагруженных распределённых системах, в том числе и СУБД MySQL, в корпоративе ты себе можешь позволить хоть derby или sqlite, можешь и Oracle, только не надо говорить, что из-за фич, и уж совсем смешно предлагать миккимаус, платить мелкомягким за лицензию форточек, кроме самой СУБД, платить за дорогое сертифицированное железо каждый раз, когда надо замасштабироваться, в баню такое счастье, и да, работает оно всё равно хуже мускуля. Если ты изначально схему БД сделаешь жуткосвязанной и всю логику внутри, то потом масштабироваться будет ой как сложно, возможно тебе-то насрать, ты же у нас «Авгий» и пусть другие разгребают твои «конюшни»

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

Нет у нас одной базы, нет у нас нигде всех необходимых данных в одной базе, данные существуют не только в базе, как ты к ним доступ из движка СУБД нам предлагаешь, «гнать байтики по сокету???

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

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

которые уже выше структурирования данных,

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

но которые еще не знают, какие же данные у них реально лежат в базе

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

и как с этим винегретом теперь работать в «ПО промежуточного слоя» на Node.js.

Ну если логика не в базе, то Node.js заменить будет всё таки попроще.

Система дай бог если на миллион, а позиционируется минимум на миллиард.

О таких системах я не веду речь, хотя не вижу там проблем использовать и MySQL

Судя по всему, ты еще не слышал, что фейсбуку пришлось сделать статическую типизацию для пыха ( https://en.wikipedia.org/wiki/Hack_(programming_language) ), и сделать собственный движок для мускуля ( https://code.fb.com/core-data/myrocks-a-space-and-write-optimized-mysql-datab... ), который, по сути, превращает мускуль в NoSQL. Фейсбук выплачивает проценты по «technical debt», поскольку вовремя не перестроил свою архитектуру.

Как раз тот случай, когда ты опять пользуешься «слухами» вместо того, чтоб осознать, что тебе говорят, да фейсбук лопохнулся и стал делать костылики, но это как раз относится к пыху, худшую ошибку сделал только ты, завязавшись на Delfi/Oracle. Насчёт MySQL ты, чёрт тебя подери, очень невнимательно читал, может потому что не понимаешь особенностей строения, а может потому что тебе плевать на MySQL, ведь это же не база данных, с чем мы, конечно же согласились. Но с NoSQL это точно пальцем в небо, но для тебя и NoSQL не существуют, очевидно.

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

Чёрт, что за тупизна, читай заново свою ссылку!

Зачем ты вообще городишь эти слойки?

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

Очевидно, ты сейчас пишешь про внутрикорпоративную софтину,

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

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

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

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

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

Мне кажется, что ты не понял, к чему я это писал. Я писал о том, что средний слой не нужен.

данные размазаны по разным базам, и не просто по разным базам, а под разными версиями СУБД, по разным СУБД, по разным сервисам, по разным NoSQL

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

Просто у людей есть опыт в высоконагруженных распределённых системах, в том числе и СУБД MySQL

И этот опыт не имеет отношения к MySQL. Чем более твоя система становится высоконагруженной и распределенной, тем меньше она отношения имеет к MySQL.

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

Никто не знаком с термином «миккимаус», мне пришлось догадываться, о чем ты пишешь.
Работает хуже, потому что ты сказал, или потому что ты не видел тестов производительности? У MS SQL есть единственный конкурент - это Oracle. У них обоих проблема одна - очень высокая цена лицензий. Стоимость железа и ОС на этом фоне меркнет.

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

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

Нет у нас одной базы, нет у нас нигде всех необходимых данных в одной базе, данные существуют не только в базе, как ты к ним доступ из движка СУБД нам предлагаешь, «гнать байтики по сокету?
Причем тут знание о целостности, тебе с одной тачкой целостность просто легче обеспечить, и да, о целостности остальные знают побольше тебя, в том числе и где этой целостностью или её частью можно пожертвовать

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

у каких-то «бигдатовцев» вообще проблемы поменьше у них просто данных много, а схема «плоская» аки твой лоб!..
Ну если логика не в базе, то Node.js заменить будет всё таки попроще.

Они расплющили и максимально упростили представление, потому что так проще иметь распределенное хранилище без контроля целостности. Целостные данные восстанавливаются уже при выполнении каждого запроса. Такая архитектура повышает общую стоимость каждого запроса, но дает неограниченную масштабируемость. По этой причине она подходит только тогда, когда масштабирование неизбежно - это прыжок из одного сервера сразу в пять серверов, меньше не имеет смысла. Ну, или если ты собрался писать и не читать.
И тогда логика на Node.js не влияет на структуру данных, а лишь меняет представление при чтении. Тогда она действительно не нужна на сервере БД. И она все равно не поможет исправить проблему разнородности данных, которые были добавлены в отдаленные периоды времени и не реструктурированы - сложность поддержки будет просто расти со временем. Зато сотрудники будут сыты, здоровы, при своих рабочих местах.
Из плоскости хранения данных возникает проблема:

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

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

Система дай бог если на миллион, а позиционируется минимум на миллиард.

О таких системах я не веду речь, хотя не вижу там проблем использовать и MySQL
...
У меня данные не в одной базе, не все базы сиквельные, не все базы реляционные, не все базы на одной машине, не все данные читаются с мастеров, не все данные читаются только баз, есть распределённые индексные сервера, есть распределённые кэши, есть оперативная информация, и в датацентре тоже не одном, работа 24/7/365, обновления что схемы базы

Давай разделим понятия: есть многомиллиардные компании с сотней миллионов пользователей, а есть фирмы с 20 пользователями и 40 серверовами.

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

Очень мало. У фейсбука при лярде онлайн было несколько десятков миллионов запросов в секунду. Если грубо провести аналогию, то на твоем масштабе получится порядка 10 тыс запросов в секунду. Это детский сад, на таком масштабе нужно думать о том, как бы сэкономить и вложиться в приобретение большего числа пользователей, а не о покупке избыточных серверов и разведении зоопарка.

худшую ошибку сделал только ты, завязавшись на Delfi/Oracle

Не я. Я бы в жизни такую дичь никому бы не посоветовал. Но у индустрии свои взгляды, и те же 1C-ники используют чаще всего MS SQL: https://infostart.ru/public/967268/

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

Facebook использует InnoDB и RocksDB в качестве key-value хранилища, что есть одно из популярных устройств NoSQL баз. Им не нужен SQL - потому я и зову это «NoSQL». Я так понимаю, что ты относишься к той молодежи, которая считает навык составления запросов на выборку/вставку/обновление по одной таблице «хорошее знание SQL».
Аналогию монго с мускулем ты не понял, увы, а история ведь ходит по кругу - каждое новое поколение разводят по старой схеме.

Закину историю успеха одного индуса:
1. 1 month - 20k users - learnt about indexes and created indexes.
2. 3 months - 500k users - Realized MyISAM is a bad fit for mutable tables. Converted the tables to InnoDB. Increased number of JVM threads to tomcat
3. 9 months - 5M users - Realized that the default MySQL config is for a desktop and allocates just 64MB RAM to the database. Setup the mysql configs. 2 application servers now.
4. 18 months - 15M users - Tuned MySQL even more. Optimized JDBC connector to cache MySQL prepared statements.
5. 36 months - 45M users - Split database by having different tables on different machines.

Мне кажется, что ты не понял, к чему я это писал. Я писал о том, что средний слой не нужен.

Ты невнимателен, к тому, что сам же написал, это глупо.

данные размазаны по разным базам, и не просто по разным базам, а под разными версиями СУБД, по разным СУБД, по разным сервисам, по разным NoSQL

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

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

И этот опыт не имеет отношения к MySQL.

О да, рассказывает нам тот, у кого опыта нет в MySQL от слова «вообще»

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

О да, рассказывает нам тот, у кого опыта нет в высоконагруженных и распределённых системах от слова «вообще».

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

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

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

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

У MS SQL есть единственный конкурент - это Oracle.

Не смеши меня, на MSSQL можно завязываться, только если есть явное предпочтение заказчика: уже куплена лицензия, мифическая боязнь зоопарка, предпочтение офтопика, уже написано куча кода. В других случаях следует потратить усилия и убедить их использовать Оракл. Следует сказать что мелкомягкие выпустили версию SQL Server под линукс, но я честно его не использовал, может я не прав и под линуксом оно рвёт и педалит, если у тебя такой опыт, так и скажи, а понты оставь заказчикам.

У них обоих проблема одна - очень высокая цена лицензий. Стоимость железа и ОС на этом фоне меркнет.

В смысле меркнет??? Может сейчас что-то изменилось, но лет двенадцать назад тебе надо было заплатить лицензию за SQL server, за Windows Server (да, ваш хоумэдишн не подойдёт), и за железо, которое раза в три дороже стоило, чем обычные сервера используемые под приложения. Стоимость стандартных лицензий оракла и миккимауса в то время были почти одинаковы, а интерпрайз редакция тебе явно не нужна, самое смешное, что в том проекте того же самого можно было добиться и от MySQL и от PostgreSQL и дешевле, и без потери производительности, просто «не хотелось разводить зоопарк» и никто не хотел связываться с тем, что заведомо и условно считалось, что не потянет.

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

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

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

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

Потому я называю тебя бигдатавцем.

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

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

Их счастье, большинство ведь и не знает, но ты-то что-то слышал, а продолжаешь рассказывать байки, о том, что всё можно сделать в одной и той же базе, главное «правильно» спроектировать.

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

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

Давай разделим понятия: есть многомиллиардные компании с сотней миллионов пользователей, а есть фирмы с 20 пользователями и 40 серверовами.

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

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

Очень мало.

Побольше, чем ты видел ^_^

У фейсбука при лярде онлайн было несколько десятков миллионов запросов в секунду.

Ты оперируешь средней температурой по больницАМ.

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

У нас не фейсбук, если так проводить аналогию, то можно сравнивать и со сферическим конём в абсолютном вакууме.

Это детский сад,

Нет, дорогуша, детский сад у тебя.

на таком масштабе нужно думать о том,

Ты в таком масштабе ничего не понимаешь, судить не можешь, а тем более давать советы, не выставляй себя ещё большим идиотом.

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

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

а не о покупке избыточных серверов и разведении зоопарка.

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