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