Udostępnij za pośrednictwem

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

  • Artykuł

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 do wykonywania bezpośrednio w aucie bazy danych. W przypadku tradycyjnych relacyjnych baz danych należy radzić sobie z dwoma różnymi językami programowania aplikacji (bez transakcji), takimi jak JavaScript, Python, C#, Java itp. oraz transakcyjny język programowania (np. T-SQL), który jest natywnie wykonywany przez bazę danych.

Aparat bazy danych w usłudze Azure Cosmos DB obsługuje pełne transakcje zgodne z funkcją 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 wielu elementów
Wstawianie (bez wyzwalacza przed/po) Write Transakcja pojedynczego elementu
Wstaw (z wyzwalaczem wstępnym/po) Zapis i odczyt Transakcja z wieloma elementami
Zamień (bez wyzwalacza przed/po) Write Transakcja pojedynczego elementu
Zamień (na wyzwalacz wstępny/post) Zapis i odczyt Transakcja z wieloma elementami
Upsert (bez wyzwalacza przed/po) Write Transakcja pojedynczego elementu
Upsert (z wyzwalaczem wstępnym/po) Zapis i odczyt Transakcja z wieloma elementami
Usuwanie (bez wyzwalacza przed/po) Write Transakcja pojedynczego elementu
Usuwanie (z wyzwalaczem wstępnym/po) Zapis i odczyt Transakcja z wieloma elementami
Wykonaj procedurę składowaną Zapis i odczyt Transakcja z wieloma elementami
Zainicjowane przez system wykonanie procedury scalania Write Transakcja z wieloma elementami
Zainicjowane przez system wykonywanie usuwania elementów na podstawie wygaśnięcia (TTL) elementu Write Transakcja z wieloma elementami
Przeczytaj Przeczytaj Transakcja pojedynczego elementu
Zestawienie zmian Przeczytaj Transakcja z wieloma elementami
Odczyt podzielony na strony Przeczytaj Transakcja z wieloma elementami
Zapytanie podzielone na strony Przeczytaj Transakcja z wieloma elementami
Wykonywanie funkcji zdefiniowanej przez użytkownika w ramach zapytania podzielonego na strony Przeczytaj 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 (UDF) i procedury scalania można zarejestrować 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, wyzwalacze, funkcje zdefiniowane przez użytkownika i procedury scalania oparte na języku JavaScript są opakowane w otoczenia transakcji ACID z izolacją migawki 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 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 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 pliki JSON i JavaScript, nie ma niezgodności impedancji 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. Współbieżne operacje powodujące konflikt podlegają regularnemu pesymistycznemu zablokowaniu 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 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 był rzeczywiście najnowszą wartością elementu. Na szczęście tę sytuację można wykryć za pomocą optymistycznej kontroli współbieżności (OCC) przed zezwoleniem dwóm operacjom na wejście granicy transakcji wewnątrz aparatu 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 dostarczonym 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ą na serwerze, element jest następnie aktualizowany. 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ć bieżącą wersję elementu na serwerze lub zastąpić wersję elementu na serwerze własną _etag wartością elementu. Ponadto można użyć z nagłówkiemif-none-match, aby określić, _etag czy jest potrzebne 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. Przykładowy kod można znaleźć w witrynie GitHub. _etag wartości są niejawnie sprawdzane dla wszystkich zapisanych elementów dotkniętych procedurą składowaną. 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 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 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 elementu aktualizowanego (lub usuwania) po stronie klienta jest taka sama jak wersja elementu w kontenerze usługi Azure Cosmos DB. Dzięki temu zapisy są chronione przed przypadkowym zastąpieniem przez zapisy innych i odwrotnie. W środowisku z wieloma użytkownikami 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 "utraconych aktualizacji" lub "utraconym usunięciem".

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 jest on następnie scalony w regionie 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 na temat transakcji bazy danych i optymistycznej kontroli współbieżności w następujących artykułach: