jakobz

Categories:

Eventual vs "true" consistency

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

Когда Боб переводит $100 Алисе за сексуальные утехи авансом, а Алиса наливает клофилина, и обносит хату — это все равно выходит за рамки той части системы, которой мы управляем. Система тут включает поведение Алисы и Боба, а не просто банковский перевод. И эта система — она eventually consistent, как ты ее не сделай.

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

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

К сожалению, мир так устроен, что Consistency не бесплатен. CAP-теорема, сорян.

Но, когда выбираешь между Mongo и Postgresql, или между «кешить в redis или просто потюнить постргрю» — ты не выбираешь между наличием, или отсутствием проблем у Боба и Алисы. Ты не заработаешь на приложении, в котором Алису или Боба будут ебать проблемы консистентности — им своих проблем хватает, а у тебя — конкуренты.

Consistency — обеспечивает экономию на разработке. Особенно в системах сложнее блога. А решение продать Consistency за сиюминутную выгоду  — херакнуть in-memory-кешей, стартовать проект на Mongo-DB, обмазаться Redis-ом— часто принимается впопыхах, а часто даже — как дань моде. И, часто, это решение целые проекты хоронит.

Не дайте себя обмануть

Error

default userpic

Your reply will be screened

When you submit the form an invisible reCAPTCHA check will be performed.
You must follow the Privacy Policy and Google Terms of use.