Позволете ми да ви дам няколко съвета въз основа на моите глобални познания и опит:
Използвайте по-кратки имена на полета
MongoDB съхранява един и същ ключ за всеки документ. Това повторение води до увеличаване на дисковото пространство. Това може да има някакъв проблем с производителността на много огромна база данни като вашата.
Плюсове:
- По-малък размер на документите, по-малко дисково пространство
- Още документи, които да се поберат в RAM (повече кеширане)
- Размерът на индексите на do ще бъде по-малък в някои сценарии
Минуси:
- По-малко четими имена
Оптимизиране на размера на индекса
Колкото по-малък е размерът на индекса, толкова повече се вписва в RAM и по-малко се случва пропускането на индекса. Помислете за SHA1 хеш за git commits например. Git commit много пъти се представя от първите 5-6 знака. След това просто запазете 5-6 знака вместо целия хеш.
Разберете коефициента на запълване
За актуализации, които се случват в документа, причиняващи скъпо преместване на документ. Това преместване на документа води до изтриване на стария документ и актуализирането му до ново празно място и актуализиране на индексите, което е скъпо.
Трябва да се уверим, че документът не се мести, ако се случи някаква актуализация. За всяка колекция има фактор за допълване, който казва, по време на вмъкването на документ, колко допълнително пространство да бъде разпределено освен действителния размер на документа.
Можете да видите коефициента на запълване на колекцията, като използвате:
db.collection.stats().paddingFactor
Добавете ръчно запълване
Във вашия случай със сигурност ще започнете с малък документ, който ще нарасне. Актуализирането на вашия документ след време ще доведе до множество премествания на документи. Така че по-добре добавете подпълване за документа. За съжаление няма лесен начин за добавяне на подложка. Можем да го направим, като добавим няколко произволни байта към някакъв ключ, докато правим вмъкване и след това изтрием този ключ в следващата заявка за актуализиране.
И накрая, ако сте сигурни, че някои ключове ще дойдат в документите в бъдеще, тогава предварително разпределете тези ключове с някои стойности по подразбиране, така че по-нататъшните актуализации да не причинят увеличаване на размера на документа, причинявайки преместване на документа.
Можете да получите подробности за заявката, причиняваща преместване на документ:
db.system.profile.find({ moved: { $exists : true } })
Голям брой колекции срещу голям брой документи в няколко колекции
Схемата е нещо, което зависи от изискванията на приложението. Ако има огромна колекция, в която търсим само последните N дни данни, тогава можем по избор да изберем да имаме отделно събиране и старите данни могат да бъдат безопасно архивирани. Това ще гарантира, че кеширането в RAM се извършва правилно.
Всяка създадена колекция носи разходи, които са повече от разходите за създаване на колекция. Всяка от колекцията има минимален размер, който е няколко KB + един индекс (8 KB). Всяка колекция има асоциирано пространство от имена, по подразбиране имаме 24K пространства от имена. Например, да имате колекция на потребител е лош избор, тъй като не е мащабируема. След известен момент Mongo няма да ни позволи да създаваме нови колекции от индекси.
По принцип наличието на много колекции не води до значително намаляване на производителността. Например, можем да изберем да имаме една колекция на месец, ако знаем, че винаги правим запитвания въз основа на месеци.
Денормализация на данните
Винаги се препоръчва да съхранявате всички свързани данни за заявка или поредица от заявки на едно и също място на диска. Имате нужда да дублирате информацията в различни документи. Например, в публикация в блог, ще искате да съхранявате коментарите на публикацията в документа на публикацията.
Плюсове:
- размерът на индекса ще бъде много по-малък, тъй като броят на записите в индекса ще бъде по-малък
- заявката ще бъде много бърза, което включва извличане на всички необходими подробности
- размерът на документа ще бъде сравним с размера на страницата, което означава, че когато пренасяме тези данни в RAM, през повечето време не пренасяме други данни на страницата
- преместването на документа ще гарантира, че освобождаваме страница, а не малка малка част от страницата, която може да не се използва при по-нататъшни вмъквания
Ограничени колекции
Ограничената колекция се държи като кръгови буфери. Те са специален тип колекции с фиксиран размер. Тази колекция може да получава много висока скорост на запис и последователно четене. Тъй като размерът е фиксиран, след като разпределеното място се запълни, новите документи се записват чрез изтриване на по-старите. Актуализациите на документи обаче са разрешени само ако актуализираният документ отговаря на оригиналния размер на документа (играйте с подплънки за по-голяма гъвкавост).
