Trwałość to „D” we właściwościach „ACID” (A – Atomicity, C – Consistency, I – Isolation), spopularyzowane przez tradycyjne systemy zarządzania relacyjnymi bazami danych (RDBMS). Trwałość to gwarancja, że zapisane dane zostały zapisane i przetrwają na stałe. Bazy danych NoSQL, takie jak MongoDB, zapewniają programistom dokładną kontrolę nad trwałością wywołań zapisu. Umożliwia to programistom wybór różnych modeli trwałości, bezpieczeństwa i wydajności dla różnych klas danych. Jednak nakłada to również na programistę obowiązek dostrzeżenia i zrozumienia niuansów różnych opcji bezpieczeństwa zapisu. W tym poście przyjrzymy się różnym opcjom bezpieczeństwa zapisu dostępnym w sterowniku Java.
W żargonie MongoDB nazywa się to „zainteresowaniem pisemnym”. Pisz obawy, od „słabych” do „silnych”. Słabe problemy związane z zapisem mogą prowadzić do wyższej przepustowości, ale zapewniają mniejsze bezpieczeństwo danych, a poważne obawy związane z zapisem są odwrotnie.
Sterownik Java umożliwia określenie opcji bezpieczeństwa zapisu przy użyciu kilku konstruktorów teleskopowych. Oto konstruktor ze wszystkimi opcjami:
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Jak widać, ten konstruktor ma wiele opcji. Aby ułatwić programistom, udostępniono „Tagi” dla typowych wartości związanych z zapisem — Unacknowledged, Acknowledged, Journalled, Fsynced i Replica Acknowledged. Każdy tag jest mapowany na określone wywołanie powyższego konstruktora.
Niepotwierdzony tryb MongoDB
To jest tryb „odpal i zapomnij”. Sterownik MongoDB nie próbuje potwierdzać odbioru operacji zapisu. Na przykład, jeśli twoja usługa MongoDB nie działa i używasz tego trybu, wszystkie błędy są dyskretnie ignorowane, a twoje dane zostają utracone. Oczywiście należy używać tego trybu tylko w przypadku danych o niskiej wartości, gdzie przepustowość zapisu jest ważniejsza niż utrata określonej ilości danych. Ten tryb można określić w następujący sposób:
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Tryb potwierdzenia MongoDB
Jest to domyślny tryb zapisu dla MongoDB. W tym trybie drajwer MongoDB próbuje potwierdzić odebranie operacji zapisu na serwerze, pozwalając mu wyłapać ewentualne błędy sieciowe, błędy zduplikowanych kluczy itp. Nie gwarantuje to jednak, że dane zostaną zapisane na dysku. Jeśli serwer MongoDB ulegnie awarii po potwierdzeniu zapisu, ale przed zapisaniem go na dysku, dane zostaną utracone. Ten tryb można określić w następujący sposób:
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
Tryb dziennika MongoDB
W tym trybie serwer MongoDB potwierdza zapis dopiero po przesłaniu danych do dziennika. W przypadku korzystania z tego trybu, nawet jeśli serwer ulegnie awarii podczas restartu serwera, dane z dziennika zostaną ponownie zastosowane. Oczywiście, aby to zadziałało, musi być włączone księgowanie. Wszystkie systemy produkcyjne powinny mieć włączone księgowanie. Więcej informacji na ten temat znajdziesz w naszym poście. Czy należy włączyć księgowanie MongoDB?
W scenariuszu zestawu replik, problemy związane z zapisem w dzienniku dotyczą tylko podstawowego. Domyślnie dziennik jest umieszczany na dysku co 100 ms. Po określeniu zapisu z opcją księgowania, dziennik jest zapisywany na dysku w ciągu 30 ms. Tak więc, jeśli określisz j:true dla każdego zapisu, Twoja przepustowość będzie wynosić maksymalnie 1000/30 =33,3 zapisów/s. Jeśli chcesz uzyskać lepszą przepustowość, musisz grupować aktualizacje i ustawić j:true dla ostatniej aktualizacji partii. Ten tryb można określić w następujący sposób:
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Tryb Fsynced MongoDB
W tym trybie serwer MongoDB potwierdza zapis dopiero po zapisie na dysku. Ten tryb można określić w następujący sposób:
new WriteConcern(true) / WriteConcern.FSYNCED
Tryb potwierdzonych replik MongoDB
Poprzednie tryby bezpieczeństwa zapisu dotyczą tylko jednego serwera. Po uruchomieniu zestawów replik masz możliwość kontrolowania liczby replik, które należy napisać, zanim zostanie uznany za udany. Na przykład, jeśli chodzi o zapis „w:2”, zapis musi zostać zapisany do jednego podstawowego i co najmniej jednego dodatkowego, zanim zostanie uznany za udany. Zmniejsza to przepustowość, ale zapewnia większe bezpieczeństwo. Jeśli nie znasz wcześniej liczby replik, możesz użyć tagu WriteConcern.MAJORITY, aby upewnić się, że dane są zapisywane w większości replik. To najbezpieczniejsza opcja w MongoDB. Jeśli zamierzasz użyć tej opcji, upewnij się również, że ustawiłeś wartość „wtimeout”, aby wskazać, jak długo polecenie powinno czekać, zanim zwróci błąd:
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
Następujące tagi zostały wycofane (lub mają być) – ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Użyj nowszych opcji zamiast tych. Jak zawsze, jeśli masz jakieś uwagi lub pytania, skontaktuj się z nami pod adresem [email protected].
