-
Проблемы изоляции транзакций
Конкурентный доступ к данным - одна из основных проблем при реализации изоляции транзакций. Способ решения этой проблемы определяет ключевые характеристики базы данных, на которые мы опираемся при выборе подходящего хранилища для своих проектов. И так повелось, что со времен изобретения SQL-стандарта так и не появилось однозначного определения “уровней изоляции транзакций”, благодаря чему у каждой базы данных своё представление относительно этого вопроса. А разбираться с этим многообразием приходится нам - пользователям этих продуктов.
-
Удаление конфиденциальных данных
Бывает так, что встречаешь описание интересного подхода или алгоритма, а потом про него забываешь, так как теория не была подкреплена практикой или прошло очень много времени. И вот когда наступает момент, где можно блеснуть своими знаниями, приходится тратить время, чтобы вспомнить детали. В очередной раз, когда я поймал себя на подобной мысли, я решил, что было бы неплохо делиться подобными находками. ;-) #tip
-
Calvin Protocol для распределенных транзакций
Многие знают про протокол двухфазной фиксации (two-phase commit, 2PC), но мало кто слышал про протокол Calvin. Честно говоря, до недавних пор я тоже относился к этому меньшинству, поэтому решил поделиться своей находкой с вами. Однако для начала предлагаю освежить память и вспомнить про распределенные транзакции и 2PC. :)
-
Конкурентный доступ к данным
Конкурентный доступ к данным — это драйвер всего того, что делается во имя изоляции транзакций. Конечно, речь о транзакциях, которые модифицируют данные (read/write, write/write), поскольку именно в этом случае возникают все те аномалии, о которых шла речь ранее.
-
Хочешь рисуй, не хочешь - вызывай REST
Решил завести нерегулярную рубрику “Утилиты” #tools, в которой буду делиться своими находками удобных и полезных инструментов. Если сталкивались с чем-то похожим, делитесь своими подборками в комментариях. ;)
-
ACID, AID или AD
В свете растущей популярности распределенных систем часто видим упоминание таких слов, как согласованность и изоляция. В контексте работы с данными считается, что эталоном согласованности и изоляции являются проверенные годами реляционные базы данных, а в распределенных системах с этим всё очень плохо, ведь там нет транзакций, поэтому приходится придумывать что-то своё, сильно усложняя прикладной код, а в результате всё равно получается что-то не очень надёжное. Давайте разбираться.
-
Что не так с PostgreSQL
Если вы никогда не задумывались о том, что не так с PostgreSQL, скорей всего, у вас всё так и можно спокойно жить дальше. Но это не точно. :-)
-
Принцип прочности
В продолжении разговора о надежности, прочности и устойчивости. Недавно наткнулся на принцип, о существовании которого я не знал, но много раз применял его на практике. Точней сказать, я не знал, что это целый принцип. :)
-
Борьба с зомби-процессами
Ранее я обещал, что постараюсь раскрыть тему безопасного исполнения ненадежного кода (untrusted code). Сегодня будет первая статья из цикла “Как безопасно исполнять ненадежный код” #untrusted_code. Надеюсь, что будет интересно. :)
-
Гарантированная отправка сообщений
На конференции TeachLeadConf 2024 после доклада мне был задан вопрос про гарантию отправки сообщений в брокер. Если коротко, то вопрос можно сформулировать так: “Как гарантировать отправку сообщений, сохранив их порядок?” Оригинальная формулировка была не столь понятна для меня, поэтому пришлось ответить позже в закрытом чате конференции. Поскольку вопрос достаточно популярный, я решил дать более развернутый и публичный ответ.