Если вам кажется, что вы понимаете, что такое транзакции - вам кажется.
Несколько лет назад в знаменитом «кабанчике» Клеппмана я прочитала:
Хм, интересно, подумала я, но тогда не придала этому значения. Позже я начала работать с 389 Directory Server - иерархической БД на протоколе LDAP.
😮И... сюрприз, сюрприз: 😮 в базовой комплектации в ней нет транзакционности в привычном для SQL-разработчика смысле.
Что это значит:
- Как только произошла операция над объектом (в LDAP это ADD, MODIFY, DELETE) и она подтверждена сервером — она фиксируется.
- Нет отката изменений для группы объектов.
- Можно накрутить костылей вокруг changelog, чтобы имитировать транзакцию, но это будет уже backend-код, а не гарантия от самой БД.
При более детальном разборе оказалось, что в каком-то виде транзакционность (а точнее часть буквы A из ACID) всё же есть, если речь о нескольких изменениях в рамках одной команды, обращённой к одному объекту.
В Пример 1, это обрабатывается как единая операция: либо применяется всё, либо ничего.
в группе Editors
ADD UserA, UserB
DELETE UserX, UserY
С этого момента жить стало проще… до тех пор, пока ко мне не принесли пачку запросов с неконсистентными данными, которые такими быть не долждны были (в нашем понимании).
Причина в том, что к одному объекту можно атомарно обратиться по-разному:
Как в примере 1, или же сделать те же действия, но двумя отдельными командами (пример 2, каждое объявление группы начинает новую операцию):
в группе Editors
ADD UserA, UserB
в группе Editors
DELETE UserX, UserY
При работе на одном сервере: в первом случае атомарность гарантируется на уровне операции, во втором за счет транзакции уровня backend-хранилища (DBTxn). В целом зная об этом, у нас частенько встречались оба варианта операций.
⚠️Вот только⚠️, при репликации каждая команда получает свой CSN (номер изменения) и всегда выполняется отдельно. В результате в Примере 2 первая операция может примениться, а вторая - нет. Хотя на одном сервере, они всегда выполняются вместе.
Когда, казалось бы, я уже понимаю этим важные моменты, мне пришлось столкнуться с RFC 5805 (LDAP Transactions), который открывает перед LDAP возможности транзакционности при использовании специальных патчей. Но это уже совсем другая история.
Так что, если вы уверены, что уже хорошо разбираетесь в транзакциях, но работали только с реляционными СУБД, вас ждёт немало сюрпризов.
💬 Ну а те кто уже хлебнул разных систем, поделитесь с какой «недо»-транзакционностью сталкивались? К чему это приводило? Что было самым необычным?
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
#LDAP #транзакционность #СУБД
Несколько лет назад в знаменитом «кабанчике» Клеппмана я прочитала:
"Транзакции оказались главной жертвой" NoSQL БД: "многие базы нового поколения полностью отказались или поменяли значение термина — теперь он стал означать намного более слабый набор функциональных гарантий."
Хм, интересно, подумала я, но тогда не придала этому значения. Позже я начала работать с 389 Directory Server - иерархической БД на протоколе LDAP.
😮И... сюрприз, сюрприз: 😮 в базовой комплектации в ней нет транзакционности в привычном для SQL-разработчика смысле.
Что это значит:
- Как только произошла операция над объектом (в LDAP это ADD, MODIFY, DELETE) и она подтверждена сервером — она фиксируется.
- Нет отката изменений для группы объектов.
- Можно накрутить костылей вокруг changelog, чтобы имитировать транзакцию, но это будет уже backend-код, а не гарантия от самой БД.
При более детальном разборе оказалось, что в каком-то виде транзакционность (а точнее часть буквы A из ACID) всё же есть, если речь о нескольких изменениях в рамках одной команды, обращённой к одному объекту.
В Пример 1, это обрабатывается как единая операция: либо применяется всё, либо ничего.
в группе Editors
ADD UserA, UserB
DELETE UserX, UserY
С этого момента жить стало проще… до тех пор, пока ко мне не принесли пачку запросов с неконсистентными данными, которые такими быть не долждны были (в нашем понимании).
Причина в том, что к одному объекту можно атомарно обратиться по-разному:
Как в примере 1, или же сделать те же действия, но двумя отдельными командами (пример 2, каждое объявление группы начинает новую операцию):
в группе Editors
ADD UserA, UserB
в группе Editors
DELETE UserX, UserY
При работе на одном сервере: в первом случае атомарность гарантируется на уровне операции, во втором за счет транзакции уровня backend-хранилища (DBTxn). В целом зная об этом, у нас частенько встречались оба варианта операций.
⚠️Вот только⚠️, при репликации каждая команда получает свой CSN (номер изменения) и всегда выполняется отдельно. В результате в Примере 2 первая операция может примениться, а вторая - нет. Хотя на одном сервере, они всегда выполняются вместе.
Когда, казалось бы, я уже понимаю этим важные моменты, мне пришлось столкнуться с RFC 5805 (LDAP Transactions), который открывает перед LDAP возможности транзакционности при использовании специальных патчей. Но это уже совсем другая история.
Так что, если вы уверены, что уже хорошо разбираетесь в транзакциях, но работали только с реляционными СУБД, вас ждёт немало сюрпризов.
💬 Ну а те кто уже хлебнул разных систем, поделитесь с какой «недо»-транзакционностью сталкивались? К чему это приводило? Что было самым необычным?
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
#LDAP #транзакционность #СУБД