Преводът на статията е подготвен в очакване на старта на курса .
Основни моменти:
- Изключително важно е да разработите схема, въпреки че в MongoDB тя не е задължителна.
- Аналогично, индексите трябва да съответстват на вашата схема и шаблони за достъп.
- Избягвайте използването на големи обекти и големи масиви.
- Бъдете внимателни с настройките на MongoDB, особено когато става дума за сигурност и надеждност.
- В MongoDB няма оптимизатор на заявки, затова трябва да бъдете внимателни при изпълнението на операции с заявки.
Дълго време работя с бази данни, но едва наскоро открих MongoDB. Има няколко неща, които бих искал да знам преди да започна работа с нея. Когато човек вече има опит в определена област, той има предварителни предразсъдъци за това какво представляват базите данни и какво правят. За да улесня разбирането на другите, представям списък с общи грешки.
Създаване на MongoDB сървър без удостоверяване
За съжаление, MongoDB по подразбиране се инсталира без удостоверяване. За работна станция, до която се осъществява локален достъп, тази практика е нормална. Но тъй като MongoDB е многопотребителска система, която обича да използва големи обеми памет, ще бъде по-добре, ако я инсталирате на сървър с максимално възможно количество оперативна памет в условията, в които работите, дори ако планирате да я използвате само за разработка. Инсталирането на сървър през подразбиращия порт може да стане проблемно, особено ако в заявката може да се изпълни всеки код на JavaScript (например, $where като идея за ).
Има няколко метода за удостоверяване, но най-простият е да зададете ID/парола за потребителя. Ползвайте тази идея, докато обмисляте по-сложна удостоверителна система на базата на . Когато говорим за сигурност, MongoDB трябва постоянно да бъде актуализирана, а логовете винаги трябва да се проверяват за несанкциониран достъп. На мен, например, ми харесва да избирам друг порт вместо подразбиращия.
Не забравяйте да ограничите повърхностите на атака на MongoDB
съдържа добри съвети за намаляване на риска от пробив в мрежата и leaking на данни. Лесно е да се откажем и да кажем, че сървърът за разработка не се нуждае от висок ниво на сигурност. Но не е така просто и това важи за всички сървъри на MongoDB. По-специално, ако няма основателна причина да се използва , или , трябва да се деактивира използването на произволн код на JavaScript, като се запише в конфигурационния файл . Тъй като в стандартната MongoDB файловете с данни не са криптирани, разумно е да се стартира MongoDB с , който има пълен достъп до файловете, с ограничен достъп само за него и възможност за използване на собствени средства за управление на достъпа до файловете на операционната система.
Грешка при проектиране на схемата
MongoDB не използва схема. Но това не значи, че схемата не е необходима. Ако искате просто да съхранявате документи без никаква последователна схема, можете да ги съхраните бързо и лесно, но извличането им по-късно може да е .
Класическата статия „ си струва да се прочете, а функции като в инструмента Studio 3T си заслужават да се използват за редовни проверки на схемите.
Не забравяйте за реда на сортиране
Забравяйки за реда на сортиране, можете да останете разочаровани и да загубите повече време, отколкото ако използвахте всяка друга неправилна конфигурация. По подразбиране MongoBD използва . Но едва ли ще е полезно за някого. Чувствителните към регистър, акцент, бинарни сортирания се смятаха за любопитни анахронизми заедно с мъниста, кафтан и къдрави мустаци още в 80-те години на миналия век. Сега тяхната употреба е непростима. В реалния живот „мотоциклет“ е същото, както и „Мотоциклет“. А „Британия“ и „британия“ са едно и също място. Малката буква е просто главен еквивалент на голямата буква. И не ме карайте да говоря за сортиране на диакритични знаци. При създаване на база данни в MongoDB използвайте параметри за сортиране без да се отчитат акценти и , които съответстват на езика и . Така значително ще опростите търсенето на текстови данни.
Създаване на колекции с големи документи
MongoDB радва да разполага големи документи с размер до 16 МБ в колекции, а е предназначена за големи документи с размер над 16 МБ. Но само защото големи документи могат да бъдат разположени там, не е добра идея да ги съхранявате там. Най-добре MongoDB ще работи, ако запазвате отделни документи с размери в няколко килобайта, разглеждайки ги повече като редове в широка SQL таблица. Големите документи ще бъдат източник на проблеми с .
Създаването на документи с големи масиви
Документите могат да съдържат масиви. Най-добре е, ако броят на елементите в масива е далеч от четиризначно число. Ако елементите към масива се добавят често, той ще надмине съдържащия го документ и ще трябва да бъде , което означава, че ще трябва да се . При повторно индексиране на документ с голям масив, индексите често ще бъдат перезаписвани, тъй като за всеки елемент съществува , съ храняващ неговия индекс. Такава преиндексация също така се случва, когато документът се вмъква или изтрива.
В MongoDB има така наречения , който предоставя пространство за растеж на документите, за да се сведе до минимум този проблем.
Може да си помислите, че можете да се справите без индексиране на масиви. За съжаление, поради липсата на индекси, могат да възникнат други проблеми. Тъй като документите се преглеждат от начало до край, търсенето на елементи в края на масива ще отнеме повече време, а и повечето операции, свързани с такъв документ, ще бъдат .
Не забравяйте, че редът на етапите в агрегизацията има значение
В системата на базата данни с оптимизатор на заявки, заявките, които пишете, са обяснения за това, което искате да получите, а не как да го получите. Такъв механизъм работи по аналогия с поръчка в ресторант: обикновено просто поръчвате ястие, а не давате подробни инструкции на готвача.
В MongoDB вие инструктирате готвача. Например, трябва да се уверите, че данните преминават през reduce колкото се може по-рано в пайплайна с помощта на $match и $project, а сортирането се случва само след това reduce, и че търсенето се извършва точно в реда, в който ви е необходимо. Наличието на оптимизатор на заявки, който премахва ненужната работа, оптимално подрежда стъпките и избира типа свързаност, може да ви разнежва. В MongoDB имате повече контрол за сметка на удобството.
Инструменти като оптимизират изграждането на заявки за агрегация в . Функцията Aggregation Editor ще ви позволи да прилагате оператори на пайплайн по една стъпка наведнъж, както и да проверявате входните и изходните данни на всяка стъпка за улесняване на дебъгинга.
Използването на бързи записи
Никога не задавайте в MongoDB параметри за запис с висока скорост, но ниска надеждност. Режимът «file-and-forget» изглежда бърз, тъй като командата се връща преди реалния запис. Ако системата падне, преди данните да бъдат записани на диск, те ще се загубят и ще останат в несъответствие. За щастие, в 64-битния MongoDB е включено логиране.
Двигателите за съхранение MMAPv1 и WiredTiger използват логиране, за да предотвратят това, макар че WiredTiger може да се възстанови до последната съгласувана , ако логиране е деактивирано.
Логиране гарантира, че базата данни е в съгласувано състояние след възстановяване и съхранява всички данни до момента на запис в лог. Периодичността на записите се настройва с параметъра .
За да сте сигурни в записите, уверете се, че в конфигурационния файл логиране е активирано ), а периодичността на записите отговаря на обема информация, която можете да си позволите да загубите.
Сортиране без индекс
При търсене и агригация често се налага сортиране на данни. Да се надяваме, че това ще се направи на един от финалните етапи, след филтриране на резултата с цел намаляване на обема на сортираните данни. И дори в такъв случай ще ви е необходим . Можете да използвате единичен или съставен индекс.
Ако подходящ индекс няма, MongoDB ще се справи и без него. Има ограничение на паметта от 32 Мб за общия размер на всички документи в , и ако MongoDB достигне този лимит, то или ще върне грешка, или ще върне .
Търсене без поддръжка на индекси
Търсещите заявки изпълняват функция, аналогична на операция JOIN в SQL. За по-добра работа им е необходим индекс на стойността на ключа, използван като външен ключ. Това не е очевидно, тъй като използването не е отразено в explain(). Такива индекси са допълнение към индекса, записан в explain(), който от своя страна се използва от операторите на пайплайна $match и $sort, когато те се срещат в началото на пайплайна. Индексите вече могат да обхващат всяка фаза .
Отказ от използването на многообновления
Методът се използва за промяна на част от съществуващ документ или на целия документ, включително до пълна замяна в зависимост от зададения от вас параметър . Не е толкова очевидно, че той няма да обработи всички документи в колекцията, докато не зададете параметър за актуализиране на всички документи, отговарящи на критериите на запитването.
Не забравяйте важността на реда на ключовете в хеш-таблица
В JSON обектът се състои от неупорядочена колекция с нула или повече двойки име/стойност, където името е низ, а стойността е низ, число, логическа стойност, нула, обект или масив.
За съжаление, BSON отдава голямо значение на реда при търсене. В MongoDB редът на ключовете вътре в вградени обекти , т.е. { firstname: "Phil", surname: "factor" } – не е същото, както { { surname: "factor", firstname: "Phil" }. Тоест, трябва да запазите реда на двойките име/стойност в документите, ако искате да сте сигурни, че ще ги намерите.
Не бъркайте «null» и «undefined»
Стойност «undefined» никога не е било допустимо в JSON, съгласно JSON (ECMA-404, Раздел 5), въпреки че се използва в JavaScript. Освен това, за BSON то е остаряло и се преобразува в $null, което не винаги е добро решение. .
Използването $limit() без $sort()
Много често, когато развивате в MongoDB, е полезно просто да видите примерен резултат, който ще се върне от запитването или агрегирацията. За тази задача ще ви бъде полезно $limit(), но никога не трябва да бъде в финалната версия на кода, освен ако преди това не използвате $sort. Тази механика е необходима, тъй като в противен случай не можете да гарантирате реда на резултата и няма да можете надеждно да преглеждате данните. В горната част на резултата ще получавате различни записи в зависимост от сортирането. За надеждната работа заявките и агрегациите трябва да бъдат детерминирани, тоест да дават еднакви резултати при всяко изпълнение. Кодът, в който има $limit(), но няма $sort, няма да бъде детерминиран и по-късно може да предизвика грешки, които ще бъдат трудни за проследяване.
Заключение
Единственият начин да се разочаровате от MongoDB е да я сравнявате директно с друг тип бази данни, като СУБД, или да започнете да я използвате, основавайки се на определени очаквания. Това е като да сравнявате портокал с вилица. Системите за управление на бази данни имат определени цели. Най-добре е просто да разберете и оцените тези различия. Бъде хубаво да натискате разработчиците на MongoDB заради пътя, по който ги е принудил да вървят по пътя на СУБД. Искам да виждам нови и интересни начини за решаване на стари проблеми, като осигуряване на целостта на данните и създаване на системи за данни, устойчиви на сривове и атаки от злонамерени лица.
Внедряването на ACID транзакционност в MongoDB в версия 4.0 е добър пример за внедряване на важни подобрения по иновативен начин. Мултидокументалните и мултиоператорни транзакции сега са атомарни. Също така се появи възможността да се регулира времето, необходимо за получаване на блокировки, и да се приключват зависнали транзакции, както и да се променя нивото на изолация.
Прочетете още:
Източник: habr.com
