Transakcje i optymistyczna kontrola współbieżności
DOTYCZY: 
NoSQL
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/lub wyzwalaczy, wysyłają je do serwera w celu wykonania bezpośrednio w a aparatze bazy danych. W przypadku tradycyjnych relacyjnych baz danych wymagane jest radzenie sobie z dwoma różnymi językami programowania (bez transakcji) językiem programowania aplikacji, takim jak JavaScript, Python, C#, Java itp. oraz język programowania transakcyjnego (na przykład T-SQL), który jest natywnie wykonywany przez bazę danych.
Aparat bazy danych w usłudze Azure Cosmos DB obsługuje pełne transakcje ACID (niepodzielność, spójność, izolacja, trwałość) z izolacją migawki. 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 przedstawiono różne operacje i typy transakcji:
| Operacja | Typ operacji | Transakcja pojedynczego lub wielokrotnego elementu |
|---|---|---|
| Wstaw (bez wyzwalacza pre/post) | Zapisywanie | Transakcja pojedynczego elementu |
| Wstawianie (z wyzwalaczem wstępnym/postem) | Zapis i odczyt | Transakcja z wieloma elementami |
| Zamień (bez wyzwalacza pre/post) | Zapisywanie | Transakcja pojedynczego elementu |
| Zamień (na wyzwalacz wstępny/post) | Zapis i odczyt | Transakcja z wieloma elementami |
| Upsert (bez wyzwalacza pre/post) | Zapisywanie | Transakcja pojedynczego elementu |
| Upsert (z wyzwalaczem wstępnym/po) | Zapis i odczyt | Transakcja z wieloma elementami |
| Usuwanie (bez wyzwalacza pre/post) | Zapisywanie | Transakcja pojedynczego elementu |
| Usuwanie (z wyzwalaczem wstępnym/po) | Zapis i odczyt | Transakcja z wieloma elementami |
| Wykonywanie procedury składowanej | Zapis i odczyt | Transakcja z wieloma elementami |
| Zainicjowane przez system wykonanie procedury scalania | Zapisywanie | Transakcja z wieloma elementami |
| Zainicjowane przez system wykonywanie usuwania elementów na podstawie wygaśnięcia (TTL) elementu | Zapisywanie | Transakcja z wieloma elementami |
| Odczyt | Odczyt | Transakcja pojedynczego elementu |
| Zestawienie zmian | Odczyt | Transakcja z wieloma elementami |
| Odczyt podzielony na strony | Odczyt | Transakcja z wieloma elementami |
| Zapytanie podzielone na strony | Odczyt | Transakcja z wieloma elementami |
| Wykonywanie funkcji UDF w ramach zapytania podzielonego na strony | Odczyt | Transakcja z wieloma elementami |
Transakcje obejmujące wiele elementów
Usługa Azure Cosmos DB umożliwia pisanie procedur składowanych, wyzwalaczy wstępnych/post, funkcji zdefiniowanych przez użytkownika i procedur scalania w języku JavaScript. Usługa Azure Cosmos DB natywnie obsługuje wykonywanie języka JavaScript wewnątrz aparatu bazy danych. Procedury składowane, wyzwalacze wstępne/post, funkcje zdefiniowane przez użytkownika i procedury scalania można rejestrować w kontenerze, a później wykonywać je transakcyjnie w akompaniacie bazy danych usługi 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 oparte na języku JavaScript, wyzwalacze, funkcje zdefiniowane przez użytkownika i procedury scalania są opakowane w otoczenia transakcji ACID z izolacją migawek we wszystkich elementach w partycji logicznej. W trakcie wykonywania, jeśli program JavaScript zgłasza wyjątek, cała transakcja zostanie przerwana i wycofana. Wynikowy model programowania jest prosty, ale zaawansowany. Deweloperzy języka JavaScript otrzymują trwały model programowania, używając jednocześnie znanych konstrukcji językowych i pierwotnych bibliotek.
Możliwość wykonywania kodu JavaScript bezpośrednio w a aparatze bazy danych zapewnia wydajność i transakcyjne wykonywanie operacji bazy danych względem elementów kontenera. Ponadto, ponieważ aparat bazy danych usługi Azure Cosmos DB natywnie obsługuje format JSON i JavaScript, nie ma niezgodności impedance między systemami typów aplikacji a bazą danych.
Optymistyczna kontrola współbieżności
Optymistyczna kontrola współbieżności umożliwia zapobieganie utracie aktualizacji i usuwania. Równoczesne operacje powodujące konflikty podlegają regularnemu pesymistycznemu blokowaniu aparatu bazy danych hostowanego 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 wygra, a druga zakończy się niepowodzeniem. Jeśli jednak jedna lub dwie operacje próbujące równoczesnie zaktualizować ten sam element wcześniej odczytał starszą wartość elementu, baza danych nie wie, czy poprzednio odczytywana wartość według jednej lub obu operacji powodujących konflikt była rzeczywiście najnowszą wartością elementu. Na szczęście tę sytuację można wykryć za pomocą optymistycznej kontrolki współbieżności (OCC) przed zezwoleniem na wejście dwóch operacji na granicę transakcji wewnątrz aparatu bazy danych. OCC chroni dane przed przypadkowym zastępowaniem zmian, które zostały wprowadzone 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 właściwość zdefiniowaną _etag przez system. Wartość _etag elementu jest generowana automatycznie i aktualizowana przez serwer za każdym razem, gdy element jest aktualizowany. _etag można użyć z podanym if-match przez klienta nagłówkiem żądania, aby umożliwić serwerowi podjęcie decyzji, czy element może zostać warunkowo zaktualizowany. Wartość nagłówka if-match jest zgodna z _etag wartością serwera, element jest następnie aktualizowany. Jeśli wartość if-match nagłówka żądania nie jest już bieżąca, serwer odrzuca operację z komunikatem odpowiedzi "Błąd warunku wstępnego HTTP 412". Następnie klient może ponownie pobrać element, aby uzyskać bieżącą wersję elementu na serwerze lub zastąpić wersję elementu na serwerze z własną _etag wartością elementu. Ponadto można użyć z nagłówkiemif-none-match, aby określić, _etag czy konieczne jest ponowne pobranie zasobu.
Wartość elementu _etag zmienia się za każdym razem, gdy element jest aktualizowany. W przypadku operacji if-match zastępowania elementów należy jawnie wyrazić jako część opcji żądania. Aby zapoznać się z przykładem, zobacz przykładowy kod w usłudze GitHub. _etag wartości są niejawnie sprawdzane dla wszystkich zapisanych elementów dotykanych przez procedurę składowaną. Jeśli zostanie wykryty konflikt, procedura składowana wycofa transakcję i zgłosi wyjątek. W przypadku tej metody wszystkie lub żadne operacje zapisu w procedurze składowanej są stosowane niepodziealnie. 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 podlegają warstwie 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, który aktualizujesz (lub usuwasz), jest taka sama jak wersja elementu w kontenerze usługi Azure Cosmos DB. Gwarantuje to, że zapisy są chronione przed przypadkowym zastępowaniem przez zapisy innych i odwrotnie. W środowisku wielu użytkowników optymistyczna kontrola współbieżności chroni przed przypadkowym usunięciem lub zaktualizowaniem nieprawidłowej wersji elementu. W związku z tym elementy są chronione przed niesławnymi problemami z "utratą aktualizacji" lub "utraconym usuwaniem".
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. Gdy nowe dane zostaną zatwierdzone lokalnie w regionie pomocniczym, zostaną scalone w centrum lub regionie podstawowym. Jeśli zasady rozwiązywania konfliktów scalą nowe dane z regionem centrum, te dane zostaną zreplikowane globalnie przy użyciu nowego _etagelementu . Jeśli zasady rozwiązywania konfliktów odrzucają nowe dane, region pomocniczy zostanie wycofany do oryginalnych danych i _etag.
Następne kroki
Dowiedz się więcej o transakcjach bazy danych i optymistycznej kontroli współbieżności w następujących artykułach: