Дисковото съхранение е критичен ресурс за всяка мащабируема система за бази данни. Производителността на вашите базирани на диск бази данни ще зависи от това как се управляват данните на диска. Вашият MongoDB сървър поддържа различни включващи движки за съхранение, които обработват управлението на съхранението и първоначално съхраняват всички документи последователно. Тъй като базата данни расте и се изпълняват множество операции за запис, това непрекъснато пространство се фрагментира на по-малки блокове с парчета свободно пространство между тях. Типичното решение е да увеличите размера на диска, но има алтернативи, които могат да ви помогнат да си върнете свободното пространство, без да се налага да мащабирате размера на диска. Едно важно нещо, което трябва да знаете, е статистиката за съхранение на MongoDB и как можете да компактирате или поправите базата данни, за да се справите с фрагментацията.

Колко голяма е вашата база данни, наистина?

Винаги трябва да следите количеството свободно дисково пространство на вашия производствен сървър и също така разумно да знаете размера на вашата база данни, когато плащате за нея на облачна платформа. MongoDB има команда db.stats()  които могат да предоставят представа за статистическите данни за съхранение на екземпляр на 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
}

размер на данни

Общият размер в байтове на некомпресираните данни съхранявани в тази база данни.

storageSize

Общото количество дисково пространство разпределено на всички колекции в базата данни.

Отговорът на db.stats()  зависи от типа на двигателя на MongoDB. Можете да намерите вашето зависимо от версията описание на горните показатели в документацията на MongoDB.

Защо голямата разлика между storageSize и размер на данни ? Това се дължи на фрагментиране на файлове с данни, обяснено по-рано. MongoDB се опитва да използва повторно свободно пространство между фрагментирани данни, когато е възможно, и не го пуска на операционната система. Въпреки това, в WiredTiger, storageSize може да е по-малък от dataSize, ако компресията е активирана.

В  случай, че голяма част от данни бъде изтрита от колекция и колекцията никога не използва изтритото пространство за нови документи, това пространство трябва да бъде върнато на операционната система, за да може да се използва от другите ви бази данни или колекции. Ще трябва да стартирате компакт или ремонт операция с цел дефрагментиране на дисковото пространство и възстановяване на използваемото свободно пространство.

Уплътняване на MongoDB

Компактната операция на MongoDB пренаписва всички документи и индекси в колекция в последователни блокове дисково пространство. Тази операция обаче блокира всички други операции в базата данни, към която принадлежи колекцията. Така че, за самостоятелен сървър, се препоръчва да го стартирате по време на прозорец за поддръжка, а за набори от реплики трябва да го стартирате по непрекъснат начин за всеки фрагмент. Това означава първо уплътняване на всички вторични и накрая първичните, така че наличността на базата ви данни да не бъде засегната. Синтаксисът на командата е:

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

1. MMAPv1

• Операцията за уплътняване дефрагментира файлове с данни и индекси. Въпреки това, имайте предвид, че той не освобождава място за операционната система. Операцията все още е полезна за дефрагментиране и създаване на по-последователно пространство за повторно използване от MongoDB, но е безполезна, когато свободното дисково пространство е много малко.
• Изисква се допълнително дисково пространство до 2GB по време на операцията по уплътняване.
• Заключване на ниво база данни се задържа по време на операцията по уплътняване.

2. WiredTiger

Двигателят WiredTiger осигурява компресия по подразбиране, което консумира по-малко дисково пространство от MMAPv1.

• Компактният процес освобождава свободното пространство на операционната система.
• Изисква се минимално дисково пространство за изпълнение на компактната операция.
• WiredTiger също така блокира всички операции с базата данни, тъй като се нуждае от заключване на ниво база данни.

Ако използвате WiredTiger, препоръчваме да стартирате компактната операция, когато паметта достигне 80% от размера на диска. Можете да направите това, като задействате операция „Компакт“ от нашата страница с подробности.

Поправете MongoDB

MongoDB поправка операцията поправя всички грешки и несъответствия в съхранението на данни, подобно на командата fcsk за файлова система. Тази команда гарантира целостта на данните след неочаквано изключване или срив. Въпреки това, ако воденето на дневник е активирано на сървъра, тогава няма изискване за ремонт, тъй като сървърът използва дневника, за да влезе в чисто състояние автоматично след рестартиране. Ако вашата база данни е била повредена, тогава поправете база данни няма да запази повредените данни, така че не се препоръчва да използвате тази операция за възстановяване на данни когато имате други опции.

За MMAPv1,  поправете база данни е единственият начин да възстановите дисково пространство, ако смятате, че вашата база данни не е повредена и има достатъчно място, необходимо за операцията по ремонт. Синтаксисът на командата е:

db.runCommand({repairDatabase: 1})

• Тази команда уплътнява всички колекции в базата данни и пресъздава всички индекси.
• Заданието изисква свободно дисково пространство, равно на размера на текущия ви набор от данни плюс 2 гигабайта.

В ScaleGrid използваме repairDatabase операция за възстановяване на свободно пространство за MMAPv1 клъстери на двигатели.