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

Question

[Sergey Myasoedov]

Могут ли буть уровни изоляции у распределенных транзакций? И если да, то каким образом их определить? Просто у каждой же базы данных есть свой уровень изоляции и у одной он может быть ReadCommited, а у другой Serializable

Comments

[mayton2019]

Все неправильно. Все перепутал.

ReadCommited / Serializable - это свойство транзакции а не базы данных.

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

[hint000]

Sergey Myasoedov, а ещё вы не понимаете разницу между несколькими БД и одной БД, распределённой по нескольким хостам.
Тезис: распределённая транзакция работает с одной (но распределённой) базой данных.

[Sergey Myasoedov]

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

[Sergey Myasoedov]

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

[mayton2019]

Друзья. У нас в топике есть сложное определение. Распределенные транзакции. Тема очень злая и неприятная. Ей часто спекулируют. Я встречал некоторых Ораклистов которые Oracle Cluster считают распределенными транзакциями. Есть некоторые люди которые репликацию считают системой с распределенностью и т.п. Поэтому в топике нужно определение. Некоторые считают что JDBC-драйвер с XA это и есть распределенность. Злая. Жестокая. И полностью угнетающая производительность.

Объективно хорошо с распределенностью (globally distibuted) могут работать AWS Dynamo или Microsoft CosmosDb потому что эта распределенность изначально была заложена в их архитектуру. Но очень часто она достигается за счет сильного ослабления транзакций. Грубо говоря чем распределеннее - тем менее констистентно. Это - ползунок. Вы можете двигать его вправо и получать очень жесткую систему но работающую медленно на запись. И влево - быстрая запись но при этом причинно-следственная связь может быть нарушена. В роли такого регулятора-ползунка выступают например в CosmosDb режимы консистентности (их 5 штук от Eventual до Strong). Но эти уровни - не имеют никакого отношения к классическим ReadComm/Ser. Они - просто про попытку навести хоть какой-то порядок в евентуальной системе и сделать эту евентуальность с хоть какими-то гарантиями.

Есть еще и оригинальное решение распределенных транзакций в Cassandra. Но я щас не готов по кассандре спорить. Мне надо почитать и восстановить знания чего там внутри и как. Кроме того после выхода новых релизов они там все расхерячили.

Все остальные решения по распределенности ПРАКТИЧЕСКИ не работают. Как только вы разламываете базу на осколки и разносите ее в сеть - про микросекунды откликов можно уже забыть и начинаются долгие милисекунды и где-то секунды в зависимости от качества вашей сети.

[Vitsliputsli]

Sergey Myasoedov, очень хорошо проблематику описал mayton2019.
Т.е. даже если у вас кластер, но транзакция выполняется всегда строго на одной ноде, назвать это распределенной транзакцией нельзя. С другой стороны, в колоночных СУБД распределение данных по нодам не обязательно полное и один запрос будет выполняться на нескольких нодах, но там и от консистентности одно название.
Если же говорить про highload, то в нем вопрос не особо актуален, при высокой нагрузке требуется максимум производительности системы, поэтому лучше вовсе не использовать транзакции, как и любые иные блокировки. А если уж очень надо, то они должны быть очень короткими и быстрыми.
Если же брать ваш кейс про микросервисы, подразумевая, что транзакция это сущность бизнесовая, а не в СУБД. То тут уже полностью программная реализация, как напишите так и будет, и борьба с аномалиями только на стороне кода приложения. Скажем, если у вас геораспределенная система, то скорее всего вы не можете ждать, пока данные в разных точках мира будут согласованы, и приходится жертвовать консистентостью, делать ее отложенной. Вообще в таких системах даже подразумевается, что консистентность может отсутствовать в определенный момент времени, но в конечном итоге все подсистемы придут в состояние согласованности.
В общем, если у вас нагруженная система, то классические и универсальные решения не подходят, вам нужны специализированные решения и жертвы.

[mayton2019]

Vitsliputsli, да. Кроме того распределенность - это про partition tolerance (CAP-теорема) и этот вопрос
просто практически невозможно игнорировать в обсуждении данной темы. CAP - это компромиссы
с бизнесом. Это попытка понять где мы можем чем-то пожертвовать чтобы получить P/A, P/C e.t.c.

[Sergey Myasoedov]

Большое спасибо за ваши ответы, есть над чем подумать

[DollyPapper]

Sergey Myasoedov, распределенные транзакции они на то и распределенные, что выполняются не в рамках инстанса (физического) одной базы данных. По этой причине одна база данных не может гарантировать такие транзакции. Почитайте на эту тему "Designing Data Intensive Applications", главу про согласованность и консенсус. Так же полезно на эту тему узнать что такое паттерн Saga