W dyskusjach na temat baz danych NoSQL kontra SQL czasami słyszę, że firmy wolą korzystać z baz danych NoSQL bez schematu, ponieważ migracja schematu do nowej wersji jest problematyczna. Ale czy to naprawdę duży problem podczas aktualizacji? Czy relacyjne bazy danych są nieodpowiednie dla takich operacji?
Przeczytałem ten post na blogu na blogu MongoDB: Dlaczego Schemaless?
Odpowiedzi:
To, że twoja baza danych NoSql nie ma schematu w tradycyjnym sensie, nie oznacza, że nie ma logicznego schematu, z którym musisz sobie radzić, gdy się zmienia. W przypadku typowej aplikacji korzystającej z MongoDb najprawdopodobniej Twój kod oczekuje, że pewne pola obiektu json zachowują się w określony sposób. Jeśli zmienisz zachowanie, wynika z tego, że możesz chcieć zaktualizować już istniejące dane w bazie danych. Teraz, w przypadku tradycyjnych RDBMS był to w dużej mierze rozwiązany problem - wystarczyło ZMIENIĆ bazowe tabele. Ale z tymi nowomodowanymi bazami danych NoSQL masz decyzję - czy piszesz skrypt, aby munge i zaktualizować wszystkie swoje obiekty? A może dodajesz kod do konwersji między wersjami w locie? Jeśli tak, to jak długo obsługujecie obiekty v1? Na zawsze? Do wersji v3?
Dodam, że przykład użyty w blogu MongoDb jest nieco uproszczony i bardzo łatwy w obsłudze, jeśli masz przyzwoity proces aktualizacji bez względu na to, czym jest RDBMS; dodanie pola rzadko boli. To kiedy decydujesz się podzielić swoje Namepole FirstNamei LastNamesprawy stają się ekscytujące.
Ale czy to naprawdę duży problem podczas aktualizacji?
To może być.
Niektóre organizacje są - dobrze - zdezorganizowane i bardzo źle wykonują migrację schematu.
„Weekend migracji”. Zatrzymaj serwery. Utwórz kopię zapasową i wyeksportuj wszystkie dane. Zbuduj nowy schemat (często poprzez modyfikację istniejącego schematu). Załaduj ponownie dane lub spróbuj przeprowadzić restrukturyzację.
„Ciągłe ulepszanie”. Zmień tabele w zakresie dozwolonym przez SQL. Bez śledzenia sekwencji ALTER wykonanych. Nie ma możliwości powrotu do poprzedniej wersji schematu. W razie potrzeby utwórz nowe tabele z istniejących tabel, miejmy nadzieję, dostosowując wszystkie aplikacje do korzystania z nowych tabel. Ale - brak dobrej jakości - pozostawiając stare tabele „na wszelki wypadek”.
„Pełna panika”. Po prostu zapobiegaj modyfikacjom schematu. Zrób duży smród. Twierdzić, że ryzyko jest zbyt wysokie. Zablokuj wszystkie wysiłki w tym kierunku. Weź zakładnika schematu, aż będziesz zmuszony przyjąć bardziej rozsądne podejście.
Czy relacyjne bazy danych są nieodpowiednie dla takich operacji?
Każdy schemat wymaga migracji.
Największy problem nie ma charakteru technicznego.
Jest semantyczny.
Jednym z głównych powodów zmiany schematu jest to, że poprzedni schemat nie pasuje zbyt dobrze do domeny problemu. Ponieważ semantyka się zmieniła, baza danych (i aplikacje) muszą się zmienić. Czasami są to głębokie zmiany, które wymagają ponownego przemyślenia sposobu działania aplikacji z danymi.
Korekta semantyki bazy danych może być bardzo trudna.
To, co ludzie robią zamiast zmian schematu, to po prostu niewłaściwe użycie schematu fizycznego. Zaczynają ładować nieprawidłowe dane do istniejących pól, ponieważ mogą. Pole „komentarz” nagle zaczyna zawierać ważną informację zarządzania klientem, po której następuje „//”, po którym następuje prawdziwy komentarz. Rośnie to do fragmentów danych „pole 1 - pole 2 // komentarz”. Użytkownicy mają arkusz kalkulacyjny, który wyodrębnia te dodatkowe dane z pola komentarza, ponieważ „prawdziwe” oprogramowanie aplikacji miało schemat trudny do zmiany, a IT odmówił jego zmiany.
Aktualizujemy produkcyjne bazy danych, dodając tabele i (zerowalne) kolumny bez żadnych problemów. Poprzednie wersje aplikacji działają poprawnie z uaktualnioną bazą danych, po prostu nie odwołują się do nowych rzeczy. Unikamy usuwania tabel lub kolumn, ani zmieniania sposobu przechowywania istniejących danych, ale gdy jest to konieczne, tworzymy odpowiednie skrypty konwersji. Bez względu na to, czy baza danych ma zadeklarowany bezpieczny schemat, czy nie, zmiany w strukturze danych wymagają konwersji danych i aktualizacji aplikacji w celu interakcji z nową strukturą.
To zależy.
Po pierwsze, jeśli masz naprawdę dużą bazę danych obejmującą wiele komputerów, wszystko (nie tylko aktualizacja bazy danych) będzie bolesne. (bez względu na to, ile zaplanowałeś wcześniej).
Po drugie, aktualizacja bazy danych NIE jest po prostu kwestią bazy danych - zależy również od większego systemu, którego częścią jest DB. Obejmuje to także wdrożenie bazy danych (wiele serwerów baz danych, wiele centrów danych, konfiguracje master-slave itp.)
Ból można złagodzić przez takie skonstruowanie komponentów systemu, aby wszystkie miały pewne „rozpoznanie” zdarzenia zmiany schematu DB. Oznacza to, że cały system powinien tolerować zmiany schematu i reagować na nie w sposób „rozsądny”.
Możesz sprawdzić narzędzie opracowane przez Facebook do rozwiązywania aktualizacji schematów MySQL.
Istnieją również standardowe najlepsze praktyki, takie jak przekształcanie w master tylko do odczytu, wprowadzanie zmian w slaveach lub na kopiach programistycznych itp.
W każdym razie MUSISZ mieć pełną kopię zapasową i obszerny zestaw testów . Tylko wtedy możesz bezpiecznie i bezpiecznie dokonywać zmian.