Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Zasoby obliczeniowe usługi Azure DocumentDB 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.
Pamięć jest używana do plików bazodanowych, plików tymczasowych, logów transakcji i logów serwera baz 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 DocumentDB
Łączna ilość pamięci RAM w jednym fragmencie zależy od wybranej liczby rdzeni wirtualnych (vCores).
| Warstwa klastra | vCores | Jeden fragment, pamięć RAM w GiB |
|---|---|---|
| M10 | 1 (z możliwością serii) | 2 |
| M20 | 2 (z możliwością zwiększenia wydajności) | 4 |
| M25 | 2 (z możliwością serii) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Magazyn w usłudze Azure DocumentDB
Łączna ilość przypisanej pamięci masowej określa również pojemność I/O dostępną dla każdego fragmentu w klastrze.
| Rozmiar pamięci, GiB | Maksymalna liczba IOPS |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5,000 |
| 2,048 | 7,500 |
| 4,095 | 7,500 |
| 8,192 | 16,000 |
| 16,384 | 18,000 |
| 32,767 | 20,000 |
† maksymalna liczba operacji we/wy na sekundę przy użyciu technologii "disk bursting". Pamięć masowa do 512 GiB włącznie ma dostępną bezpłatną funkcję zwiększania wydajności dysku.
Maksymalizuj liczbę operacji we/wy na sekundę dla konfiguracji obliczeniowej i pamięci masowej
Każda konfiguracja obliczeniowa ma limit IOPS, który zależy od liczby vCores. Upewnij się, że wybrano konfigurację obliczeniową klastra, aby w pełni wykorzystać operacje we/wy na sekundę (IOPS) w wybranej pamięci masowej.
| Rozmiar magazynu | Maksymalna liczba operacji we/wy na sekundę dla magazynu | Minimalna warstwa obliczeniowa | Minimalna liczba vCores |
|---|---|---|---|
| Do 0,5 TiB | 3,500† | M30 | 2 rdzenie wirtualne |
| 1 TiB | 5,000 | M40 | 4 vCore |
| 2 TiB | 7,500 | M50 | 8 rdzeni wirtualnych |
| 4 TiB | 7,500 | 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 |
† Maksymalne IOPS z bezpłatnym tymczasowym przyspieszeniem dysku. Pamięć masowa do 512 GiB włącznie ma dostępną bezpłatną funkcję zwiększania wydajności dysku.
Jeśli na przykład potrzebujesz 8 TiB przestrzeni dyskowej na shard lub więcej, wybierz 16 lub więcej rdzeni wirtualnych do konfiguracji obliczeniowej węzła. Wybór ten umożliwia zmaksymalizowanie użycia operacji wejścia/wyjścia na sekundę (IOPS) udostępnianych przez wybraną pamięć masową.
Zagadnienia dotyczące obliczeń i magazynu
Podczas konfigurowania klastra usługi Azure DocumentDB ważne jest, aby zrozumieć, w jaki sposób opcje obliczeniowe i magazynowe wpływają na wydajność, koszt i skalowalność określonego obciążenia.
Zagadnienia dotyczące zestawu roboczego i pamięci
W usłudze Azure DocumentDB zestaw roboczy odwołuje 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 w określeniu, które części danych są najczęściej uzyskiwane.
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 zestaw roboczy przekracza dostępną pamięć RAM, rozważ optymalizację modelu danych, dodanie większej ilości pamięci RAM do klastra lub użycie fragmentowania w celu dystrybucji danych między wieloma węzłami.
Wybieranie optymalnej konfiguracji dla obciążenia
Określenie odpowiedniej konfiguracji zasobów obliczeniowych i magazynu dla obciążenia usługi Azure DocumentDB 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 migracją obciążenia na platformę Azure. Po wdrożeniu obciążenia bazy danych MongoDB w klastrze usługi Azure DocumentDB kontynuuj monitorowanie przy użyciu metryk monitorowania platformy Azure.
- 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, obciążenie pamięci lub wolne operacje wejścia/wyjścia 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 usługi Azure DocumentDB, aby wyświetlić historyczne wzorce użycia zasobów obliczeniowych.
- Liczba operacji IOPS magazynu: wybierz magazyn ze wystarczającą liczbą IOPS, aby obsługiwać operacje odczytu i zapisu. Użyj metryki „IOPS” z agregacją „Max” w swoim klastrze, aby zobaczyć historyczne użycie metryki IOPS w magazynie.
- 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: skalujemy zasoby obliczeniowe/pamięć RAM w górę i w dół oraz zasoby pamięci masowej 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 DocumentDB. Przechowywanie umożliwia uniknięcie niepotrzebnego użycia zasobów pamięci. Monitoruj użycie magazynu, ustawiając alerty dotyczące metryk "Procent magazynu" i/lub "Użyty magazyn" z agregacją "Max". Rozważ zwiększenie przestrzeni, gdy wykorzystanie obciążenia przekracza 70%.
- Skalowanie w poziomie: rozważ użycie wielu fragmentów dla klastra w celu dystrybucji danych między wieloma węzłami usługi Azure DocumentDB w celu zwiększenia wydajności i lepszego zarządzania pojemnością w miarę wzrostu obciążenia. Takie skalowanie jest szczególnie przydatne w przypadku dużych zestawów danych (ponad 2–4 TiB) i aplikacji o wysokiej przepływności.
-
Skalowanie w pionie: skalujemy zasoby obliczeniowe/pamięć RAM w górę i w dół oraz zasoby pamięci masowej 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 CPU/RAM, IOPS 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 usługi Azure DocumentDB 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 odpowiedniej pojemności pamięci masowej dla obciążenia wymaga wzięcia pod uwagę kilku czynników, aby zapewnić optymalną wydajność i skalowalność. Poniżej przedstawiono zagadnienia dotyczące rozmiaru magazynu w usłudze Azure DocumentDB:
Szacowanie rozmiaru danych:
- Oblicz oczekiwany rozmiar danych usługi Azure DocumentDB. Rozważ:
- Bieżący rozmiar danych: W przypadku migracji z istniejącej bazy danych.
- Wskaźnik wzrostu: Szacowanie ilości danych, które zostaną dodane w miarę upływu czasu.
- Rozmiar i struktura dokumentu: Zapoznaj się ze schematem danych i rozmiarami dokumentów, ponieważ wpływają one na wydajność magazynowania.
- Oblicz oczekiwany rozmiar danych usługi Azure DocumentDB. Rozważ:
Współczynnik w indeksach:
- Usługa Azure DocumentDB używa 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.
Uwagi 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ż:
- Przepustowość I/O: IOPS, czyli operacje wejścia/wyjścia na sekundę, to liczba żądań wysyłanych do dysków magazynujących w ciągu jednej sekundy. Większa pojemność magazynu wiąże się z większą liczbą operacji we/wy na sekundę (IOPS). Zapewnij odpowiednią przepływność dla operacji odczytu/zapisu. Użyj metryki "IOPS" z agregacją "Max", aby monitorować używane IOPS w klastrze.
- Opóźnienie: Opóźnienie to czas potrzebny aplikacji na odebranie pojedynczego żądania, wysłanie go na dyski magazynu i wysłanie odpowiedzi do klienta. Opóźnienie to kluczowa miara wydajności aplikacji, obok IOPS i throughput. Typ używanego magazynu i konfiguracja magazynu w dużej mierze definiuje opóźnienie. W usłudze zarządzanej, takiej jak Azure DocumentDB, 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ż:
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 umożliwić wzrost bez częstych rozbudowy pamięci masowej.
Przykładowe obliczenie:
- Załóżmy, że początkowy rozmiar danych to 500 GiB.
- Rozmiar razem z indeksami może 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 przestrzeni dyskowej 1 TiB dzisiaj i zwiększyć ją do 2 TiB, gdy jej 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.
Czym są obliczenia elastyczne?
Warstwa z możliwością rozszerzenia oferuje inteligentne rozwiązanie dostosowane do małych obciążeń baz danych. Zapewniając minimalną wydajność procesora CPU w okresach bezczynności, te klastry optymalizują wykorzystanie zasobów. Jednak prawdziwy blask polega na możliwości bezproblemowego skalowania do pełnej mocy CPU w odpowiedzi na zwiększone obciążenie ruchem lub zapotrzebowaniem na zasoby. Ta adaptacja zapewnia maksymalną wydajność w razie potrzeby, zapewniając jednocześnie znaczne oszczędności kosztów.
Obniżając początkową cenę usługi, rozszerzalna warstwa klastra Azure DocumentDB ma na celu ułatwienie onboarding i eksploracji usługi Azure DocumentDB przy obniżonych cenach. Ta demokratyzacja dostępu umożliwia firmom o wszystkich rozmiarach wykorzystanie możliwości usługi Azure DocumentDB bez nadwerężenia budżetu. Niezależnie od tego, czy jesteś startupem, małą firmą, czy przedsiębiorstwem, ta warstwa otwiera nowe możliwości ekonomicznej skalowalności.
Aprowizowanie warstwy z możliwością skalowania jest tak proste, jak aprowizowanie warstw regularnych; W opcji warstwy klastra wystarczy wybrać opcję "M10", "M20" lub "M25". Oto przewodnik szybkiego startu, który zawiera instrukcje krok po kroku dotyczące konfigurowania klastra Azure DocumentDB.