Една от най-рекламираните характеристики на MongoDB е способността му да бъде „безсхемен“. Това означава, че MongoDB не налага никаква схема върху документи, съхранявани в колекция. Обикновено MongoDB съхранява документи във формат JSON, така че всеки документ може да съхранява различни видове схеми/структури. Това е полезно за началните етапи на разработка, но в по-късните етапи може да искате да наложите някаква валидация на схемата, докато вмъквате нови документи за по-добра производителност и мащабируемост. Накратко, „безсхемно“ не означава, че не е необходимо да проектирате своята схема. В тази статия ще обсъдя някои общи съвети за планиране на вашата MongoDB схема.
Измислянето на най-добрия дизайн на схема, който отговаря на вашето приложение, понякога може да стане досадно. Ето някои точки, които можете да вземете предвид при проектирането на вашата схема.
Избягвайте нарастващите документи
Ако вашата схема позволява създаване на документи, които непрекъснато нарастват по размер, тогава трябва да предприемете стъпки, за да избегнете това, защото това може да доведе до влошаване на производителността на DB и дисково IO. По подразбиране MongoDB позволява 16MB размер на документ. Ако размерът на вашия документ се увеличи с повече от 16 MB за определен период от време, това е знак за лош дизайн на схемата. Понякога това може да доведе до неуспех на заявките. Можете да използвате кофи за документи или техники за предварително разпределение на документи, за да избегнете тази ситуация. В случай, че приложението ви трябва да съхранява документи с размер над 16 MB, тогава можете да обмислите използването на MongoDB GridFS API.
Избягвайте да актуализирате цели документи
Ако се опитате да актуализирате целия документ, MongoDB ще пренапише целия документ на друго място в паметта. Това може драстично да влоши производителността на запис на вашата база данни. Вместо да актуализирате целия документ, можете да използвате модификатори на полета, за да актуализирате само определени полета в документите. Това ще задейства актуализация на място в паметта, а оттам и подобрена производителност.
Опитайте се да избягвате присъединявания на ниво приложение
Както всички знаем, MongoDB не поддържа присъединявания на ниво сървър. Следователно трябва да получим всички данни от DB и след това да извършим присъединяване на ниво приложение. Ако извличате данни от множество колекции и обединявате голямо количество данни, трябва да се обадите на DB няколко пъти, за да получите всички необходими данни. Това очевидно ще изисква повече време, тъй като включва мрежата. Като решение за този сценарий, ако вашето приложение силно разчита на съединения, тогава денормализиращата схема има по-голям смисъл. Можете да използвате вградени документи, за да получите всички необходими данни с едно извикване на заявка.
Използвайте правилно индексиране
Докато правите търсене или агрегиране, човек често сортира данни. Въпреки че кандидатствате за сортиране в последния етап от конвейера, все още имате нужда от индекс, който да покрие сортирането. Ако индексът на полето за сортиране не е наличен, MongoDB е принуден да сортира без индекс. Има ограничение на паметта от 32MB от общия размер на всички документи, които участват в операцията за сортиране. Ако MongoDB достигне това ограничение, може или да доведе до грешка, или да върне празен набор.
След като обсъдихме добавянето на индекси, също така е важно да не добавяте ненужни индекси. Всеки индекс, който добавяте в базата данни, трябва да актуализирате всички тези индекси, докато актуализирате документи в колекцията. Това може да влоши производителността на базата данни. Освен това всеки индекс ще заема малко място и памет, така че броят на индексите може да доведе до проблеми, свързани със съхранението.
Още един начин за оптимизиране на използването на индекс е отмяната на полето _id по подразбиране. Единствената цел на това поле е запазването на едно уникално поле на документ. Ако вашите данни съдържат времева марка или поле за идентификатор, тогава можете да замените полето _id и да запазите един допълнителен индекс.
Severalnines Станете DBA на MongoDB – Пренасяне на MongoDB в Производството Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате MongoDB Изтеглете безплатноСъотношение на четене и запис
Проектирането на схема за всяко приложение до голяма степен зависи от това дали дадено приложение се чете тежко или пише тежко. Например, ако изграждате табло за показване на данни от времеви серии, тогава трябва да проектирате вашата схема по такъв начин, че да увеличи максимално пропускателната способност на запис. Ако приложението ви е базирано на електронна търговия, тогава повечето от операциите ще бъдат операции за четене, тъй като повечето потребители ще преминават през всички продукти и ще преглеждат различни каталози. В такива случаи трябва да използвате денормализирана схема, за да намалите броя на извикванията към DB за получаване на подходящи данни.
Типове данни на BSON
Уверете се, че сте дефинирали BSON типове данни за всички полета правилно, докато проектирате схема. Тъй като когато промените типа данни на което и да е поле, MongoDB ще пренапише целия документ в ново пространство на паметта. Например, ако се опитате да съхраните (int)0 на мястото на полето (float)0.0, MongoDB пренаписва целия документ на нов адрес поради промяна в типа данни на BSON.
Заключение
Накратко, разумно е да проектирате схема за вашата база данни Mongo, тъй като това само ще подобри производителността на вашето приложение. Започвайки от версия 3.2, MongoDB започна да поддържа валидиране на документи, където можете да дефинирате кои полета са необходими за вмъкване на нов документ. От версия 3.6 MongoDB въведе по-елегантен начин за налагане на валидиране на схема с помощта на валидиране на схемата на JSON. Използвайки този метод за валидиране, можете да наложите проверка на типа данни заедно с проверка на задължителните полета. Можете да използвате горните подходи, за да проверите дали всички документи използват един и същ тип схема или не.
