mongodb

Czy wiesz, jak bezprzerwowo zmienić schemat w MongoDB?

26 stycznia 2024

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.

{
    "_id": "<ObjectId>",
    "name": "Anakin Skywalker",
    "home": "503-555-0000",
    "work": "503-555-0010",
    "mobile": "503-555-0120"
}

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.

"contact_method": [
    { "work": "503-555-0210" },
    { "mobile": "503-555-0220" },
    { "twitter": "@anakinskywalker" },
    { "skype": "AlwaysWithYou" }
]

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).

{
    "_id": "<ObjectId>",
    "schema_version": "2",
    "name": "Anakin Skywalker",
    "contact_method": [
        { "work": "503-555-0210" },
        { "mobile": "503-555-0220" },
        { "twitter": "@anakinskywalker" },
        { "skype": "AlwaysWithYou" }
    ]
}

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.

Przydatne linki

Najnowsze wpisy