Konfiguracje obliczeń i magazynu dla klastrów z rdzeniami wirtualnymi usługi Azure Cosmos DB dla bazy danych MongoDB
DOTYCZY: 
Rdzenie wirtualne bazy danych MongoDB
Zasoby obliczeniowe są udostępniane jako rdzenie wirtualne, które reprezentują logiczny procesor podstawowego sprzętu. Rozmiar magazynu do aprowizacji odnosi się do pojemności dostępnej dla fragmentów w klastrze. Magazyn jest używany dla plików bazy danych, plików tymczasowych, dzienników transakcji i dzienników serwera bazy danych. Ustawienia zasobów obliczeniowych i magazynu można wybrać niezależnie. Wybrane wartości zasobów obliczeniowych i magazynu mają zastosowanie do każdego fragmentu w klastrze.
Obliczenia w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB
Łączna ilość pamięci RAM w jednym fragmentze jest oparta na wybranej liczbie rdzeni wirtualnych.
| Warstwa klastra | Rdzenie wirtualne | Jeden fragment, pamięć RAM GiB |
|---|---|---|
| M25 | 2 (z możliwością serii) | 8 |
| M30 | 2 | 8 |
| M40 | 100 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Magazyn w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB
Łączna ilość aprowizowania magazynu definiuje również pojemność we/wy dostępną dla każdego fragmentu w klastrze.
| Rozmiar magazynu, GiB | Maksymalna liczba operacji we/wy na sekundę |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5,000 |
| 2048 | 7500 |
| 4,095 | 7500 |
| 8,192 | 16 000 |
| 16,384 | 18 000 |
| 32 767 | 20,000 |
† maksymalna liczba operacji we/wy na sekundę z bezpłatnymi wzrostami wydajności dysku. Magazyn do 512 GiB włącznie jest wyposażony w bezpłatny wzrost wydajności dysku.
Maksymalizowanie liczby operacji we/wy na sekundę dla konfiguracji obliczeń/magazynu
Każda konfiguracja obliczeniowa ma limit liczby operacji we/wy na sekundę, który zależy od liczby rdzeni wirtualnych. Upewnij się, że wybrano konfigurację obliczeniową klastra, aby w pełni wykorzystać operacje we/wy na sekundę w wybranym magazynie.
| Rozmiar magazynu | Operacje we/wy na sekundę magazynu do | Minimalna warstwa obliczeniowa | Minimalna liczba rdzeni wirtualnych |
|---|---|---|---|
| Do 0,5 TiB | 3,500† | M30 | 2 rdzenie wirtualne |
| 1 TiB | 5,000 | M40 | 4 rdzenie wirtualne |
| 2 TiB | 7500 | M50 | 8 rdzeni wirtualnych |
| 4 TiB | 7500 | M50 | 8 rdzeni wirtualnych |
| 8 TiB | 16 000 | M60 | 16 rdzeni wirtualnych |
| 16 TiB | 18 000 | M60 | 16 rdzeni wirtualnych |
| 32 TiB | 20,000 | M60 | 16 rdzeni wirtualnych |
† maksymalna liczba operacji we/wy na sekundę z bezpłatnymi wzrostami wydajności dysku. Magazyn do 512 GiB włącznie jest wyposażony w bezpłatny wzrost wydajności dysku.
Jeśli na przykład potrzebujesz 8 TiB magazynu na fragment lub więcej, upewnij się, że wybrano 16 rdzeni wirtualnych lub więcej dla konfiguracji obliczeniowej węzła. Wybór ten umożliwia zmaksymalizowanie użycia operacji we/wy na sekundę udostępnianych przez wybrany magazyn.
Zagadnienia dotyczące obliczeń i magazynu
Zagadnienia dotyczące zestawu roboczego i pamięci
W przypadku rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB zestaw roboczy odnosi się do części danych, do których często uzyskuje się dostęp i jest używany przez aplikacje. Obejmuje ona zarówno dane, jak i indeksy, które są regularnie odczytywane lub zapisywane podczas typowych operacji aplikacji. Koncepcja zestawu roboczego jest ważna w przypadku optymalizacji wydajności, ponieważ baza danych MongoDB, podobnie jak wiele baz danych, działa najlepiej, gdy zestaw roboczy pasuje do pamięci RAM.
Aby zdefiniować i zrozumieć zestaw roboczy bazy danych MongoDB, rozważ następujące składniki:
- Często używane dane: te dane obejmują dokumenty, które aplikacja odczytuje lub aktualizuje regularnie.
- Indeksy: indeksy używane w operacjach zapytań stanowią również część zestawu roboczego, ponieważ muszą zostać załadowane do pamięci, aby zapewnić szybki dostęp.
- Wzorce użycia aplikacji: analizowanie wzorców użycia aplikacji może pomóc określić, do których części danych są najczęściej używane.
Zachowując zestaw roboczy w pamięci RAM, można zminimalizować wolniejsze operacje we/wy dysku, co zwiększa wydajność bazy danych MongoDB. Jeśli okaże się, że zestaw roboczy przekracza dostępną pamięć RAM, możesz rozważyć optymalizację modelu danych, dodanie większej ilości pamięci RAM lub użycie fragmentowania w celu dystrybucji danych między wieloma węzłami.
Wybieranie optymalnej konfiguracji dla obciążenia
Określenie odpowiedniej konfiguracji obliczeniowej i magazynu dla obciążenia rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB obejmuje ocenę kilku czynników związanych z wymaganiami i wzorcami użycia aplikacji. Kluczowe kroki i zagadnienia dotyczące określania optymalnej konfiguracji obejmują:
Informacje o obciążeniu
- Ilość danych: szacowanie całkowitego rozmiaru danych, w tym indeksów.
- Współczynnik odczytu/zapisu: określ stosunek operacji odczytu do operacji zapisu.
- Wzorce zapytań: analizowanie typów zapytań, które wykonuje aplikacja. Na przykład proste operacje odczytu, złożone agregacje.
- Współbieżność: oceń liczbę współbieżnych operacji, które musi obsłużyć baza danych.
Monitorowanie bieżącej wydajności
- Wykorzystanie zasobów: użyj narzędzi do monitorowania, aby śledzić użycie procesora CPU, pamięci, operacji we/wy dysku i sieci przed przeniesieniem obciążenia na platformę Azure i monitorowanie metryk po rozpoczęciu uruchamiania obciążenia bazy danych MongoDB w klastrze rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB.
- Metryki wydajności: Monitoruj kluczowe metryki wydajności, takie jak opóźnienia, przepływność i współczynniki trafień pamięci podręcznej.
- Wąskie gardła: zidentyfikuj wszelkie istniejące wąskie gardła wydajności, takie jak wysokie użycie procesora CPU, wykorzystanie pamięci lub wolne we/wy dysku.
Szacowanie wymagań dotyczących zasobów
- Pamięć: Upewnij się, że zestaw roboczy (często używane dane i indeksy) mieści się w pamięci RAM. Jeśli rozmiar zestawu roboczego przekracza dostępną pamięć, rozważ dodanie większej ilości pamięci RAM lub optymalizację modelu danych.
- Procesor CPU: wybierz konfigurację procesora CPU, która może obsługiwać obciążenie zapytań i wymagania współbieżności. Obciążenia intensywnie korzystające z procesora CPU mogą wymagać większej liczby rdzeni. Użyj metryki "Procent procesora CPU" z agregacją "Max" w klastrze rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB, aby wyświetlić historyczne wzorce użycia zasobów obliczeniowych.
- Liczba operacji we/wy na sekundę magazynu: wybierz magazyn z wystarczającą ilością operacji we/wy na sekundę, aby obsługiwać operacje odczytu i zapisu. Użyj metryki "IOPS" z agregacją "Max" w klastrze, aby zobaczyć historyczne użycie operacji we/wy na sekundę magazynu.
- Sieć: zapewnij odpowiednią przepustowość sieci do obsługi transferu danych między aplikacją a bazą danych, szczególnie w przypadku konfiguracji rozproszonych. Upewnij się, że skonfigurowano hosta dla aplikacji MongoDB pod kątem obsługi przyspieszonych technologii sieciowych , takich jak SR-IOV.
Odpowiednio skaluj
- Skalowanie w pionie: skalowanie zasobów obliczeniowych/pamięci RAM w górę i w dół oraz skalowanie magazynu w górę.
- Obliczenia: Zwiększ liczbę rdzeni wirtualnych/pamięć RAM w klastrze, jeśli obciążenie wymaga tymczasowego zwiększenia lub często przekracza 70% wykorzystania procesora CPU przez dłuższy czas.
- Upewnij się, że masz odpowiednie przechowywanie danych w bazie danych usługi Azure Cosmos DB dla bazy danych mongoDB z rdzeniami wirtualnymi. Przechowywanie pozwala uniknąć niepotrzebnego użycia magazynu. Monitoruj użycie magazynu, ustawiając alerty dotyczące metryk "Procent magazynu" i/lub "Użyty magazyn" z agregacją "Max". Rozważ zwiększenie magazynu, ponieważ rozmiar obciążenia przekracza 70% użycia.
- Skalowanie w poziomie: rozważ użycie wielu fragmentów dla klastra w celu dystrybucji danych między wieloma węzłami rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB w celu zwiększenia wydajności i lepszego zarządzania pojemnością w miarę wzrostu obciążenia. Jest to szczególnie przydatne w przypadku dużych zestawów danych (ponad 2–4 TiB) i aplikacji o wysokiej przepływności.
- Skalowanie w pionie: skalowanie zasobów obliczeniowych/pamięci RAM w górę i w dół oraz skalowanie magazynu w górę.
Testowanie i iterowanie
- Testowanie porównawcze: wykonaj pomiar dla najczęściej używanych zapytań z różnymi konfiguracjami, aby określić wpływ na wydajność. Użyj metryk procesora CPU/pamięci RAM i liczby operacji we/wy na sekundę oraz testów porównawczych na poziomie aplikacji.
- Testowanie obciążenia: przeprowadź testowanie obciążenia, aby symulować obciążenia produkcyjne i zweryfikować wydajność wybranej konfiguracji.
- Ciągłe monitorowanie: ciągłe monitorowanie wdrożenia rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB i dostosowywanie zasobów zgodnie z potrzebami na podstawie zmieniających się obciążeń i wzorców użycia.
Systematycznie oceniając te czynniki i stale monitorując i dostosowując konfigurację, możesz upewnić się, że wdrożenie bazy danych MongoDB jest dobrze zoptymalizowane pod kątem konkretnego obciążenia.
Zagadnienia dotyczące magazynu
Podjęcie decyzji o odpowiednim rozmiarze magazynu dla obciążenia wymaga kilku zagadnień, aby zapewnić optymalną wydajność i skalowalność. Poniżej przedstawiono zagadnienia dotyczące rozmiaru magazynu w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB:
Szacowanie rozmiaru danych:
- Oblicz oczekiwany rozmiar danych rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB. Rozważać:
- Bieżący rozmiar danych: w przypadku migracji z istniejącej bazy danych.
- Wskaźnik wzrostu: Szacowanie ilości danych, które zostaną dodane w czasie.
- Rozmiar i struktura dokumentu: zapoznaj się ze schematem danych i rozmiarami dokumentów, ponieważ wpływają one na wydajność magazynowania.
- Oblicz oczekiwany rozmiar danych rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB. Rozważać:
Współczynnik w indeksach:
- Rdzenie wirtualne usługi Azure Cosmos DB dla bazy danych MongoDB używają indeksów do wydajnego wykonywania zapytań. Indeksy zużywają dodatkowe miejsce na dysku.
- Szacowanie rozmiaru indeksów na podstawie:
- Liczba indeksów.
- Rozmiar indeksowanych pól.
Zagadnienia dotyczące wydajności:
- Wydajność dysku ma wpływ na operacje bazy danych, szczególnie w przypadku obciążeń, które nie mogą zmieścić zestawu roboczego w pamięci RAM. Rozważać:
- Przepływność we/wy: liczba operacji we/wy na sekundę lub operacje wejścia/wyjścia na sekundę to liczba żądań wysyłanych do dysków magazynu w ciągu jednej sekundy. Większy rozmiar magazynu ma więcej operacji we/wy na sekundę. Zapewnij odpowiednią przepływność dla operacji odczytu/zapisu. Użyj metryki "IOPS" z agregacją "Max", aby monitorować używane operacje we/wy na sekundę w klastrze.
- Opóźnienie: opóźnienie to czas potrzebny aplikacji na odbieranie pojedynczego żądania, wysyłanie go na dyski magazynu i wysyłanie odpowiedzi do klienta. Opóźnienie to kluczowa miara wydajności aplikacji oprócz liczby operacji we/wy na sekundę i przepływności. Opóźnienie jest w dużej mierze definiowane przez typ używanego magazynu i konfigurację magazynu. W usłudze zarządzanej, takiej jak Azure Cosmos DB dla bazy danych MongoDB, szybka pamięć masowa, taka jak dyski SSD w warstwie Premium, jest używana z ustawieniami zoptymalizowanymi pod kątem zmniejszenia opóźnień.
- Wydajność dysku ma wpływ na operacje bazy danych, szczególnie w przypadku obciążeń, które nie mogą zmieścić zestawu roboczego w pamięci RAM. Rozważać:
Przyszły wzrost i skalowalność:
- Planowanie przyszłych potrzeb dotyczących wzrostu i skalowalności danych.
- Przydziel więcej miejsca na dysku poza bieżącymi potrzebami, aby obsłużyć wzrost bez częstych rozszerzeń magazynu.
Przykładowe obliczenia:
- Załóżmy, że początkowy rozmiar danych to 500 GiB.
- Indeksy mogą wzrosnąć do 700 GiB.
- Jeśli przewidujesz podwojenie danych w ciągu dwóch lat, zaplanuj 1,4 TiB (700 GiB * 2).
- Dodaj bufor na potrzeby związane z obciążeniem, wzrostem i potrzebami operacyjnymi.
- Możesz zacząć od 1 TiB magazynu dzisiaj i przeskalować go do 2 TiB, gdy jego rozmiar wzrośnie ponad 800 GiB.
Podjęcie decyzji o rozmiarze magazynu obejmuje połączenie szacowania bieżących i przyszłych potrzeb dotyczących danych, biorąc pod uwagę indeksowanie i kompresję oraz zapewnienie odpowiedniej wydajności i skalowalności. Regularne monitorowanie i korekta na podstawie rzeczywistych trendów użycia i wzrostu mają również kluczowe znaczenie dla utrzymania optymalnej wydajności bazy danych MongoDB.