У меня

Пока у вас все так круто, к нам поползли клиенты из банковского сектора, подхватившие тренд Сбера. Мы не позиционировались как хайлоад, логику отродясь держали в БД, но, как оказалось, там, где нужна и высокая производительность, и бизнес-логика, и куча батч-операций, и ручные действия пользователей, одна оракловая БД на оракловой железке справляется лучше. Да, это не фронт, это процессинг или что-то около того. Да, никакого 24/7, нужно техокно для обслуживания. Да, нужно следить, чтобы какой-нибудь пользователь не заблокировал потоковые операции. Но все описанные тобой фичи нужны там, где есть взаимодействие с клиентом. А в бэк-системах, как и раньше, нужен честный ACID и производительность, что ограничивает нас одной БД. Справедливости ради нужно заметить, что RAC нужен, а, значит, без тщательного проектирования шардирования никуда.

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

Не я. Я бы в жизни такую дичь никому бы не посоветовал.

Выше советовал, теперь открещиваешься.

Но у индустрии свои взгляды,

выходи из своей отсталой индустрии.

и те же 1C-ники используют чаще всего MS SQL: https://infostart.ru/public/967268/

Я что-то пропустил, у 1C пропал промежуточный уровень? Или может они сделали трансляцию своего 1C диалекта напрямую в TSQL? Может появилась родная поддержка хотя бы части диалекта 1C/SQL в SQL Server???

Facebook использует InnoDB и RocksDB в качестве key-value хранилища, что есть одно из популярных устройств NoSQL баз.

Facebook использует RocksDB в качестве key-value хранилища (и ещё для кое чего)! Всё, остальное твои фантазии.

Им не нужен SQL - потому я и зову это «NoSQL».

Запущенные фантазии. Они используют MySQL, как SQL, потому что им всё так же нужна реляционная модель данных. Если бы ты прочитал статью, понял бы, что они просто заменили в MySQL движок InnoDB на RocksDB, в основном ради улучшенного сжатия, так же они расписали прочие плюсы, такие как ускорение записи, а так что ещё за плюшки в нагрузку получили. MySQL, тем менее, у них остался. Уже третий раз пишу, либо прочти статью, либо выучи английски, либо иди лесом со своими фантазиями.

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

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

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

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

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

Пока у вас все так круто, к нам поползли клиенты из банковского сектора, подхватившие тренд Сбера. Мы не позиционировались как хайлоад, логику отродясь держали в БД, но, как оказалось, там, где нужна и высокая производительность, и бизнес-логика, и куча батч-операций, и ручные действия пользователей, одна оракловая БД на оракловой железке справляется лучше. Да, это не фронт, это процессинг или что-то около того. Да, никакого 24/7, нужно техокно для обслуживания. Да, нужно следить, чтобы какой-нибудь пользователь не заблокировал потоковые операции. Но все описанные тобой фичи нужны там, где есть взаимодействие с клиентом. А в бэк-системах, как и раньше, нужен честный ACID и производительность, что ограничивает нас одной БД. Справедливости ради нужно заметить, что RAC нужен, а, значит, без тщательного проектирования шардирования никуда.

Два чая этому товарищу, критика по делу, с такими требованиями сложно не согласиться, биться и топить за что-то другое, (тем более за «миккимауса» ^_^) не буду. Замечу только, что это Оракл, и аналога RAC для SQL Server я не знаю, когда я с ним работал, аналогов не было. Так же, замечу, что масштабирование оракла всё таки влетает в копеечку, но если требования такие жёсткие, то заказчик обычно готов платить.

значит, без тщательного проектирования шардирования никуда.

Благодарствуем!

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

Ну если для тебя «крупный сервис» - это миллион пользователей, то, может быть, ты и прав. Правда, тогда получается, что любой отдельно взятый популярный бложик - это «крупный сервис». Показательно что компании, выбравшие mongodb, тусуются на уровне «крупный сервис», не перерастая в по-настоящему крупный сервис.
Держать несколько версий той же монги значит, что у тебя разные механизмы репликации, отличаются доступные функции у каждой из них и потенциально отличаются движки (MMAPv1, WiredTiger). То есть, здесь у тебя мастер-слейв на MMAPv1, там у тебя реплика-сет на тигре, новыми инструментами не поработаешь со старой базой, старыми не поработаешь с новой.
У мускуля даже между минорными версиями есть значимая разница, и результат одной и той же операции может быть разным в зависимости от версии, и если в одной версии запрос сработал - в другой он может выдать ошибку:
https://severalnines.com/blog/understand-what-has-changed-between-mysql-56-an...
https://makandracards.com/makandra/51169-understanding-sql-compatibility-mode...
Не, может у вас манипуляции с базой ведутся на авось и подход «пропотеряли данные - и ниче страшного» вполне приемлим, но, мягко говоря, не всех такой подход устраивает, а грузить кодера деталями вроде «там такая версия, ты это делай, а этого не делай, а если перепутаешь - мы тебя натянем» никто не будет, потому что кодер все равно накосячит.

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

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

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

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

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

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

И тогда ты должен знать, что MS SQL и Oracle обскакивают мускуль и постгрес в полтора-два-три и больше раза в зависимости от запроса. И да, MS SQL используют по причине оффтопика в среде.

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

Не застал эти времена, судя по всему. Сейчас 32 ядра и 400 Гб оперативы можно взять за 3000$, а цена лицензии SQL-сервера на все эти ядра будет космической. Я хз, может ты перепутал цену железа с ценой лицензии мелкомягких, и вам на самом деле продавали железо с готовым комплектом лицензий.
Постгрес всего 10-15 лет назад имел проблемы с производительностью и репликацией, а мускуль не поддерживал ACID.

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

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

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

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

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

А ты не хочешь объявлять свою нагрузку. Вот я и взял среднюю по больнице.

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

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

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

И просто уходишь в глухую оборону, осознавая, что обосрался.

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

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

худшую ошибку сделал только ты, завязавшись на Delfi/Oracle
Не я. Я бы в жизни такую дичь никому бы не посоветовал.

Выше советовал, теперь открещиваешься.

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

у 1C пропал промежуточный уровень? Или может они сделали трансляцию своего 1C диалекта напрямую в TSQL? Может появилась родная поддержка хотя бы части диалекта 1C/SQL в SQL Server???

Может быть когда-нибудь увидим PL/1С, в чем я сомневаюсь, на самом деле. Я напомню, что есть много людей, совмещающих сервер логики 1С с сервером базы, у них это называется «файловая база», аля SQLite. Такая архитектура создает сложности переноса логики на выделенный сервер БД.

Они используют MySQL, как SQL, потому что им всё так же нужна реляционная модель данных.

Хорошо, ты меня подловил, он все-таки используют простые join-ы внутри шарда:
https://www.youtube.com/watch?v=Zofzid6xIZ4#t=04m10s
https://www.nairaland.com/1277430/facebook-database-schema-take-look
Хотя, Aditya Agarwal в 2010 заявлял, что джоинов у них нет в продакшене.
Так или иначе, структура конечного хранилища там - это не то же самое, что общая структура хранимых данных.

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

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

монга — документоориентированная, мускуль — реляционная

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

если ты думаешь, что всё, что они решают, ты решишь на сиквеле, да ещё быстрее и дешевле, то ты просто дурак

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

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

Справедливости ради нужно заметить, что RAC нужен, а, значит, без тщательного проектирования шардирования никуда.

RAC нужен для чего? А я отвечу сам: для того, чтобы тяжелые процессорные обработки распределять на несколько машин. Несколько машин по сети обращаются к хранилищу - уже довольно давно такая модель не позволяет использовать быстрые накопители, упираясь в сеть, для чего ораклу пришлось придумывать Cache Fusion.
Таким образом, ниша для RAC остается только в тяжелых вычислениях. Но что у тебя за такие тяжелые вычисления, для которых нужно мало ввода-вывода? Как бы можно было теоретически графический интерфейс сервером оракла делать, но это уже абсурд. А по-хорошему те же задачи можно и нужно было выполнять, оставляя сервер оракла в единственной машине.
Вот чем преуспела технология RAC - так это во впаривании дополнительных лицензий, здесь я соглашусь.

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

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

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

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

Я ее не упустил - я ее просто не понял. Цитата была:

Справедливости ради нужно заметить, что RAC нужен, а, значит, без тщательного проектирования шардирования никуда.

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

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

Это я просто пытался придумать, кому и зачем может понадобиться RAC. Видимо, никому и низачем.

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

Не нужен не RAC, а распределенная БД. Часто хватает одной БД на топовой железке, а когда её не хватает, берёшь RAC. Нюанс в том, что нельзя сидеть на БД без шардирования, а потом пересесть на RAC. Т.е. нужно изначально понимать нагрузку и проектировать шардироавание. Я противопоставляю RAC и распределены БД, потому что в случае RAC заботу об ACID на себя берет БД.

Нюанс в том, что нельзя сидеть на БД без шардирования, а потом пересесть на RAC

Можно, я разрешаю. Проблемы производительности ввода-вывода это не решит, но пересаживаться можно.

Я противопоставляю RAC и распределены БД, потому что в случае RAC заботу об ACID на себя берет БД.

Есть распределенные БД с ACID из коробки. Но это не оракл.

Можно

Нет. То, что ты при этом получишь посадку производительности, и означает нет.

Есть распределенные БД с ACID из коробки

Нет. Есть одна такая БД и она у гугла. Остальные не обеспечивают честный ACID. Итоговая согласованность, как минимум, означает грязные чтения. Никто тебе такого не позволит делать, например, в процессинге, где встречается такой хак, как выполнить расчёт в изолированной транзакции, насчитать процент на остаток, откатить транзакцию, показать клиенту/пользователю процент.

Есть одна такая БД и она у гугла. Остальные не обеспечивают честный ACID. Итоговая согласованность, как минимум, означает грязные чтения. Никто тебе такого не позволит делать, например, в процессинге, где встречается такой хак, как выполнить расчёт в изолированной транзакции, насчитать процент на остаток, откатить транзакцию, показать клиенту/пользователю процент.

Citus на слонах позволяет: https://www.citusdata.com/blog/2017/11/22/how-citus-executes-distributed-tran...
Да, это медленно, но это работает.

С постгресом мы тоже тестировали, он и на одном инстансе, к сожалению, сливает в наших кейсах. Потери не в 1-2 процента, а, ЕМНИП, до 30. Подробностей не скажу, сам в этом не принимал участия.

С постгресом мы тоже тестировали, он и на одном инстансе, к сожалению, сливает в наших кейсах. Потери не в 1-2 процента, а, ЕМНИП, до 30.

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

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

Опять рассказываешь то, чего не понимаешь

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

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

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

Решается наличием промежуточного слоя

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

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

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

Потому что это решается наличием прослойки, но да, действительно везде накосячишь

И тогда ты должен знать, что MS SQL и Oracle обскакивают мускуль и постгрес в полтора-два-три и больше раза в зависимости от запроса.

Примерно в 90%-95% запросов разницы не будет, либо будет колебания в пользу одного, либо другого, и это только по количеству, если смотреть по мощности то 99.9%. Конечно, если у тебя система, где надо перелопатить кучу таблиц для построения многостраничных отчётиков, то почувствуешь жёсткий дискомфорт, на мускуле ты даже запрос толком не сможешь построить без промежуточных таблиц. Только тут не факт, что я задачу хуже решу на промежуточном слое.

Не застал эти времена, судя по всему. Сейчас 32 ядра и 400 Гб оперативы можно взять за 3000$, а цена лицензии SQL-сервера на все эти ядра будет космической. Я хз, может ты перепутал цену железа с ценой лицензии мелкомягких, и вам на самом деле продавали железо с готовым комплектом лицензий. Постгрес всего 10-15 лет назад имел проблемы с производительностью и репликацией, а мускуль не поддерживал ACID.

В те время я как раз использовал SQL Server, BerkleyDB. Три кластера на беркли держали в 100 раз больше данных по объёму и обходились в 20 раз дешевле, хотя машин на беркли было больше в полтора раза, конечно там был тупо распределённый реплицированный массив, и половину данных в реляционку только дурак пытался бы положить. К слову, в сиквеле данные в одну машину ты тоже не засунул бы, там хранилища по FC подключались, так что сказки не рассказывай, о том, что тогда счастливое время для реляционных СУБД было. В том проекте было >100 миллионов пользователей в пике.

Постгрес всего 10-15 лет назад имел проблемы с производительностью и репликацией, а мускуль не поддерживал ACID.

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

Это был стеб, если ты не понял.

Твой бред только как стёб и можно воспринимать.

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

В треде ты регулярно выставляешь себя некомпетентным дураком.

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

Кто так хранил, ты что ли? Так ты в любой базе их так хранишь, ты же неопытный.

До сих пор реально широкое применение в индустрии нашли только реляционные БД

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

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

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

Мне говорили, что именно для картинок и придумали всякие sybase, разве это не так? Или... Вы ничего кроме пары самых популярных вариантов не знаете, и просто проецируете свой опыт на весь мир?

Зачем картинки вообще класть в базу данных?

Ну ты же всё хранишь в ОДНОЙ базе!

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

Причём тут МЫ, ты опять невнимательно читаешь? Что за бред, какого ты предлагаешь картинки в одну клеить, что это за дерьморешение. Совсем ненормальный?

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

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

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

Ясно, так бы и сказал, что ты далёк от разработки.

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

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

У мускуля даже между минорными версиями есть значимая разница

Решается наличием промежуточного слоя

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

Потому что это решается наличием прослойки, но да, действительно везде накосячишь

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

Репликация тебе не нужна, ты ратуешь за одну машинку

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

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

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

Совсем скатываешься в говно.

До сих пор реально широкое применение в индустрии нашли только реляционные БД

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

Ну я же написал «единственный вариант достаточно глубокого и гибкого структурирования хранилища». Если у тебя хранилище простое, если тебе транзакции не нужны, целостность не нужна - ради бога, храни в беркли, храни в файловой системе. Но это упрощение. Предельное упрощение - сплошное неструктурированное хранилище данных, и этот подход тоже используется. Файловые системы, например, это обычно тупо сплошная таблица файлов со строго заданной структурой каждой записи (элементы реляционной базы), которая ссылается на BLOB (элементы key-value базы). И сверху над этим уже ось домысливает иерархию.

Мне говорили, что именно для картинок и придумали всякие sybase, разве это не так? Или... Вы ничего кроме пары самых популярных вариантов не знаете, и просто проецируете свой опыт на весь мир?

Эмпирическое правило примерно такое: если ваши данные занимают не более десятка-другого страниц (<200 кб), то есть смысл хранить их в базе данных. Всё остальное беспощадно выносится в файловую систему, особенно учитывая, что обычно содержимое файла при выполнении запросов никак не используется и целостность необязательна.
Про Sybase похоже больше на маркетинговую байку.

Ну ты же всё хранишь в ОДНОЙ базе!
Причём тут МЫ, ты опять невнимательно читаешь? Что за бред, какого ты предлагаешь картинки в одну клеить, что это за дерьморешение. Совсем ненормальный?

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

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

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

Ясно, так бы и сказал, что ты далёк от разработки.

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

невозможно пересесть на шардированную БД и получить прирост производительности, эсли это шардирование не заложено в логике приложения.

Да.

А ты не хочешь объявлять свою нагрузку

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

Возьмём простенькую базу пользователей и смотрим запросы только по пользователям только на чтению по первичному ключу, пускай будет даже 6K запросов в секунду, а у тебя в таком же расскладе на базу будет идти 116786 в секунду, потому что у тебя тупо нет распределённого кэша, а если взять ближний кэш, ой, а тут ещё 220К запросов. И это только выборка пользователей по PK, а есть ещё поиск по кучей полей пользователя, в том числе и полнотекстовый, в том числе и по связанным таблица(1:N), который сейчас идёт на отдельные индексные сервера, да, там есть лаг в полминуты на создание инкрементального индекса, зато выборка не нагружает основную базу, и не надо в базе пользователей держать кучу разных индексов. Так что, давай, до свидания, со своими сказками об одной базе, и как всё в неё можно запихать и всё на ней одной сделать.

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

С чего бы это?

И просто уходишь в глухую оборону, осознавая, что обосрался.

По себе о людях судишь, врунишка!

Резервирование на случай сбоя - совершенно другое дело.

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

Возьмём простенькую базу пользователей и смотрим запросы только по пользователям только на чтению по первичному ключу, пускай будет даже 6K запросов в секунду, а у тебя в таком же расскладе на базу будет идти 116786 в секунду, потому что у тебя тупо нет распределённого кэша, а если взять ближний кэш, ой, а тут ещё 220К запросов

3 млн пользователей в системе и 220 тыс запросов в секунду по ним? Что это за система у вас такая?

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

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

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

Тебе уже ответили, что ты херню несёшь.

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

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

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

Ты опять невнимателен, не понимаю, почему я должен объяснять который раз, система работает 24/7/365, сервисных окон нет, обновления почти каждую неделю, даже в один день может быть несколько, пользователи никак обновлением не затрагиваются. Тут это к тебе с твоей одной базой сложней, а микросервисы так и вообще на то и придуманы, чтоб их обновлять не кладя всю систему.

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

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

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

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

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

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

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

Запиши другое: 1. обновлять не нужно, старый функционал не требует новых фишечек, которые есть в новой версии субд. 2. обновлять не нужно, старый функционал не подвержен ошибкам, которые присутствуют в используемой версии субд. 3. обновлять не нужно, старый функционал не получит прироста производительности от новой версии(в особых случаях может быть даже падение производительности) 4. можно обновить после тестов, но только для новых и изменяемых записей, расширяются компоненты, добавляется политика шардирования и слияния. 5. можно обновить после тестов, дальше уже смотреть как можно данные зареплицировать между версиями: 5.a) всё реплицируется штатными средствами, делаем, переключаем мастеров конфигурацией. 5.b) всё поломано, репликация поломана, логи не накатываются, бэкапы не открываются, делаешь дамп и ручная накатку, на промежуточном слое делается запись в обе, накатывается разница, что накопилась до начала записи. Делаешь дампы с обеих вариантов до появления новых записей, разрешаешь конфликты. Переключаешь чтение в конфигурации на новую, отключаешь запись в старую, всё. Да, это будет дольше, зато пользователи ничего не заметят.

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

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

3 млн пользователей в системе и 220 тыс запросов в секунду по ним? Что это за система у вас такая?

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

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

Отлично!

В последнем предложении ты писал про реплику (или про реплику шарда, или про шард реплики), а не про простой шард.

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

Ты опять невнимателен, не понимаю, почему я должен объяснять который раз, система работает 24/7/365, сервисных окон нет, обновления почти каждую неделю, даже в один день может быть несколько, пользователи никак обновлением не затрагиваются. Тут это к тебе с твоей одной базой сложней, а микросервисы так и вообще на то и придуманы, чтоб их обновлять не кладя всю систему.

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

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

Эй, погоди, что значит «может еще что-то абстрагировал» и «может взял готовый orm»? Вы эту совместимость делали или нет? У меня такое ощущение, что нет, потому что если бы вы реально все перечисленное реализовали хоть как-то достаточно глубоко и надежно, то получился бы проект размером с весь ваш остальной, потому что обычные ORM ни разу не дают полной абстракции от базы, и тот же SQLAlchemy на 100 тыс строк в основном питонового кода не дает полной абстракции. Ты уверен, что у вас действительно есть гарантия отсутствия сбоев из-за разных версий, или «может быть» у вас они случаются, но вы перекинете нагрузку на другой сервак или нагрузите stateless сервис дополнительным слоем исправления ошибок, и продолжите работать как ни в чем не бывало? Или, может быть, вы просто не используете большую часть функций СУБД, ограничиваясь лишь базовыми и стабильными?
Я, конечно, больше склоняюсь к тому, что вы просто используете MongoDB без транзакций вместо базы данных, и то, что вы там «могли бы», вы на самом деле не делали и делать не будете, а для решения проблем докинете еще одну стойку. Там и «схему обновить» легко, потому что схемы никакой нет, и достаточно отдаленные версии умеют реплицироваться между собой.

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

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

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

Кто-то серьезно таким занимается? То есть, даже зоопарк внутри микросервиса? Прикольно.

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

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

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

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

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

100 млн - это те, которые зашли один раз и оставили печеньки? Просто странно, что пользователей 100 млн, но онлайн не дотягивает до ляма даже.
Когда я писал про запросы в секунду, я имел в виду именно запросы, а не чтения строк. Вот цифра 6к запросов выглядит правдоподобной для <1 млн пользователей. То есть, каждый юзер раз в две минуты запрашивает инфу о других пользователях - и так круглые сутки. Или каждый пользователь 1 час в день делает по запросу в 5 секунд. Это довольно большая цифра, если считать, что пользователь - человек, а не робот.
Такая нагрузка прекрасно держится многими реляционными базами на единственной машине.

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

Чет я не совсем понял, у вас типа допустим частичный сбой системы?

Смотрю, любитель шардов и орм, а не хипстерок ли ты часом?

Нетты невнимателен, я писал про базу данных.

Хватит фантазировать, о базе данных ничего дельного ты не написал.

Я-то как раз с самого начала угадал, что у вас база/базы представляют собой неподдерживаемую помойку,

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

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

Такой бред несёшь только ты.

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

И, их же очень мало, и их не обновляют, большинство логики на промежуточном слое.

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

Вообще не проблема, если ты обновляешь приложение на эрланге, даже состояние обновится, для других есть распределённый кэш, для особенных — разделяемая память, а в основном им состояние конечно не нужно, пользовательский сеанс отдельными распределёнными сервисами хранится в памяти. А есть машины с ПО «state of Art», которые годами работают и держат состояние, и просто передают на бэк с запросом.

Эй, погоди, что значит «может еще что-то абстрагировал» и «может взял готовый orm»? Вы эту совместимость делали или нет?

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

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

Всё верно, но поскольку основная логика пишется не в базе, и занимает от силы процентов 5%, то нам глубокой абстракции и не нужно. Схема модифицируется отдельно от приложения. И от разработчика всё так же требуется понимание ACID, структурирования, нормализации, блокировках, индексах, всё то, в чём ты только поверхностно разбираешь. Плюс разнесение данных вертикально/горизонтально, таким образом, чтоб масштабировалось и сохранялись целостность и атомарность, и не было (по возможности) распределённых транзакций, о таких аспектах ты только догадываешь, и пишешь чушь.

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

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

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

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

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

Эврика, наконец-то доходит, да конкретно от MySQL нам нужна только RM и ACID, если брать PostgreSQL, то там есть вкусный geospatial индекс. Хранимых процедур — минимум, тригеров — почти нет, для редких сущностей, отображений — нет, материализованных отображений — нет. А в транзакции выполнить кучку операций, большого ума не надо, если до этого всё корректно спроектировано.

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

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

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

Проблем с обновлением схемы на sql ориентированных базах у нас нет, периодически делаем на лету, и прод при этом не ломается.

100 млн - это те, которые зашли один раз и оставили печеньки?

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

Просто странно, что пользователей 100 млн, но онлайн не дотягивает до ляма даже.

Самим обидно.

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

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

Вот цифра 6к запросов выглядит правдоподобной для <1 млн пользователей. То есть, каждый юзер раз в две минуты запрашивает инфу о других пользователях - и так круглые сутки.

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

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

Чет я не совсем понял, у вас типа допустим частичный сбой системы?

Да, частично не работает что-то для кого-то, или работает несколько медленнее, остальные об этом даже не догадываются.

Смотрю, любитель шардов и орм,

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

а не хипстерок ли ты часом?

Нет.

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

Ты скрываешь детали своего проекта, ты пытаешься казаться чем-то загадочным, многообразным и открытым новому, выдаешь себя за высоконагруженный модульный багдата сервис без даунтайма, на проверку со смешной для таких замашек нагрузкой. В общей картине ваш проект следует современной моде тысяч таких же высоконагруженных бигдат, которых развелось уже, как собак нерезанных. Моде, которая ни разу не диктует оптимальные решения, а просто следует тренду - так проще, так инженеры взаимозаменяемее, и самому инженеру приятнее ответить при любой проблеме «вот, все делают то же самое, я не виноват». Свободный выбор - это такая тяжелая штука, что мало кто решается его делать, если нужно еще и отвечать за этот выбор. Тем более, что часто стартапы работают на чужие деньги, так что не жалко.
Советы твои применимы больше к mongodb/redis/nodejs/docker, в крайнем случае мелкий сервак постгреса или мускуля, но ты не забываешь того и дело вставить умные словечки про эрланг, и про нормализацию. Нормализацию, в которой ты проявил невежество, но я не стал указывать конкретную ошибку, потому что сегодня ты пытаешься навешать лапши мне, а завтра будешь уже с новыми знаниями впаривать свои услуги очередному высоконагруженному бигдата стартапу в том же стиле «я вот слышал про sql, я много чего могу про них рассказать, но это уже прошлый век - монга еще круче».

есть машины с ПО «state of Art», которые годами работают и держат состояние, и просто передают на бэк с запросом.

Какое замечательное описание. А теперь смотрим с другой стороны: «мы не смогли сделать сохранение состояния, и просто 10 лет подряд крутим одно и то же приложение на сервере». А как красиво звучит «State of the art», да? Хз, правда, что вы делаете, когда сервер все-таки приходится выключать.

Всё верно, но поскольку основная логика пишется не в базе, и занимает от силы процентов 5%, то нам глубокой абстракции и не нужно...
За семь лет работы в этом проекте, я такие просто такие сбои не встречал. Базы обновлялись, но проблемы там были внутренние, связанные с репликацией....

Эй, погоди, что значит «может еще что-то абстрагировал» и «может взял готовый orm»? Вы эту совместимость делали или нет?

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

Ну хотя бы повыпендриваться-то можно, правильно? «Мы столько можем, и все версии SQL обернуть, и NoSQL, и с репликациями на любой вкус, всё можем, но делать не пробовали и не будем пробовать, а сделали только для пары версий». В реальности же там монга с примитивным доступом, и оборачивать толком нечего. И тут ты понимаешь, что это даст тебе имидж индусоконторы, потому надо бы кинуть какие-то клевые словечки.

Смотрю, любитель шардов и орм, а не хипстерок ли ты часом?

ОРМ выпадает из картины, для бигдаты это не модно.

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

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

Для моей индустрии 6к запросов это что-то совсем маленькое, тут одних картинок заливают 10 лямов в сутки, а спрашивают 50 лямов в сутки

Я об этом и пишу. 10 лямов картинок в сутки - это примерно 100 заливок в секунду. А чтений 500, соответственно. Очень скромные показатели.

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

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

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

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

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

Пальцем в небо.

Моде, которая ни разу не диктует оптимальные решения, а просто следует тренду - так проще,

Неоптимальные решения диктуешь ты, мы им не следуем.

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

Нет, специалистов в нашей области крайне сложно найти.

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

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

Какое замечательное описание. А теперь смотрим с другой стороны: «мы не смогли сделать сохранение состояния, и просто 10 лет подряд крутим одно и то же приложение на сервере». А как красиво звучит «State of the art», да? Хз, правда, что вы делаете, когда сервер все-таки приходится выключать.

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

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

Боже упаси обновлять сервер без теста.

Ну хотя бы повыпендриваться-то можно, правильно?

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

«Мы столько можем, и все версии SQL обернуть, и NoSQL, и с репликациями на любой вкус, всё можем, но делать не пробовали и не будем пробовать, а сделали только для пары версий».

Делается для того, что используется в боевом режиме, делать для всего, извини, на это нет ни времени, ни ресурсов. Давай ты в своём SQL Server сделаешь поддержку 1С наконец, надоело на буржуйском писать, возможностей TSQL ой как не хватает. Или расскажи об опыте эксплуатации его на Linux? Это полезней, чем мне бесконечно твои глупости отбивать.

В реальности же там монга с примитивным доступом, и оборачивать толком нечего. И тут ты понимаешь, что это даст тебе имидж индусоконторы, потому надо бы кинуть какие-то клевые словечки.

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

Давай ты в своём SQL Server сделаешь поддержку 1С наконец, надоело на буржуйском писать, возможностей TSQL ой как не хватает. Или расскажи об опыте эксплуатации его на Linux?

Я в гробу видал 1С.

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

Я думаю, что понты тебе кидать не надоест. Но передохнуть не помешает, да.

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

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

Под линуксом, это мускуль, и это твои масштабы

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

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

Так всё таки есть, а зачем тогда срач разводил? По сути он только держит соединения от клиентов и соединения к базе? Предоставляет некий функциональный фасад, для работы с БД?

Что, у тебя мускуль??? Одна единственная база??? Cколько в ней терабайт, какие диски, если это мои масштабы, то мне очень интересно. Есть ли аналог материального представления?
Так всё таки есть, а зачем тогда срач разводил? По сути он только держит соединения от клиентов и соединения к базе? Предоставляет некий функциональный фасад, для работы с БД?

На пользователей и их интенсивно используемые данные база одна, не считая резерва. Файлы юзеров, как я уже писал, отдельно хранятся. Примерно 100к пользователей каждый день ддосят сервер автоматическими запросами раз в 1-5 минут.
Клиент не пишет данные напрямую в мускуль - операции изменения складируются в очередь, которая обычно за секунды проходит в базу.
В основном сервере что-то вроде десятка терабайт. На файлопомойке даже не знаю сколько - точно больше.
Что такое «аналог материального представления» - понятия не имею.

есть же MUMPS

(в основном, «жидкие» данные с кучей пустых колонок)?

Для таких данных разреженные массивы MUMPS хорошо подходят

Какие есть альтернативы базам данных MS SQL и Oracle?
На память приходит только PostgreSQL и MariaDB/MySQL.

А что это все упёрлись именно в SQL? Сиквел не единственная и не лучшая технология баз данных. Я вот не понимаю, почему все мучаются, используют какое-то своё разное подмножество SQL (почти как в С++), какие-то разные диалекты хранимок и мидлвари поверх. И всё ради чего? Ради возможности делать SELECT ... JOIN ... произвольного вида?

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

Далее, есть рутины, то есть сопрограммы на языке MUMPS. ООП там обычно нет (если не считать Cache CacheScript или Profile в GT.M). Можно делать множественные точки входа, сопрограммы, продолжения и замыкания. Есть циклы, ветвления, процедуры и функции, макросы, eval и косвенность.

Есть транзакции и блокировки, для структурированных данных.

Можно просто написать типа свой ORM для работы с типизированными данными в виде рутин MUMPS и далее работать через него. При этом в отличие от SQL языка достаточно для того чтобы на нём полностью написать само приложение работы с данным, а не просто DDL/DML.

Есть параллельные процессы (JOBS), можно вызывать произвольное их количество. Процессы СУБД могут общаться между собой, вызывать рутины других процессов, передавать между собой данные глобалов, с учётом блокировок и транзакций.