Unikanie blokad datastore

Share

Blokada datastore (Datastore contention) pojawia się się, gdy dana jedna encja lub jedna grupa encji jest aktualizowana zbyt często. Jeżeli dwa lub więcej żądań przybędzie równocześnie i każde z nich będzie chciało zaktualizować daną encję, to przynajmniej jedno z tych żądań skończy się niepowodzeniem. Optymistyczne zarządzanie współbieżnością stosowane przez datastore zapobiega potencjalnemu nadpisaniu nowych danych dodanych przez pierwsze żądanie. Datastore spróbuje kilka razy automatycznie ponowić nieudane żądanie zanim wyrzuci wyjątek (timeout). Jeżeli planujesz że jakaś encja będzie często aktualizowana, czy też jedna grupa encji będzie często aktualizowana lub poszerzana o nowe encje (kilka razy na sekundę) to najlepiej będzie przebudować modele/projekt tak by uniknąć problemów blokady, gdy projekt ruszy na produkcję.

Jak unikać blokad?

Grupy encji powinny być małe. Jako że operacje w datastore są atomowe (albo wszystkie aktualizacje są nałożone lub żadne) to aktualizacja encji w obrębie grupy blokuje zmiany we wszystkich encjach na czas zakończenia transakcji. Encje nie należące do tej samej grupy można aktualizować równocześnie bez blokad. Dokumentacja zaleca by grupy stosować tylko tam gdzie konieczne są transakcje na grupie. Grup nie musimy też stosować, gdy chcemy mieć referencję jednej encji zapisanej w drugiej (poprzez ReferenceProperty).

Shardowanie często aktualizowanych encji. Jeżeli przewidujesz że encja może być aktualizowana przez 1-2 żądania na sekundę to należy rozbić aktualizację na zbiór shardów rozpraszających operacje aktualizacji na N niezależnych encji. Datastore bardzo dobrze obsługuje równoczesne, współbierzne wykonywanie operacji na niezależnych encjach i shardowanie znacząco zwiększa przepustowość aktualizacji (co opisano w artykule shardowanych liczników).

Podsumowanie

App Engine to świetna platforma do budowania skalowalnych aplikacji webowych, ale to twórca aplikacji musi efektywnie wykorzystać dostarczone narzędzia i rozwiązania, żeby ta skalowalność była dostępna. Ważne jest by na samym początku projektowania aplikacji wykorzystać silne strony platformy, dzięki czemu przy gwałtownym wzroście popularności aplikacja nawet się nie zająknie, a użytkownicy nie doświadczą typowego dla wielu startupów zamulenia serwisu ;)