Какво да знаете, когато започнете да работите с MongoDB в производството - десет съвета

Изучаването на MongoDB изисква много прецизно мислене. Често не се обръща малко внимание на съществени предприятия, които иначе биха могли да застрашат работата на базата данни в производствен режим.

MongoDB е NoSQL СУБД, която буквално следва различен модел от SQL бази данни, особено по отношение на сигурността и структурата. Въпреки че някои от интегрираните функции насърчават неговата производителност и го правят една от най-добрите в последно време, някои от функциите следователно представляват потенциални заплахи, които могат да развалят производителността му, ако не се вземат предвид.

При скорошен опит в „най-лошия случай“ се опитвах да направя заявка за колекция с документи, които имат големи масиви и ми отне векове, за да получа резултатите обратно. Реших да напиша този блог, тъй като знаех, че ако някой изпита същите проблеми, че този блог ще бъде от голяма полза.

Ключови съображения за MongoDB в производството

1. Сигурност и удостоверяване.
2. Индексиране на вашите документи
3. Използване на схема във вашите колекции
4. Ограничена колекция
5. Размер на документа
6. Размер на масива за вградени документи
7. Етапи на тръбопровода за агрегиране
8. Ред на ключовете в хеш обекта
9. „undefined“ и „null“ в MongoDB
10. Операция за запис

Сигурност и удостоверяване на MongoDB

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

Данните се записват във файлове, които могат да бъдат достъпни чрез инструмент на трета страна още повече, така че ако не са криптирани. Данните могат да бъдат променени без ваше знание, ако някой анонимен получи достъп до системните файлове. Хостването на базата данни на специален сървър и определянето на един потребител, който ще има пълен достъп до файловете с данни, ще ви спести трика.

Защитата на данни от външни атаки с инжектиране също е важно начинание. Някои оператори като $group, $whereby и операциите mapReduce са разработени в javascript(js), поради което са склонни към js манипулация. За да избегнете всякакъв случай на целостта на данните в резултат на това, можете да деактивирате произволна настройка на JS, като конфигурирате параметъра javascriptEnabled:false в конфигурационния файл, ако не сте използвали нито един от споменатите оператори. Освен това можете да намалите риска от достъп до данни чрез мрежови пробиви, като използвате някои от процедурите, подчертани в  Контролния списък за сигурност на MongoDB.

Индексиране на вашите документи

Индексирането обикновено присвоява уникална идентификационна стойност на всеки документ в колекция MongoDB. Индексирането води до надграждане на производителността както при операциите за четене, така и за запис. По подразбиране  тя е активирана и винаги трябва да поддържате тази настройка. Без индексиране базата данни трябва да проверява множество документи от началото до края и за съжаление операцията ще струва време за документи, които са към края, което води до лошо забавяне на заявката. В даден момент, в края на приложението, потребителите може да изпитат забавяне и може да помислят, че приложението всъщност не работи. Индексирането е полезно при операции за сортиране и търсене, като не пропуска самата операция за намиране. Сортирането е обичайна операция за много върнати документи. Често се извършва като последен етап след филтриране на документи, така че трябва да се сортират малко количество данни. Индексът в този случай ще помогне за сортиране на данните по естество на въвеждане и ще ограничи върнатите данни до лимит от 32MB. Ако няма индексиране, шансовете за ограничението от 32 памет за комбинирания размер на върнатите документи ще бъдат надвишени и всеки път, когато базата данни достигне това ограничение, тя ще изведе грешка, освен че ще върне празен набор от записи.

Операцията $lookup също се поддържа с индексиране. Индексът на стойността на ключа, използван като външен ключ, е от съществено значение за обработката на предходните етапи.

Използване на схема във вашите колекции

MongoDB не се нуждае от такъв, за да дефинира полета (колони), точно както може да изисква от вас да го направите за SQL dbms. Колкото и да не е необходимо да дефинирате полетата, за да избегнете непоследователност на данните и някои неуспехи, които могат да възникнат, дефинирането на схема винаги е добра практика. Дизайнът на схемата ви позволява да определите кой тип данни отиват в определено поле, кое поле трябва да бъде снабдено със стойност и като цяло подобрява валидирането на данните преди въвеждане или актуализиране, като по този начин насърчава целостта и последователността на данните. Дизайнът на схема също ще ви насочи дали да препратите или да вградите данни. Като начинаещ може да си мислите, че единственият модел ще бъде „Едно към N“, което ще улесни човек да има записи в масив от поддокумент, но това не е така.

Трябва да разберете кардиналността между документите, преди да направите своя модел. Някои от правилата, които  ще ви помогнат да имате оптимална схема, са:

1. За да намалите броя на заявките, които ще трябва да изпълните, преди  да получите достъп до някои данни и ако са включени няколко полета или елементи на масив, тогава можете да вградите поддокументи. Вземете пример за модела по-долу:
   1. ​

      {
       Name: ‘John Doh’,
       Age:20
       Addresses:[
         {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’},
         {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’},
       ]
      }
      

2. За често актуализирани документи използвайте денормализация . Ако някое поле ще се актуализира често, тогава ще има задача да се намерят всички екземпляри, които трябва да бъдат актуализирани. Това ще доведе до бавна обработка на заявките, следователно ще превъзхожда дори достойнствата, свързани с денормализацията.
3. Сложни заявки като обобщен конвейер отнемат повече време за изпълнение, когато са включени много поддокументи и има нужда от извличане на документ отделно.
4. Елементите на масива с голям набор от данни за обекти не трябва да се вграждат очевидно поради факта, че те могат да нараснат и следователно  да надвишават размера на документа.

Моделирането на схема често се определя от модела за достъп до приложението. Можете да намерите още процедури, които могат да помогнат при проектирането на вашия модел в блога 6 Rules of Thumb for MongoDB Schema Design

Използване на ограничена колекция за приоритет на скорошни документи

MongoDB предоставя много ресурси като ограничената колекция. За съжаление някои в крайна сметка не се използват. Ограничената колекция има фиксиран размер и е известно, че поддържа високопроизводителни операции, които вмъкват и извличат документи въз основа на реда за вмъкване. Когато мястото му се запълни, старите документи се изтриват, за да се даде място за нови.

Пример за случай на използване на ограничена колекция :

• Кеширане на често достъпни данни, тъй като самата колекция е тежка за четене, а не за запис. Трябва да гарантирате, че колекцията е винаги в изпълнение.
• Регистрационна информация за системи с голям обем. Ограничената колекция често не използва индекс и това е изгодно, тъй като скоростта на запис е доста бърза, точно като запис във файл.

Обърнете внимание на размера на документа на MongoDB

Всеки документ на MongoDB е ограничен до размер от 16 мегабайта. Въпреки това е оптимално документът  да достигне или доближи това ограничение, тъй като това ще създаде някои ужасни проблеми с производителността. Самият MongoDB работи най-добре, когато размерът на документите е няколко килобайта. Ако документът е с достатъчно голям размер,   сложната заявка за прожектиране ще отнеме много време и може да изтече времето на заявката.

Обърнете внимание на размера на масива на вградените документи

Може да се бутат поддокументи към поле в документ, като по този начин се създава стойност на масив в това поле. Както бе споменато по-горе, трябва да поддържате малкия размер на поддокументите. Също толкова важно е да се уверите, че броят на елементите на масива е под четири цифри. В противен случай документът ще надхвърли размера си и ще трябва да бъде преместен на диска. Допълнителен проблем, свързан с такава операция, е, че всеки документ ще трябва да бъде повторно индексиран. Освен това всеки поддокумент  ще трябва да бъде преиндексиран. Това означава, че ще има много записи на индекси, което води до бавни операции. За голям размер на поддокумента е по-скоро важно записите да се съхраняват в нова колекция, отколкото да се вграждат.

Етапи на конвейера за агрегиране 

Освен нормалните операции със заявки в MongoDB, има рамка за агрегиране, използвана за манипулиране и връщане на данни в съответствие с някои спецификации, като подреждане и групиране. MongoDB няма оптимизатор на заявки, следователно се нуждае от такъв, за да подреди заявките по подходящ начин. С  рамката за агрегиране се уверете, че етапите на тръбопровода са добре подредени. Започнете с намаляване на количеството данни, с които работите, като използвате оператора $match и евентуално $sort накрая, ако трябва да сортирате. Можете да използвате инструменти на трети страни, като Studio 3T, за да оптимизирате заявката си за агрегиране, преди да я интегрирате във вашия код. Инструментът ви позволява да виждате въвеждане и извеждане на данни на всеки от етапите, като по този начин знаете с какво си имате работа.

Използването на $limit и $sort винаги трябва да дава едни и същи резултати всеки път, когато се изпълнява заявката. В случай, че използвате $limit, върнатите данни няма да бъдат детерминирани и може да доведат до някои проблеми, които са трудни за проследяване.

Проверете реда на ключовете в хеш обекти

Помислете за наличието на два големи документа с примерни данни 

{

   FirstName: ‘John’,

   LastName: ‘Doh’

}

Ако извършите операция за намиране със заявката {FirstName:'John', LastName:'Doh'}, операцията не съвпада със заявката {LastName:'Doh' FirstName:'John' }. Следователно трябва да поддържате реда на двойките име и стойност във вашите документи.

Избягвайте „undefined“ и „null“ в MongoDB

MongoDB използва формат BSON за своите документи. С валидиране на JSON, „undefined“ не се поддържа и трябва да избягвате да го използвате. $null идва като решение, но вие също трябва да го избягвате.

Помислете за операции за запис

Можете да настроите MongoDB за високоскоростно записване, но това води до неуспех в това, че отговорът се връща дори преди записването на данните. Воденето на журнал трябва да бъде активирано , за да се избегне този сценарий. Освен това, в случай на повреда на база данни, данните все още ще бъдат налични и ще създаде контролна точка, която може да се използва в процеса на възстановяване. Конфигурацията за продължителността на записите в дневника може да бъде зададена с помощта на параметъра commitIntervalMs.

Заключение

Системата за бази данни трябва да гарантира целостта и последователността на данните, освен че е устойчива на отказ и злонамереност. Въпреки това, за да стигнем до тези фактори, човек трябва да разбере самата база данни и данните, които тя съдържа. MongoDB ще работи добре, когато се вземат предвид споменатите по-горе фактори. Най-важното е използването на схема. Схемата ви позволява да потвърдите данните си преди въвеждане или актуализиране и как ще моделирате тези данни. Моделирането на данни често се ръководи от модела за достъпност на приложението. Всички тези сумирани ще предложат по-добра производителност на базата данни.