MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

Zrozumienie i zarządzanie miejscem na dysku na serwerze MongoDB

Pamięć dyskowa jest krytycznym zasobem dla każdego skalowalnego systemu baz danych. Wydajność baz danych na dyskach będzie zależeć od sposobu zarządzania danymi na dysku. Serwer MongoDB obsługuje różne podłączane silniki pamięci masowej, które obsługują zarządzanie pamięcią i początkowo przechowują wszystkie dokumenty sekwencyjnie. W miarę rozrastania się bazy danych i uruchamiania wielu operacji zapisu ta ciągła przestrzeń zostaje podzielona na mniejsze bloki z fragmentami wolnego miejsca pomiędzy nimi. Typowym rozwiązaniem jest zwiększenie rozmiaru dysku, jednak istnieją alternatywy, które mogą pomóc odzyskać wolne miejsce bez konieczności skalowania rozmiaru dysku. Jedną z ważnych rzeczy, o których należy pamiętać, są statystyki przechowywania MongoDB i sposób kompaktowania lub naprawy bazy danych w celu obsługi fragmentacji.

Jak duża jest Twoja baza danych, naprawdę?

Zawsze powinieneś mieć oko na ilość wolnego miejsca na dysku na serwerze produkcyjnym, a także rozsądnie znać rozmiar swojej bazy danych, gdy płacisz za nią na platformie w chmurze. MongoDB ma polecenie db.stats()  które mogą zapewnić wgląd w statystyki przechowywania instancji MongoDB.

>db.stats()
{
	"db" : "test",
	"collections" : 5,
	"views" : 0,
	"objects" : 53829,
	"avgObjSize" : 43.555,
	"dataSize" : 2344556121,
	"storageSize" :3124416336,
	"numExtents" : 0,
	"indexes" : 7,
	"indexSize" : 8096876,
	"ok" : 1
}

dataSize

Całkowity rozmiar w bajtach nieskompresowanych danych przechowywane w tej bazie danych.

rozmiar pamięci

Łączna ilość miejsca na dysku przydzielone do wszystkich kolekcji w bazie danych.

Odpowiedź db.stats()  zależy od typu silnika MongoDB. Zależny od wersji opis powyższych wskaźników można znaleźć w dokumentacji MongoDB.

Dlaczego duża różnica między storageSize i dataSize ? Wynika to z wcześniej wyjaśnionej fragmentacji plików danych. MongoDB próbuje ponownie wykorzystać wolne miejsce pomiędzy pofragmentowanymi danymi, gdy tylko jest to możliwe, i nie zwalnia go do systemu operacyjnego. Jednak w WiredTiger, storageSize może być mniejszy niż dataSize, jeśli włączona jest kompresja.

W przypadku usunięcia dużej porcji danych z kolekcji, która nigdy nie wykorzystuje usuniętego miejsca na nowe dokumenty, miejsce to musi zostać zwrócone do systemu operacyjnego, aby mogło być używane przez inne Twoje bazy danych lub kolekcje. Musisz uruchomić kompaktowy lub napraw operacji w celu defragmentacji miejsca na dysku i odzyskania wolnego miejsca do wykorzystania.

Kompaktowanie MongoDB

Zwarta operacja MongoDB przepisuje wszystkie dokumenty i indeksy w kolekcji na ciągłe bloki miejsca na dysku. Jednak ta operacja blokuje wszystkie inne operacje na bazie danych, do której należy kolekcja. Tak więc w przypadku samodzielnego serwera zaleca się uruchamianie go podczas okna konserwacji, a w przypadku zestawów replik należy uruchamiać go w sposób kroczący dla każdego fragmentu. Oznacza to skompaktowanie najpierw wszystkich plików pomocniczych, a na końcu podstawowego, aby nie wpłynąć na dostępność Twojej bazy danych. Składnia polecenia to:

db.runCommand({compact: collection-name })

1. MMAPv1

  • Operacja zagęszczania defragmentuje pliki danych i indeksy. Należy jednak pamiętać, że nie zwalnia miejsca dla systemu operacyjnego. Operacja jest nadal przydatna do defragmentacji i tworzenia bardziej ciągłej przestrzeni do ponownego wykorzystania przez MongoDB, ale nie ma sensu, gdy wolne miejsce na dysku jest bardzo małe.
  • Podczas operacji zagęszczania wymagane jest dodatkowe miejsce na dysku do 2 GB.
  • Podczas operacji kompaktowania utrzymywana jest blokada poziomu bazy danych.

2. WiredTiger

Silnik WiredTiger domyślnie zapewnia kompresję, która zajmuje mniej miejsca na dysku niż MMAPv1.

  • Proces kompaktowy uwalnia wolną przestrzeń dla systemu operacyjnego.
  • Do uruchomienia operacji kompaktowania wymagana jest minimalna ilość miejsca na dysku.
  • WiredTiger blokuje również wszystkie operacje na bazie danych, ponieważ wymaga blokady na poziomie bazy danych.

Jeśli korzystasz z WiredTiger, zalecamy uruchomienie operacji kompaktowej, gdy pamięć masowa osiągnie 80% rozmiaru dysku. Możesz to zrobić, uruchamiając operację „Kompakt” na naszej stronie szczegółów.

Napraw MongoDB

MongoDB naprawa operacja naprawia wszystkie błędy i niespójności w przechowywaniu danych, podobnie jak polecenie fcsk dla systemu plików. To polecenie zapewnia integralność danych po nieoczekiwanym zamknięciu lub awarii. Jeśli jednak na serwerze włączone jest kronikowanie, nie ma konieczności naprawy, ponieważ serwer używa dziennika do automatycznego przejścia do stanu czystego po ponownym uruchomieniu. Jeśli twoja baza danych została uszkodzona, to napraw bazę danych nie zapisałby uszkodzonych danych, więc nie zaleca się używania tej operacji do odzyskiwania danych kiedy masz inne opcje.

W przypadku MMAPv1, napraw bazę danych to jedyny sposób na odzyskanie miejsca na dysku, jeśli uważasz, że baza danych nie została uszkodzona i ma wystarczającą ilość miejsca wymaganego przez operację naprawy. Składnia polecenia to:

db.runCommand({repairDatabase: 1})
  • To polecenie kompaktuje wszystkie kolekcje w bazie danych i odtwarza wszystkie indeksy.
  • Zadanie wymaga wolnego miejsca na dysku równego rozmiarowi bieżącego zestawu danych plus 2 gigabajty.

W ScaleGrid korzystamy z repairDatabase operacja odzyskiwania wolnego miejsca dla MMAPv1 klastry silników.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Pozwól, aby nowy ClusterControl zabezpieczył Twoje wdrożenia MongoDB

  2. Dołącz dane do istniejącego pliku gridfs

  3. łączenie się z lokalnym mongodb z kontenera docker

  4. Jak używać MongoDB z obietnicami w Node.js?

  5. Jak mogę użyć operatora LIKE na manguście?