Transakcje i optymistyczna kontrola współbieżności

Transakcje bazy danych zapewniają bezpieczny i przewidywalny model programowania do obsługi współbieżnych zmian danych. Tradycyjne relacyjne bazy danych, takie jak SQL Server, umożliwiają pisanie logiki biznesowej przy użyciu procedur składowanych i wyzwalaczy, a następnie wysyłanie jej do serwera w celu wykonania bezpośrednio w silniku bazy danych.

W przypadku tradycyjnych relacyjnych baz danych musisz radzić sobie z dwoma różnymi językami programowania: nietransakcyjnym językiem programowania aplikacji, takim jak JavaScript, Python, C# lub Java; i transakcyjny język programowania, taki jak T-SQL, który jest natywnie wykonywany przez bazę danych.

Silnik bazy danych w usłudze Azure Cosmos DB obsługuje pełne transakcje ACID (niepodzielność, spójność, izolacja, trwałość) z izolacją migawkową. Wszystkie operacje bazy danych w zakresie partycji logicznej kontenera są wykonywane transakcyjnie w aplice bazy danych hostowanej przez replikę partycji. Te operacje obejmują zarówno operacje zapisu (aktualizowanie co najmniej jednego elementu w partycji logicznej) i operacje odczytu.

W poniższej tabeli wymieniono różne operacje i typy transakcji:

Transakcje obejmujące wiele elementów

Usługa Azure Cosmos DB umożliwia pisanie procedur składowanych, wyzwalaczy i funkcji zdefiniowanych przez użytkownika oraz procedur scalania w języku JavaScript. Usługa Azure Cosmos DB natywnie obsługuje wykonywanie kodu JavaScript wewnątrz aparatu bazy danych. Procedury składowane, wyzwalacze przed/po, funkcje zdefiniowane przez użytkownika i procedury scalania można rejestrować w kontenerze, a następnie wykonywać je transakcyjnie w silniku bazy danych Azure Cosmos DB. Pisanie logiki aplikacji w języku JavaScript umożliwia naturalne wyrażenie przepływu sterowania, określanie zakresu zmiennych, przypisywanie i integrowanie elementów pierwotnych obsługi wyjątków w ramach transakcji bazy danych bezpośrednio w języku JavaScript.

Procedury składowane, wyzwalacze, funkcje UDF i procedury scalania oparte na języku JavaScript są umieszczone w wewnętrznej transakcji ACID z izolacją migawki obejmującą wszystkie elementy w partycji logicznej. Jeśli podczas wykonywania program JavaScript zgłasza wyjątek, cała transakcja zostanie przerwana i wycofana. Wynikowy model programowania jest prosty, ale zaawansowany. Deweloperzy języka JavaScript uzyskują trwały model programowania, a jednocześnie używają znanych konstrukcji językowych i elementów pierwotnych biblioteki.

Możliwość wykonywania kodu JavaScript bezpośrednio w aparacie bazy danych zapewnia wydajność i wykonywanie operacji na bazie danych w sposób transakcyjny wobec elementów kontenera. Ponadto, ponieważ aparat bazy danych usługi Azure Cosmos DB natywnie obsługuje pliki JSON i JavaScript, nie ma niezgodności impedancji między systemami typów aplikacji i bazy danych.

Optymistyczna kontrola współbieżności

Optymistyczna kontrola współbieżności (OCC) umożliwia zapobieganie utracie aktualizacji i usuwania. Konkurencyjne, konfliktowe operacje podlegają regularnemu pesymistycznemu blokowaniu przez silnik bazy danych obsługiwany przez partycję logiczną będącą właścicielem elementu. Gdy dwie współbieżne operacje próbują zaktualizować najnowszą wersję elementu w partycji logicznej, jedna z nich wygrywa, a druga kończy się niepowodzeniem. Jeśli jednak jedna lub dwie operacje próbujące współbieżnie zaktualizować ten sam element wcześniej odczytał starszą wartość elementu, baza danych nie wie, czy wcześniej odczytywana wartość przez operacje powodujące konflikt rzeczywiście była najnowszą wartością elementu.

Na szczęście tę sytuację można wykryć za pomocą OCC przed zezwoleniem dwóm operacjom na wejście w obszar transakcyjny w aparacie bazy danych. OCC chroni dane przed przypadkowym zastąpieniem zmian wprowadzonych przez inne osoby. Zapobiega to również przypadkowemu zastępowaniu własnych zmian przez inne osoby.

Implementowanie optymistycznej kontrolki współbieżności przy użyciu nagłówków ETag i HTTP

Każdy element przechowywany w kontenerze usługi Azure Cosmos DB ma zdefiniowaną _etag właściwość systemową. Wartość elementu _etag jest generowana automatycznie i aktualizowana przez serwer za każdym razem, gdy element jest aktualizowany. _etag można użyć z nagłówkiem żądania dostarczonym przez klienta, aby umożliwić serwerowi podjęcie decyzji, czy element może zostać warunkowo zaktualizowany. Jeśli wartość nagłówka if-match jest zgodna z wartością _etag na serwerze, element zostanie zaktualizowany. Jeśli wartość nagłówka if-match żądania nie jest już aktualna, serwer odrzuca operację z komunikatem odpowiedzi "Błąd warunku wstępnego HTTP 412". Następnie klient może ponownie pobrać element, aby uzyskać aktualną wersję elementu na serwerze lub zastąpić tę wersję swoją własną wartością _etag dla tego elementu. Ponadto _etag można użyć z nagłówkiem if-none-match, aby określić, czy ponowne pobranie zasobu jest potrzebne.

Wartość elementu _etag zmienia się za każdym razem, gdy element jest aktualizowany. W przypadku operacji zastępowania elementów if-match, należy wyraźnie określić, że ma to nastąpić w ramach opcji żądania. Przykładowy kod można znaleźć w witrynie GitHub. Wartości _etag są niejawnie sprawdzane dla wszystkich zapisanych elementów, z którymi ma styczność procedura składowana. Jeśli wystąpi jakikolwiek konflikt, procedura składowana wycofa transakcję i zgłosi wyjątek. W przypadku tej metody wszystkie lub żadne zapisy w procedurze składowanej są stosowane niepodzielnie. Jest to sygnał dla aplikacji, aby ponownie zastosować aktualizacje i ponowić próbę oryginalnego żądania klienta.

Optymistyczna kontrola współbieżności i dystrybucja globalna

Współbieżne aktualizacje elementu są poddawane OCC przez warstwę protokołu komunikacyjnego usługi Azure Cosmos DB. W przypadku kont usługi Azure Cosmos DB skonfigurowanych na potrzeby zapisu w jednym regionie usługa Azure Cosmos DB zapewnia, że wersja po stronie klienta elementu aktualizowanego (lub usuwania) jest taka sama jak wersja elementu w kontenerze usługi Azure Cosmos DB. Dzięki temu Twoje zapisy są chronione przed przypadkowym zastąpieniem zapisami innych oraz odwrotnie. W środowisku z wieloma użytkownikami optymistyczna kontrola współbieżności chroni przed przypadkowym usunięciem lub zaktualizowaniem niewłaściwej wersji elementu. W związku z tym elementy są chronione przed znanymi problemami "utraconych aktualizacji" lub "utraconego usunięcia".

Na koncie usługi Azure Cosmos DB skonfigurowanym z zapisami w wielu regionach dane mogą być zatwierdzane niezależnie w regionach pomocniczych, jeśli _etag są zgodne z danymi w regionie lokalnym. Po zatwierdzeniu nowych danych lokalnie w regionie pomocniczym, są następnie scalane w regionie centralnym lub głównym. Jeśli polityki rozwiązywania konfliktów scalą nowe dane z regionem centralnym, dane są następnie replikowane globalnie przy użyciu nowego elementu _etag. Jeśli zasady rozwiązywania konfliktów odrzucają nowe dane, region pomocniczy zostanie wycofany do oryginalnych danych i _etag.

Dalsze kroki

Dowiedz się więcej o transakcjach bazy danych i optymistycznej kontroli współbieżności:

• Bazy danych, kontenery i elementy w usłudze Azure Cosmos DB
• Poziomy spójności w usłudze Azure Cosmos DB
• Typy konfliktów i zasady rozwiązywania problemów
• Transakcyjne operacje wsadowe w usłudze Azure Cosmos DB
• Procedury składowane, wyzwalacze i funkcje zdefiniowane przez użytkownika