Dlaczego pusta baza danych MongoDB jest tak duża?

W zależności od wersji MongoDB i skonfigurowanego silnika przechowywania kilka plików danych i metadanych zostanie wstępnie przydzielonych podczas uruchamiania. Jest to oczekiwane zachowanie:„puste” wdrożenie nadal skutkuje porządkowaniem i danymi diagnostycznymi.

W oparciu o listę katalogów używasz MongoDB 3.2, która domyślnie korzysta z mechanizmu przechowywania WiredTiger. WiredTiger przydziela do 100 MB na plik dziennika, więc nowe wdrożenie ma ~300 MB wstępnie przydzielonych plików dziennika :

     100M    ./journal/WiredTigerLog.0000000003
     100M    ./journal/WiredTigerPreplog.0000000001
     100M    ./journal/WiredTigerPreplog.0000000002

Oprócz plików dziennika, inne metadane, które zostaną utworzone w Twojej dbpath (bez wyraźnego utworzenia baz danych) będzie zawierać:

• local baza danych z ograniczoną kolekcją o nazwie startup_log z pewnymi informacjami diagnostycznymi o każdym uruchomieniu tego wystąpienia mongod . Będzie powiązana kolekcja i plik indeksu dla local.startup_log; nazwy plików są nieprzezroczyste, ale jako pierwsze utworzone pliki, zgaduję, w twoim przykładzie mogą to być:

   36K    ./collection-0-3697658674625742251.wt
   36K    ./index-1-3697658674625742251.wt
  

• Wiele plików metadanych WiredTiger. We wdrożeniu zawsze będzie co najmniej jedna baza danych, ponieważ local baza danych jest tworzona domyślnie dla startup_log :

  4.0K    ./WiredTiger
  4.0K    ./WiredTiger.lock
  4.0K    ./WiredTiger.turtle
  4.0K    ./WiredTigerLAS.wt
   16K    ./_mdb_catalog.wt
   36K    ./sizeStorer.wt
   44K    ./WiredTiger.wt
  

• diagnostic.data informator; to jest do okresowego próbkowania metryk stanu serwera:

  168K    ./diagnostic.data/metrics.2016-06-10T11-17-58Z-00000
  72K    ./diagnostic.data/metrics.2016-06-10T10-19-31Z-00000