ACID&BASE для собеса в IT (полный гайд по вопросу на базы данных)

ACID. BASE. Transaction Models.
Теоретическое видео про модели транзакций баз данных ACID & BASE, который задают на почти каждом интервью. Современные БД могут перехлестываться и при определенных настройках тот же postgresql может создавать eventual consistency, хотя говорим мы, что он ACID. Тем не менее попробуем описать эти два типа, чтобы у нас все было в одном месте и никто не мог подловить нас такими вопросами! А более подробные варианты и модели репликаций, шардирование, партицирование мы обсудим подробно, но немного позже через несколько видео. Дальше будет еще больше детальных видео с практическими примерами всего, что может понадобится на собесе на любой грейд. Всем удачного просмотра!
Telegram: t.me/dev_pushkin
Leetcode: leetcode.com/idfumg
GitHub: github.com/idfumg
0:00 Болтаю
2:05 ACID
5:00 Atomicity
8:24 Consistency
11:40 Isolation
19:00 Durability
21:50 BASE
27:00 Basically Available
29:44 Soft State
32:42 Eventually Consistent
#transaction_models #acid #base #postgres #mongodb #database #atomicity #consistency #isolation #durability

[@user-docsportello]

Лучшее объяснение по ACID что видел.

[@antonhen23]

Спасибо за видео! Eventual consistency - визуализация топ!

[@grigorii9019]

Gossiping можно очень мило перевести - на сплетничала, нашептал на ухо. Спасибо за видео.

[@dev_pushkin]

Спасибо) да я туплю иногда, когда думаешь на одном, говоришь на втором и наоборот 🤡

[@grigorii9019]

@@dev_pushkin Не знаю, мне манера речи и понравилась). Особенно с поправкой на то, что нужно достаточно сложные концепции объяснить.

[@dev_pushkin]

Спасибо) ну да, это довольно не просто делать)

[@dashaermolich1733]

Спасибо большое за столь полезную информацию.

[@studiosus23]

А есть ли ссылка на презу?

[@sunny3drag0n]

А как в eventual consistent решается проблема, если у нас ноды начали реплицировать изменения, и в этот момент в ещё неизменную ноду записали другое значение? Получается такой конфликт. Что получим на выход? Как повезет?

[@dev_pushkin]

Это проблема lost update и concurrency. И она решается несколькими способами типа idempotency, кворума или LWW (Last Write Wins), или версионностью в nosql. Также есть другие техники, я постараюсь про них рассказать через одно видео. Там будет понятней намного. Если у нас мастер-мастер с постгрей, то иногда такие проблемы могут быть и не решаемы и это не любят использовать. Поэтому лучше заранее договариваться, какую бд брать и для каких целей и какие техники борьбы с конкарренси заюзать. Такие же проблемы могут возникнуть и с брокерами сообщений, например если дать параллельно нескольким процессам брать мессаджи из очереди, что может нарушить порядок. В кафке есть спец механизмы для борьбы с этим, если такая потребность есть. Обычная рассинхронизация часов тоже может привести к этому и мастер мастер оставит не валидное значение, если юзаем timestamp, к примеру