Dlaczego optymistyczne blokowanie jest szybsze niż blokowanie pesymistyczne?

Obie formy blokowania powodują, że proces czeka na poprawną kopię rekordu, jeśli jest on aktualnie używany przez inny proces. W przypadku pesymistycznego blokowania mechanizm blokowania pochodzi od samej bazy danych (natywny obiekt blokady), podczas gdy w przypadku blokowania optymistycznego mechanizm blokowania jest pewną wersją wersjonowania wierszy, taką jak znacznik czasu, aby sprawdzić, czy rekord jest „nieaktualny”, czy nie.

Ale oba powodują zawieszenie drugiego procesu. Pytam więc: dlaczego optymistyczne blokowanie jest ogólnie uważane za szybsze / lepsze niż blokowanie pesymistyczne? I czy są przypadki użycia, w których pesymizm jest lepszy niż optymistyczny? Z góry dziękuję!

Zduplikowane pytanie z:

/programming/129329/optimistic-vs-pessimistic-locking

Skopiuj / Wklej odpowiedź z powyższego linku:

Optymistyczne blokowanie to strategia polegająca na czytaniu rekordu, zanotowaniu numeru wersji i sprawdzeniu, czy wersja nie uległa zmianie przed ponownym zapisaniem rekordu. Kiedy zapisujesz rekord z powrotem, filtrujesz aktualizację do wersji, aby upewnić się, że jest atomowa. (tzn. nie został zaktualizowany między sprawdzeniem wersji i zapisaniem rekordu na dysku) a aktualizacją wersji za jednym razem.

Jeśli zapis jest brudny (tzn. Inna wersja niż Twoja), przerywasz transakcję, a użytkownik może ją ponownie uruchomić.

Strategia ta ma największe zastosowanie do systemów o dużej objętości i architektur trójwarstwowych, w których niekoniecznie utrzymuje się połączenie z bazą danych dla sesji. W tej sytuacji klient nie może faktycznie utrzymywać blokad bazy danych, ponieważ połączenia są pobierane z puli i możesz nie używać tego samego połączenia z jednego dostępu do następnego.

Blokowanie pesymistyczne ma miejsce, gdy blokujesz rekord na wyłączny użytek, dopóki go nie skończysz. Ma znacznie lepszą integralność niż optymistyczne blokowanie, ale wymaga ostrożności podczas projektowania aplikacji, aby uniknąć Deadlocks. Aby użyć blokowania pesymistycznego, potrzebujesz albo bezpośredniego połączenia z bazą danych (jak to zwykle bywa w przypadku dwupoziomowej aplikacji serwera klienta), albo dostępnego z zewnątrz identyfikatora transakcji, którego można używać niezależnie od połączenia.

W tym ostatnim przypadku otwierasz transakcję za pomocą TxID, a następnie ponownie łączysz się przy użyciu tego identyfikatora. DBMS utrzymuje blokady i pozwala wybrać sesję z powrotem poprzez TxID. Tak działają transakcje rozproszone z wykorzystaniem protokołów zatwierdzania dwufazowego (takich jak Transakcje XA lub COM +).

Edytuj (dodając więcej informacji, aby odpowiedzieć na pytanie dotyczące wydajności):

Wydajność zależy od środowiska. Podejmij następujące czynniki, aby podjąć decyzję:

przekonasz się, że optymizm będzie lepszy ze względu na współbieżność w większości sytuacji. Jednak w zależności od RDBMS i środowiska może to być mniej lub bardziej wydajne. Zazwyczaj przy blokowaniu optymistycznym okaże się, że wartość musi być gdzieś wersjonowana.

Na przykład w MS SQL Server zostaje przeniesiony do TempDB i na końcu kolumny dołączane jest coś między 12-14 bajtami. Włączenie optymistycznego blokowania z poziomem izolacji, takim jak Izolacja migawki, może spowodować fragmentację, a współczynnik wypełnienia będzie musiał zostać dostosowany, ponieważ wiersze mają teraz dodatkowe dane na końcu, co może spowodować, że strona prawie pełna spowoduje podział strony, co obniży się Twój występ. Jeśli twój TempDB nie jest zoptymalizowany, nie będzie tak szybko.

Sądzę więc, że lista kontrolna to:

• - Czy masz wystarczającą liczbę operacji we / wy do obsługi wersji wersjonowania wierszy? Jeśli nie, dodajesz koszty ogólne. Jeśli tak, to jeśli często czytasz dane, gdy często blokujesz je dla operacji zapisu, zauważysz dobrą poprawę współbieżności między odczytami i zapisami (chociaż zapisy nadal będą blokować zapisy, odczyty nie będą już blokować zapisów i na odwrót)
• -Czy twój kod jest podatny na zakleszczenia lub występuje blokowanie? Jeśli nie doświadczasz długich blokad lub wielu zakleszczeń, dodatkowy narzut optymistycznego blokowania nie przyspieszyłby, oczywiście, w większości przypadków mówimy tutaj o milisekundach.
• -Jeśli twój DB jest duży (lub na bardzo ograniczonym sprzęcie), a twoje strony danych są prawie pełne, w zależności od RDBMS, możesz spowodować poważne podziały stron i fragmentację danych, więc po włączeniu pamiętaj o ponownym indeksowaniu.

To są moje przemyślenia na ten temat, otwarte na więcej wiadomości od społeczności.

Nie rozumiesz optymistycznego blokowania.

Optymistyczne blokowanie nie powoduje, że transakcje na siebie czekają.

Optymistyczne blokowanie może być przyczyną niepowodzenia transakcji, ale dzieje się tak bez jakiegokolwiek „blokowania”. A jeśli transakcja nie powiedzie się z powodu optymistycznego blokowania, użytkownik musi rozpocząć wszystko od nowa. Słowo „optymistyczny” wywodzi się dokładnie z oczekiwania, że ​​warunek powodujący niepowodzenie transakcji z tego właśnie powodu wystąpi tylko bardzo wyjątkowo. „Optymistyczne” blokowanie to podejście, które mówi: „Nie będę brać rzeczywistych blokad, ponieważ mam nadzieję, że i tak nie będą potrzebne. Jeśli okaże się, że się myliłem, zaakceptuję nieuniknioną awarię”.

Blokowanie optymistyczne jest generalnie szybsze, ponieważ w rzeczywistości nie ma blokowania z punktu widzenia bazy danych. Od aplikacji zależy, czy ma respektować kolumnę wersji (lub pseudokolumnę, taką jak ora_rowscn), czy nie. Zwykle masz wiele aplikacji podłączonych do tej samej bazy danych, więc db staje się zasobem współdzielonym, a jeśli zawiesi się, dotyczy to wszystkich klientów.

Przy optymistycznej strategii blokowania „zawieszanie” odbywa się po stronie klienta i nie wpływa na innych.

Jeśli jednak rekord jest często aktualizowany, może się okazać, że będzie on czytany zbyt wiele razy (w przypadku blokowania optymistycznego), co w ten sposób pokona największe korzyści strategii optymistycznej.

Nie zgodziłbym się co do wyższości któregokolwiek z tych podejść; oba mogą być niewłaściwie wykorzystywane. Pesymizm jest bardziej podatny na błędy tylko dlatego, że jest bardziej niebezpieczny: blokowanie odbywa się na poziomie db, zależy od RDMS, możesz nie mieć kontroli nad tym, co jest zablokowane (eskalacja blokady), musisz ręcznie zarządzać kolejnością blokowania.

Optymistyczne blokowanie zakłada, że ​​jednoczesne transakcje mogą zostać zakończone bez wzajemnego wpływu. Tak więc optymistyczne blokowanie jest szybsze, ponieważ żadne blokady nie są wymuszane podczas wykonywania transakcji. Jest to zapobieganie powodowaniu problemów z jednoczesną nieuleczeniem. Transakcja tylko weryfikuje (trzy sposoby, zestawy danych, znacznik czasu typ danych, sprawdź starą i nową wartość) dane, czy żadna inna transakcja ich nie zmodyfikowała. W przypadku modyfikacji transakcja jest wycofywana.

Blokowanie pesymistyczne zakłada, że ​​współbieżne transakcje będą ze sobą kolidować, więc wymaga blokady, odbywa się to poprzez określenie poziomu izolacji (Odczyt niezaangażowany, Odczyt zatwierdzony, Powtarzalny odczyt i Serializowalny) zarządzania transakcjami. Leczy problemy współbieżności poprzez uzyskanie blokady. zamki służą do ochrony wspólnych zasobów lub obiektów (tabele, wiersze danych, bloki danych, elementy buforowane, połączenia i całe systemy). Mamy wiele rodzajów blokad, takich jak blokady współdzielone, blokady aktualizacji, blokady wpuszczane, blokady ekskluzywne, blokady transakcji, blokady DML, blokady schematu i blokady odzyskiwania kopii zapasowej.

aby uzyskać więcej pomysłów

Fałszywe jest twierdzenie, że pesymistyczne blokowanie jest wolniejsze niż optymistyczne lub twierdzenie, że optymizm jest szybszy. Jednym z klasycznych zapytań, które ma wykazać ten nieodpowiedni sposób myślenia, jest wykonanie agregacji dla różnych RDBMS, takich jak:

SELECT COUNT(*) FROM atable

Zobaczysz, że w RDBMS, który obsługuje natywnie optymistyczne podejście, czas potrzebny na to zapytanie jest znacznie bardziej znaczący niż w przypadku tych, którzy mają natywną blokadę pesymistyczną

Na przykład na moim komputerze to samo zapytanie zajmuje 27 ms na serwerze SQL i 109 na PostGreSQL ...

Dodatkowy narzut potrzebny do odczytania martwych wersji wierszy MVCC i nie liczenia rekordów duchów w agregacie powoduje dodatkowe koszty, których pesymista nie ma!