после инсерта получаем id, храним его в сессии и при работе с одним звонком получаем и дописываем инфу по этому id

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

после инсерта получаем id, храним его в сессии и при работе с одним звонком получаем и дописываем инфу по этому id

API. Запрос к апи, получаешь id, пишешь в API

а потом этим API рулишь, чо куда записать

что за апи?

какая разница, через апи дёргать базу или напрямую?

А вы, Владимир, мне про DevOps-аутсорс

какая разница, через апи дёргать базу или напрямую?

Существенная

Напрямую небезопасно. Напрямую - не подменишь базу "на лету"

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

Сделай owner_id какой-нить

Я не видел аутсорса девопсов

Центос-админ.ру

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

Вполне хорошее решение это сервис генерации уникальных ид например

И храни там идентификатор компании

Не благодари?

ну гуиды как вариант, да

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

а кто тебе сказал, что id должны генериться самой базой?

а если связанные таблицы? по внешнему ключу

ну гуиды как вариант, да

Не, мульти мастер медленный но дающий надежно только id

пока ты не положишь id в таблицу, никаких внешних ключей не будет

что ты в базу запишешь, то ключом и будет

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

навставлялось записей в дочернюю таблицу в челябинске

транзакции?

и одна сессия размазалась по разным базам

ничего никуда не вставится при контроле внешнего ключа

если базы разные, сесси тоже будут разные

а транзакции - это транзакции

и одна сессия размазалась по разным базам

Тебе надо сначала понять что тебе нужно получить и чем ты жертвуешь

потом статистику не свести

Потому что если eventually consistent это ок, то тебе нужна какая нибудь база под аналитику с поддержкой распределенных таблиц

Смотри, по контролю консистентности: он бывает физическим, он бывает логическим

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

все равно без бутылки и друга-спеца по теории и практике БД не разберешься

Все зависит от масштабов и ситуации конкретной

У тебя ангельское терпение, бро

Если у тебя есть жена, ей очень повезло

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

Тебе надо сначала понять что тебе нужно получить и чем ты жертвуешь

кстати да, без жертв не бывает. У кого-то ягнята, у кого-то человечинка

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

осталось понять, отказоустойчивость чего тебе нужно обеспечить, и какие "допуски" есть

если тебе критично совпадение rowid в таблицах - это одно, если тебе нужно, чтобы определенные запросы выдавали идентичные ответы на разных базах - это другое

если на пару секунд у всех клиентов на одной площадке отвалятся приложения - это допустимо

это лучше чем когда падает локальная бд и все сосут

если на пару секунд у всех клиентов на одной площадке отвалятся приложения - это допустимо

первое, что приходит в голову - репликация средствами БД + автоматический реконнект в ближайшую

если хочешь "прозрачного" реконнекта - проксируй запросы

если тебе критично совпадение rowid в таблицах - это одно, если тебе нужно, чтобы определенные запросы выдавали идентичные ответы на разных базах - это другое

в идеале построить облачную бд, где каждая нода страхует всё облако

в идеале построить облачную бд, где каждая нода страхует всё облако

ближе к фантастике

я бы в API обернул, а там уже, на уровне API обращения к базе плясал как придумаю

С точки зрения сопровождения БД и софта - на стороне софта максимально абстрагируемся от БД, на стороне БД - реализуем один API

Получаем возможность "скакать" по БД и API до достижения просветления

Но там уже по реальному случаю смотреть надо

В подавляющем числе случаев прямой доступ в БД приложению не нужен

И чем меньше приложение знает про БД, тем лучше

И чем меньше приложение знает про БД, тем лучше

а как же ORM? удобно же :)

@CheshireKot нужна трехзвенная архитектура, такое можно построить на tarantool

я не знаю подходит ли nosql под твою задачу, но то что ты хочешь можно реализовать

ближе к фантастике

Блокчейн так работает

Но это ту мач

Если у тебя есть жена, ей очень повезло

Она надеюсь в курсе :)

а как же ORM? удобно же :)

Ну, собственно, я про ORM, в частном случае и говорю. ORM - это тупо уровень абстракции, он позволяет "насрать" на то, что используется в роли БД.

в идеале построить облачную бд, где каждая нода страхует всё облако

Ну так не делают

Облако это миф дающий плюс 100% к цене

@CheshireKot нужна трехзвенная архитектура, такое можно построить на tarantool

Да я не хочу реализовать, это у Константина задача стоит. Я уже наабстрагировал)

Облако это миф дающий плюс 100% к цене

вот что мне ответил наш дба

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

в идеале построить облачную бд, где каждая нода страхует всё облако

Если готов пожертвовать скоростью то мастер мастер репликация это называется

я не знаю подходит ли nosql под твою задачу, но то что ты хочешь можно реализовать

Я не люблю nosql, мыслю в категориях РСУБД

И сверху балансер

Я не люблю nosql, мыслю в категориях РСУБД

+

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

Синхронизация это дорого. Чем больше синкаешь тем дороже

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

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

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

это в контексте оракла было

Докер => попытка сбежать от синхронизации

это в контексте оракла было

Ну, в контексте СУБД, при синхронизации на физическом уровне - возможно, не совсем в курсе "кухни"

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

Говняная архитектура

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

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

Это фантастика

Если готов пожертвовать скоростью то мастер мастер репликация это называется

Можно синхронный мастер-слейв

Облако - это тупо другой уровень абстракции.

Не больше, не меньше

От тебя просто скрыты детали железа.

И выставлен другой API.

Да бля. Облако - это базворд

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

Согласен, слово придумано маркетолухами

ну понятно, значит просто репликации в условно реальном времени

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

К слову, хитрый инструментарий по репликам прилагался, ЕМНИП, к Tarantool - тут упоминали.

осторожно - технология mail.ru

ну понятно, значит просто репликации в условно реальном времени

Не бывает реалтайм репликации.

это я понимаю)

поэтому условно

но тогда и все площадки должны писать в один мастер-сервер?

Да, именно

Но я все-таки за апи

так а если он упал? или канал упал))

Потому что когда приложенька знает про бд - это плохо

где будет крутиться это апи? на каждой площадке своя копия?

Но я все-таки за апи

Велкам в наш лагерь свидетелей апи)

Канал - это про резерв сеточки