Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 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 zgodne z ACID (niepodzielność, spójność, izolacja, trwałość) ze wsparciem dla izolacji migawkowej. 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:
| Operacja | Typ operacji | Transakcja pojedynczego lub wielu przedmiotów |
|---|---|---|
| Wstaw (bez wyzwalacza przed/po) | Napisz | Transakcja pojedynczego elementu |
| Wstaw (z przed/po wyzwalaczem) | Zapis i odczyt | Transakcja z wieloma elementami |
| Zamień (bez wyzwalacza przed/po) | Napisz | Transakcja pojedynczego elementu |
| Zamień (z wyzwalaczem wstępnym/końcowym) | Zapis i odczyt | Transakcja z wieloma elementami |
| Upsert (bez wyzwalacza przed/po) | Napisz | Transakcja pojedynczego elementu |
| Upsert (z wyzwalaczem przed/po) | Zapis i odczyt | Transakcja z wieloma elementami |
| Usuń (bez wyzwalacza przed/po) | Napisz | Transakcja pojedynczego elementu |
| Usuń (z wyzwalaczem przed/po) | Zapisywanie i odczytywanie | Transakcja z wieloma elementami |
| Wykonaj procedurę składowaną | Zapis i odczyt | Transakcja z wieloma elementami |
| Zainicjowanie wykonania procedury scalania przez system | Napisz | Transakcja z wieloma elementami |
| Systemowe inicjowanie usuwania elementów na podstawie daty wygaśnięcia (TTL). | Napisz | Transakcja z wieloma elementami |
| Przeczytaj | Przeczytaj | Transakcja pojedynczego przedmiotu |
| Źródło zmian | Przeczytaj | Transakcja z wieloma elementami |
| Odczyt podzielony na strony | Przeczytaj | Transakcja z wieloma elementami |
| Stronicowane zapytanie | Przeczytaj | Transakcja z wieloma elementami |
| Wykonaj funkcję zdefiniowaną przez użytkownika w ramach zapytania stronicowanego | Przeczytaj | Transakcja z wieloma elementami |
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 JavaScript wewnątrz silnika bazy danych. Można rejestrować procedury przechowywane, wyzwalacze przed i po, funkcje definiowane przez użytkownika oraz procedury scalania w kontenerze, a następnie wykonywać je transakcyjnie w kontekście silnika 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 otoczenie transakcji ACID z izolacją migawkową dla wszystkich elementów w obrębie 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 silniku bazy danych zapewnia wydajność oraz transakcyjne wykonywanie operacji bazodanowych na elementach 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 utraconym aktualizacjom i usunięciom. 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 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 granicę transakcji wewnątrz silnika 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 kontroli 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 if-match, aby pozwolić serwerowi zdecydować, czy element może zostać zaktualizowany warunkowo. 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 pobrać ponownie 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łówkiem_etag, aby określić, if-none-match 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. Wartości _etag są niejawnie sprawdzane w odniesieniu do wszystkich zapisanych elementów objętych procedurą składowaną. Jeśli zostanie wykryty 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 po stronie klienta elementu aktualizowanego (lub usuwania) 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 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 lokalnym zatwierdzeniu nowych danych w regionie pomocniczym, są one następnie scalane w regionie głównym. Jeśli zasady rozwiązywania konfliktów scalą nowe dane z regionem centrum, te dane są replikowane globalnie przy użyciu nowego _etagelementu . Jeśli zasada rozwiązywania konfliktów odrzuci nowe dane, region pomocniczy zostanie przywrócony do oryginalnych danych i _etag.
Następne kroki
Dowiedz się więcej o transakcjach bazy danych i optymistycznej kontroli współbieżności: