Udostępnij za pośrednictwem

Kroki premigration migracji danych z bazy danych MongoDB do usługi Azure Cosmos DB dla bazy danych MongoDB

  • Artykuł

DOTYCZY: MongoDB

Ważne

Przeczytaj cały ten przewodnik przed wykonaniem kroków przed migracją. W przypadku migracji do usługi Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB zapoznaj się z opcjami migracji rdzeni wirtualnych

Ten przewodnik po migracji wstępnej bazy danych MongoDB jest częścią serii migracji jednostek RU bazy danych MongoDB. Krytyczne kroki migracji bazy danych MongoDB to czynności przed migracją, migracją i po migracji, jak pokazano w tym przewodniku.

Diagram kroków migracji z przed migracją do po migracji.

Omówienie przed migracją

Przed faktycznym przeniesieniem jakichkolwiek danych ważne jest przeprowadzenie pewnego wcześniejszego planowania i podejmowania decyzji dotyczących migracji. Ten początkowy proces podejmowania decyzji jest "przed migracją".

Twoim celem w wstępnej migracji jest:

  1. Upewnij się, że skonfigurowaliśmy usługę Azure Cosmos DB w celu spełnienia wymagań aplikacji i
  2. Zaplanuj sposób wykonywania migracji.

Wykonaj następujące kroki, aby przeprowadzić dokładną migrację przed migracją

  1. Odkryj istniejące zasoby bazy danych MongoDB i oceń gotowość istniejących zasobów bazy danych MongoDB na potrzeby migracji danych
  2. Mapuj istniejące zasoby bazy danych MongoDB na nowe zasoby usługi Azure Cosmos DB
  3. Planowanie kompleksowej logistyki procesu migracji przed rozpoczęciem migracji danych na pełną skalę

Następnie wykonaj migrację zgodnie z planem przed migracją.

Na koniec wykonaj krytyczne kroki po migracji po migracji i optymalizacji.

Wszystkie powyższe kroki mają kluczowe znaczenie dla zapewnienia pomyślnej migracji.

Podczas planowania migracji zalecamy, aby zawsze, gdy jest to możliwe, planować na poziomie poszczególnych zasobów.

Ocena przed migracją

Pierwszym krokiem przed migracją jest odnalezienie istniejących zasobów bazy danych MongoDB i ocena gotowości zasobów do migracji.

Odnajdywanie obejmuje utworzenie kompleksowej listy istniejących zasobów (baz danych lub kolekcji) w zasobach danych bazy danych MongoDB.

Ocena obejmuje ustalenie, czy używasz obsługiwanych funkcji i składni. Obejmuje to również upewnienie się, że przestrzegasz limitów i limitów przydziału. Celem tego etapu jest utworzenie listy niezgodności i ostrzeżeń, jeśli istnieją. Po dokonaniu oceny możesz spróbować rozwiązać problem z wynikami podczas planowania migracji.

Istnieją 3 sposoby ukończenia oceny przed migracją. Zalecamy użycie rozszerzenia Migracja usługi Azure Cosmos DB dla bazy danych MongoDB.

Migracja usługi Azure Cosmos DB dla rozszerzenia bazy danych MongoDB

Rozszerzenie Migracja usługi Azure Cosmos DB dla bazy danych MongoDB w narzędziu Azure Data Studio pomaga ocenić obciążenie bazy danych MongoDB pod kątem migracji do usługi Azure Cosmos DB dla bazy danych MongoDB. Za pomocą tego rozszerzenia możesz uruchomić kompleksową ocenę obciążenia i dowiedzieć się, jakie działania mogą być konieczne, aby bezproblemowo migrować obciążenia w usłudze Azure Cosmos DB. Podczas oceny punktu końcowego bazy danych MongoDB rozszerzenie zgłasza wszystkie odnalezione zasoby.

Uwaga

Zalecamy szczegółowe zapoznanie się z obsługiwanymi funkcjami i składnią, limitami i limitami przydziału usługi Azure Cosmos DB, a także przeprowadzenie weryfikacji koncepcji przed rzeczywistą migracją.

Ręczne odnajdywanie (starsza wersja)

Alternatywnie możesz utworzyć arkusz kalkulacyjny migracji majątku danych. Celem tego arkusza kalkulacyjnego jest zwiększenie produktywności i ułatwienie planowania migracji od końca do końca i używania go jako dokumentu śledzenia w całym procesie migracji.

  • Ten arkusz zawiera kompleksową listę istniejących zasobów (baz danych lub kolekcji) w zasobach danych bazy danych MongoDB.
  • Arkusz kalkulacyjny powinien być ustrukturyzowany jako rekord zasobów majątku danych w postaci listy.
  • Każdy wiersz odpowiada zasobowi (bazie danych lub kolekcji).
  • Każda kolumna odpowiada właściwości zasobu; zacznij od co najmniej nazwy i rozmiaru danych (GB) jako kolumn.
  • W miarę postępów w tym przewodniku utworzysz ten arkusz kalkulacyjny w dokumencie śledzenia dla kompleksowego planowania migracji, dodając kolumny zgodnie z potrzebami.

Oto kilka narzędzi, których można użyć do odnajdywania zasobów:

Przejrzyj arkusz kalkulacyjny i zweryfikuj każdą kolekcję pod kątem obsługiwanych funkcji i składni oraz szczegółowo limity i limity przydziału usługi Azure Cosmos DB.

Narzędzie Asystent migracji bazy danych (starsza wersja)

Uwaga

Asystent migracji bazy danych to starsze narzędzie ułatwiające wykonanie kroków przed migracją. Zalecamy użycie rozszerzenia Migracja usługi Azure Cosmos DB dla bazy danych MongoDB dla wszystkich kroków przed migracją.

Możesz użyć narzędzia Database Asystent migracji (DMA), aby ułatwić wykonanie kroków przed migracją.

Mapowanie przed migracją

Po wykonaniu kroków odnajdywania i oceny wykonano czynności opisane w równaniu po stronie bazy danych MongoDB. Teraz nadszedł czas, aby zaplanować stronę równania w usłudze Azure Cosmos DB. Jak planujesz skonfigurować i skonfigurować produkcyjne zasoby usługi Azure Cosmos DB? Planowanie na poziomie poszczególnych zasobów oznacza to, że należy dodać następujące kolumny do arkusza kalkulacyjnego planowania:

  • Mapowanie usługi Azure Cosmos DB
  • Klucz fragmentu
  • Model danych
  • Dedykowana a współdzielona przepływność

Więcej szczegółów znajduje się w poniższych sekcjach.

Planowanie zdolności produkcyjnych

Próbujesz zaplanować pojemność migracji do usługi Azure Cosmos DB?

Zagadnienia dotyczące korzystania z interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB

Przed zaplanowaniem majątku danych usługi Azure Cosmos DB upewnij się, że rozumiesz następujące pojęcia dotyczące usługi Azure Cosmos DB:

  • Model pojemności: pojemność bazy danych w usłudze Azure Cosmos DB jest oparta na modelu opartym na przepływności. Ten model jest oparty na jednostkach żądań na sekundę, która jest jednostką reprezentującą liczbę operacji bazy danych, które można wykonać względem kolekcji na sekundę. Tę pojemność można przydzielić na poziomie bazy danych lub kolekcji i można ją aprowizować w modelu alokacji lub przy użyciu aprowizowanej przepływności autoskalowania.
  • Jednostki żądań: każda operacja bazy danych ma skojarzony koszt jednostek żądania (RU) w usłudze Azure Cosmos DB. Po wykonaniu jednostki żądania są odejmowane z dostępnego poziomu jednostek żądania na danej sekundzie. Jeśli żądanie wymaga więcej jednostek RU niż obecnie przydzielone jednostki RU/s, istnieją dwie opcje rozwiązania problemu — zwiększ liczbę jednostek RU lub zaczekaj do następnego uruchomienia sekundy, a następnie ponów próbę wykonania operacji.
  • Pojemność elastyczna: pojemność dla danej kolekcji lub bazy danych może ulec zmianie w dowolnym momencie. Ta elastyczność umożliwia elastyczne dostosowanie bazy danych do wymagań dotyczących przepływności obciążenia.
  • Automatyczne dzielenie na fragmenty: usługa Azure Cosmos DB udostępnia automatyczny system partycjonowania, który wymaga tylko fragmentu (lub klucza partycji). Mechanizm automatycznego partycjonowania jest współużytkowany we wszystkich interfejsach API usługi Azure Cosmos DB i umożliwia bezproblemowe przetwarzanie danych i skalowanie przez dystrybucję poziomą.

Planowanie majątku danych usługi Azure Cosmos DB

Dowiedz się, jakie zasoby usługi Azure Cosmos DB tworzysz. Ten proces wymaga przejścia przez arkusz kalkulacyjny migracji majątku danych i mapowania każdego istniejącego zasobu bazy danych MongoDB na nowy zasób usługi Azure Cosmos DB.

  • Przewidywanie, że każda baza danych MongoDB stanie się bazą danych usługi Azure Cosmos DB.
  • Przewidywanie, że każda kolekcja bazy danych MongoDB stanie się kolekcją usługi Azure Cosmos DB.
  • Wybierz konwencję nazewnictwa dla zasobów usługi Azure Cosmos DB. Utrzymywanie tych samych nazw zasobów jest zwykle dobrym wyborem, chyba że istnieją jakiekolwiek zmiany w strukturze baz danych i kolekcji.
  • Ustal, czy używasz kolekcji podzielonych na fragmenty, czy nieuhardowanych w usłudze Azure Cosmos DB. Limit kolekcji bez fragmentowania wynosi 20 GB. Z drugiej strony fragmentowanie pomaga osiągnąć skalę w poziomie, która ma kluczowe znaczenie dla wydajności wielu obciążeń.
  • Jeśli używasz kolekcji podzielonych na fragmenty, nie zakładaj, że klucz fragmentu kolekcji MongoDB staje się kluczem partycji kontenera usługi Azure Cosmos DB. Nie zakładaj, że istniejąca struktura dokumentu modelu danych Bazy danych MongoDB powinna być tym samym modelem, którego używasz w usłudze Azure Cosmos DB.
    • Klucz fragmentu to jedno najważniejsze ustawienie optymalizacji skalowalności i wydajności usługi Azure Cosmos DB, a modelowanie danych jest drugim najważniejszym ustawieniem. Oba te ustawienia są niezmienne i nie można ich zmienić po ich ustawieniu; dlatego bardzo ważne jest, aby zoptymalizować je w fazie planowania. Aby uzyskać więcej informacji, postępuj zgodnie ze wskazówkami w sekcji Niezmienialne decyzje .
  • Usługa Azure Cosmos DB nie rozpoznaje niektórych typów kolekcji MongoDB, takich jak kolekcje ograniczone. W przypadku tych zasobów wystarczy utworzyć normalne kolekcje usługi Azure Cosmos DB.
  • Usługa Azure Cosmos DB ma dwa własne typy kolekcji — udostępnioną i dedykowaną przepływność. Współdzielona a dedykowana przepływność to kolejna krytyczna, niezmienna decyzja, którą należy podjąć w fazie planowania. Aby uzyskać więcej informacji, postępuj zgodnie ze wskazówkami w sekcji Niezmienialne decyzje .

Niezmienne decyzje

Następujące opcje konfiguracji usługi Azure Cosmos DB nie mogą być modyfikowane ani cofane po utworzeniu zasobu usługi Azure Cosmos DB; dlatego ważne jest, aby te opcje konfiguracji były odpowiednie podczas planowania przed migracją przed rozpoczęciem migracji:

Koszt posiadania

  • Szacowanie kosztów posiadania nowych zasobów usługi Azure Cosmos DB przy użyciu kalkulatora pojemności usługi Azure Cosmos DB.

Szacowanie przepływności

  • W usłudze Azure Cosmos DB przepływność jest aprowizowana z wyprzedzeniem i mierzona w jednostkach żądań (RU) na sekundę. W przeciwieństwie do maszyn wirtualnych lub serwerów lokalnych, jednostki RU są łatwe do skalowania w górę i w dół w dowolnym momencie. Liczbę aprowizowanych jednostek RU można zmienić natychmiast. Aby uzyskać więcej informacji, zobacz Request units in Azure Cosmos DB (Jednostki żądań w usłudze Azure Cosmos DB).

  • Aby określić liczbę jednostek żądań, których należy użyć, możesz użyć kalkulatora pojemności usługi Azure Cosmos DB. Ta liczba jest oparta na konfiguracji konta bazy danych, ilości danych, rozmiarze dokumentu i wymaganych odczytach i zapisach na sekundę.

  • Poniżej przedstawiono kluczowe czynniki wpływające na liczbę wymaganych jednostek RU:

    • Rozmiar dokumentu: wraz ze wzrostem rozmiaru elementu/dokumentu liczba jednostek RU użytych do odczytu lub zapisu elementu/dokumentu również wzrasta.

    • Liczba właściwości dokumentu: liczba jednostek RU użytych do utworzenia lub zaktualizowania dokumentu jest powiązana z liczbą, złożonością i długością jego właściwości. Użycie jednostek żądania dla operacji zapisu można zmniejszyć, ograniczając liczbę indeksowanych właściwości.

    • Wzorce zapytań: złożoność zapytania ma wpływ na liczbę jednostek żądań używanych przez zapytanie.

  • Najlepszym sposobem zrozumienia kosztów zapytań jest użycie przykładowych danych w usłudze Azure Cosmos DB i uruchomienie przykładowych zapytań z poziomu powłoki Bazy danych MongoDB przy użyciu getLastRequestStastistics polecenia w celu pobrania opłaty za żądanie, która zwraca liczbę użytych jednostek RU:

    db.runCommand({getLastRequestStatistics: 1})

    *To polecenie zwraca dokument JSON podobny do następującego przykładu:

    {
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}

  • Możesz również użyć ustawień diagnostycznych, aby zrozumieć częstotliwość i wzorce zapytań wykonywanych w usłudze Azure Cosmos DB. Wyniki z dzienników diagnostycznych można wysyłać do konta magazynu, wystąpienia usługi Event Hubs lub usługi Azure Log Analytics.

Planowanie logistyki przed migracją

Teraz, gdy masz już wgląd w istniejący majątek danych i projekt nowego majątku danych usługi Azure Cosmos DB, możesz zaplanować sposób kompleksowego wykonywania procesu migracji. Po raz kolejny wykonaj planowanie na poziomie poszczególnych zasobów , dodając kolumny do arkusza kalkulacyjnego w celu przechwycenia wymiarów logistycznych zawartych w tej sekcji.

Logistyka wykonywania

  • Przypisz odpowiedzialność za migrację każdego istniejącego zasobu z bazy danych MongoDB do usługi Azure Cosmos DB. Sposób stosowania zasobów zespołu w celu stosowania migracji do ukończenia jest do Ciebie. W przypadku małych migracji możesz mieć jeden zespół uruchamia cały proces migracji i monitoruje jego postęp. W przypadku większych migracji można przypisać odpowiedzialność członkom zespołu na podstawie zasobów na potrzeby migracji i monitorowania tego zasobu.

  • Po przypisaniu odpowiedzialności za migrację zasobów należy wybrać odpowiednie narzędzia migracji do migracji. W przypadku małych migracji możesz użyć jednego narzędzia do migracji, takiego jak narzędzie natywne bazy danych MongoDB lub usługa Azure DMS, aby przeprowadzić migrację wszystkich zasobów w jednym zastrzeleniu. W przypadku większych migracji lub migracji ze specjalnymi wymaganiami możesz wybrać narzędzia migracji na poziomie szczegółowości dla poszczególnych zasobów.

    • Przed zaplanowaniem narzędzi migracji do użycia zalecamy zapoznanie się z dostępnymi opcjami. Usługa Azure Database Migration Service dla interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB udostępnia mechanizm, który upraszcza migrację danych, zapewniając w pełni zarządzaną platformę hostingu, opcje monitorowania migracji i automatyczną obsługę ograniczania przepustowości. Oto pełna lista opcji:

      Typ migracji Rozwiązanie Zagadnienia do rozważenia
      Tryb online Azure Database Migration Service • Używa biblioteki funkcji wykonawczej operacji zbiorczych dla usługi Azure Cosmos DB
      • Nadaje się do dużych zestawów danych i dba o replikowanie zmian na żywo
      • Działa tylko z innymi źródłami bazy danych MongoDB
      W trybie offline Azure Database Migration Service • Używa biblioteki funkcji wykonawczej operacji zbiorczych dla usługi Azure Cosmos DB
      • Nadaje się do dużych zestawów danych i dba o replikowanie zmian na żywo
      • Działa tylko z innymi źródłami bazy danych MongoDB
      W trybie offline Azure Data Factory • Używa biblioteki funkcji wykonawczej operacji zbiorczych dla usługi Azure Cosmos DB
      • Odpowiednie dla dużych zestawów danych
      • Łatwe konfigurowanie i obsługa wielu źródeł
      • Brak punktów kontrolnych oznacza, że każdy problem podczas migracji wymaga ponownego uruchomienia całego procesu migracji
      • Brak kolejki utraconych komunikatów oznacza, że kilka błędnych plików może zatrzymać cały proces migracji
      • Wymaga niestandardowego kodu w celu zwiększenia przepływności odczytu dla niektórych źródeł danych
      W trybie offline Istniejące narzędzia Mongo (mongodump, mongorestore, Studio3T) • Łatwa konfiguracja i integracja
      • Wymaga niestandardowej obsługi ograniczania przepustowości
      Offline/online Azure Databricks i Spark • Pełna kontrola szybkości migracji i przekształcania danych
      • Wymaga kodowania niestandardowego

    • Jeśli zasób może tolerować migrację w trybie offline, użyj tego diagramu, aby wybrać odpowiednie narzędzie do migracji:

      Diagram przedstawiający używanie narzędzi do migracji offline na podstawie rozmiaru narzędzia.

    • Jeśli zasób wymaga migracji online, użyj tego diagramu, aby wybrać odpowiednie narzędzie do migracji:

      Diagram przedstawiający korzystanie z narzędzi migracji online na podstawie preferencji dla rozwiązań niestandardowych lub pod kluczem.

    • Obejrzyj wideo z omówieniem i pokazem rozwiązań migracji.

  • Po wybraniu narzędzi migracji dla każdego zasobu następnym krokiem jest ustalanie priorytetów zasobów, które zostaną zmigrowane. Dobra priorytetyzacja może pomóc w utrzymaniu migracji zgodnie z harmonogramem. Dobrą praktyką jest ustalanie priorytetów migracji tych zasobów, które wymagają jak największego czasu do przeniesienia; migracja tych zasobów po raz pierwszy przyniesie największy postęp w kierunku ukończenia. Ponadto ze względu na to, że te czasochłonne migracje zwykle obejmują więcej danych, są one intensywniejsze dla narzędzia migracji i dlatego są bardziej narażone na problemy z potokiem migracji na wczesnym etapie. Ta praktyka minimalizuje prawdopodobieństwo poślizgu harmonogramu z powodu problemów z potokiem migracji.

  • Zaplanuj sposób monitorowania postępu migracji po rozpoczęciu migracji. Jeśli koordynujesz nakład pracy nad migracją danych między zespołem, zaplanuj również regularne cykle synchronizacji zespołu, aby mieć kompleksowy wgląd w sposób, w jaki przebiegają migracje o wysokim priorytcie.

Obsługiwane scenariusze migracji

Najlepszy wybór narzędzia migracji bazy danych MongoDB zależy od scenariusza migracji.

Typy migracji

Oto lista zgodnych narzędzi dla każdego scenariusza migracji:

Element źródłowy Element docelowy Zalecenie dotyczące procesu
• Klaster lokalny bazy danych MongoDB
• Baza danych MongoDB w klastrze maszyn wirtualnych IaaS
• Klaster Usługi Atlas bazy danych MongoDB — offline		 Azure Cosmos DB Mongo API • <Dane 10 GB: narzędzia natywne bazy danych MongoDB
• <1 TB danych: Azure DMS
• >Dane 1 TB: Spark
• Klaster lokalny bazy danych MongoDB
• Baza danych MongoDB w klastrze maszyn wirtualnych IaaS
• Klaster Usługi Atlas bazy danych MongoDB — Online		 Azure Cosmos DB Mongo API • <1 TB danych: Azure DMS
• >Dane 1 TB: Spark + Mongo Changestream
• Konieczność zmiany schematu podczas migracji
Potrzebna jest większa elastyczność niż wyżej wymienione narzędzia		 Azure Cosmos DB Mongo API • Usługa ADF jest bardziej elastyczna niż usługa DMS, obsługuje modyfikacje schematu podczas migracji i obsługuje najbardziej kombinacje źródła/miejsca docelowego
• Usługa DMS jest lepsza pod względem skali (np. szybszej migracji)
• Plik JSON Azure Cosmos DB Mongo API • Narzędzia natywne bazy danych MongoDB specjalnie mongoimport
• Plik CSV Azure Cosmos DB Mongo API • Narzędzia natywne bazy danych MongoDB specjalnie mongoimport
• Plik BSON Azure Cosmos DB Mongo API • Narzędzia natywne bazy danych MongoDB w szczególności mongorestore

Obsługa narzędzi dla wersji bazy danych MongoDB

Biorąc pod uwagę, że migrujesz z określonej wersji bazy danych MongoDB, obsługiwane narzędzia dla każdej wersji są dostępne tutaj:

Wersja źródłowa bazy danych MongoDB Wersja docelowa usługi Azure Cosmos DB dla bazy danych MongoDB (RU) Obsługiwane narzędzia Nieobsługiwane narzędzia
<3.2 3.2, 3.6, <8.0 Narzędzia natywne bazy danych MongoDB, Spark DMS, ADF
3.2, 3.6, <8.0 3.2, 3.6, <8.0 Narzędzia natywne bazy danych MongoDB, DMS, ADF, Spark Brak

Po migracji

W fazie przed migracją należy poświęcić trochę czasu na zaplanowanie kroków związanych z migracją aplikacji i optymalizacją po migracji.

  • W fazie po migracji wykonasz migrację jednorazową aplikacji, aby używać usługi Azure Cosmos DB zamiast istniejącej jednostki danych MongoDB.
  • Staraj się zaplanować indeksowanie, dystrybucję globalną, spójność i inne modyfikowalne właściwości usługi Azure Cosmos DB na poziomie zasobu. Jednak te ustawienia konfiguracji usługi Azure Cosmos DB można zmodyfikować później, więc później należy spodziewać się wprowadzenia zmian w tych ustawieniach. Te konfiguracje modyfikowalne są stosowane po migracji.
  • Aby zapoznać się z przewodnikiem po migracji, zobacz Kroki optymalizacji po migracji podczas korzystania z interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB.

Następne kroki