Wyobraźmy sobie konieczność wprowadzenia zmian w schemacie. Przy tradycyjnym podejściu musielibyśmy zatrzymać aplikację, dokonać migracji bazy i dopiero po jej zakończeniu uruchomić aplikację. Co jeśli nasza kolekcja jest już bardzo duża albo przerwy nie są akceptowalne? Jest też ryzyko, że nastąpi błąd przy migracji, a powrót do poprzedniej wersji w niektórych przypadkach może być dużym problemem. Co proponuje MongoDB? Schema Versioning Pattern.
Kiedy użyć?
kiedy nie może być przerwy w dostępie do systemu
kiedy aktualizacja dokumentów może zająć godziny, dni lub tygodnie
kiedy nie trzeba aktualizować wszystkich dokumentów do nowej wersji
Przykład
Pierwotnie zamodelowaliśmy dane kontaktowe w następujący sposób.
Minęło trochę czasu, mamy już dużo dokumentów w naszej kolekcji, ale zmieniły się wymagania i musimy przechowywać więcej danych kontaktowych, związanych z nowymi formami komunikacji. Znamy na szczęście Attribute Pattern i decydujemy się wprowadzić nie tylko nowe pola, ale i zastosować ten wzorzec - dodajemy pole contact_method.
Nie możemy sobie jednak pozwolić na przerwę w działaniu aplikacji i migrację od razu wszystkich dokumentów. Nowe dokumenty będą miały już tylko pole contact_method, a stare jeszcze dawne pola home, work, mobile. Kod aplikacji będzie więc tworzył nowe dokumenty z polem contact_method przy dodawaniu. Może też ewentualnie aktualizować stare dokumenty przy okazji update’u.
Wymaga to od nas dostosowania kodu aplikacji do dokumentów w dwóch różnych wersjach. Twórcy Mongo proponują bardzo proste rozwiązanie - dodanie dodatkowego pola schema_version w nowych dokumentach (lub zwiększenie wartości schema_version, jeśli już istnieje).
Mamy więc dokumenty w dwóch różnych wersjach, a nasz kod musi poradzić sobie z obsługą obu wersji. Dodatkowo, wskazane jest, żeby rozróżniać wersje na podstawie wartości pola schema_version (w przeciwieństwie do wykrywania np. czy dane pole istnieje). Możemy równocześnie wykonać w tle masową aktualizację i zadecydować sami, kiedy ma się wydarzyć. W kolejnej wersji aplikacji możemy też zdecydować o pozbyciu się kodu obsługującego obydwie wersje.
Zauważmy jednak, że w skrajnym przypadku w okresie przejściowym będziemy potrzebować więcej indeksów - dotychczasowy, wspierający poprzednią wersję i nowy, wspierający nową wersję.
Osobną kwestią, o której nie można zapomnieć, jest walidacja takiego schematu. Warto pamiętać, że chociaż Mongo, jako baza NoSQL, uznawana jest za schemaless, to pozwala na walidacje schematu, np. wymagalności pól.
Podsumowanie
Plusy:
bezprzerwowa migracja,
możliwość zarządzania migracją (kiedy i jak się odbędzie).
Minusy:
może być konieczność utrzymywania 2 indeksów do czasu zakończenia migracji,
jeśli korzystamy z walidacji schematu, może wystąpić konieczność dostosowania walidacji do dwóch wersji.