Преводот на статијата е подготвен во пресрет на почетокот на курсот .
Нагласува:
- Исклучително е важно да се развие шема иако таа е опционална во MongoDB.
- Исто така, индексите мора да одговараат на вашата шема и шаблони за пристап.
- Избегнувајте користење на големи предмети и големи низи.
- Бидете внимателни со поставките на MongoDB, особено кога станува збор за безбедност и доверливост.
- MongoDB нема оптимизатор за пребарување, затоа мора да бидете внимателни кога извршувате операции за пребарување.
Работев со бази на податоци многу долго време, но неодамна го открив MongoDB. Има неколку работи кои би сакал да ги знам пред да почнам да работам со него. Кога некое лице веќе има искуство во одредена област, тие имаат однапред замислени идеи за тоа што се бази на податоци и што прават. Со надеж дека ќе им олеснам на другите да разберат, презентирам листа на вообичаени грешки.
Креирање на MongoDB сервер без автентикација
За жал, MongoDB е стандардно инсталиран без автентикација. За работна станица до која се пристапува локално, оваа практика е нормална. Но, бидејќи MongoDB е мулти-кориснички систем кој сака да користи големи количини меморија, ќе биде подобро ако го ставите на сервер со што е можно повеќе RAM, дури и ако го користите само за развој. Инсталирањето на серверот преку стандардната порта може да биде проблематично, особено ако во барањето може да се изврши кој било Javascript код (на пример, $where како идеја за ).
Постојат неколку методи за автентикација, но најлесно е да поставите кориснички ID/лозинка. Користете ја оваа идеја додека размислувате за фенси автентикација врз основа на . Кога станува збор за безбедноста, MongoDB треба постојано да се ажурира, а дневниците секогаш треба да се проверуваат за неовластен пристап. На пример, сакам да изберам друга порта како стандардна порта.
Не заборавајте да ја поврзете површината за напад со MongoDB
содржи добри совети за намалување на ризикот од упад во мрежата и истекување на податоци. Лесно е да се исчисти и да се каже дека на серверот за развој не му треба високо ниво на безбедност. Сепак, не е толку едноставно и ова важи за сите MongoDB сервери. Особено, ако не постои убедлива причина за употреба , или , треба да ја оневозможите употребата на произволен код во JavaScript со запишување во конфигурациската датотека . Бидејќи датотеките со податоци не се шифрирани во стандардниот MongoDB, има смисла да се работи со MongoDB , кој има целосен пристап до датотеките, со ограничен пристап само до него и можност за користење на сопствените контроли за пристап до датотеки на оперативниот систем.
Грешка при развивање на колото
MongoDB не користи шема. Но, тоа не значи дека шемата не е потребна. Ако сакате само да складирате документи без конзистентна шема, нивното складирање може да биде брзо и лесно, но нивното враќање подоцна може да биде тешко. .
Класична статија " Вреди да се прочита, и карактеристики како во алатката од трета страна Studio 3T, вреди да се користи за редовни проверки на кола.
Не заборавајте за редоследот на сортирање
Заборавањето на редоследот на сортирање може да предизвика повеќе фрустрации и губење повеќе време од која било друга неправилна конфигурација. Стандардно MongoBD користи . Но, тоа е малку веројатно да биде корисно за никого. бинарни сорти чувствителни на букви, чувствителни на акценти се сметаа за љубопитни анахронизми заедно со мониста, кафтани и кадрави мустаќи уште во 80-тите години на минатиот век. Сега нивната употреба е непростлива. Во реалниот живот, "мотоцикл" е ист како "мотоцикл". И „Британија“ и „Британија“ се истото место. Малата буква е едноставно голема еквивалент на голема буква. И не ме терајте со сортирање дијакритици. Кога креирате база на податоци во MongoDB, користете споредување без акцент и , кои одговараат на јазикот и . Ова ќе го олесни пребарувањето низ стринг податоци.
Креирајте колекции со големи документи
MongoDB е среќен да биде домаќин на големи документи до 16MB во колекции, и Дизајниран за големи документи поголеми од 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 Section 5), иако се користи во JavaScript. Покрај тоа, за BSON е застарен и е претворен во $null, што не е секогаш добро решение. .
Користете $limit() без $sort()
Доста често кога се развивате во MongoDB, корисно е само да видите примерок од резултатот што ќе биде вратен од барање или агрегација. За оваа задача ќе ви треба $limit(), но никогаш не треба да биде во конечниот код освен ако претходно не го користите $sort. Овој механичар е неопходен бидејќи во спротивно не можете да го гарантирате редоследот на резултатот и нема да можете веродостојно да ги прегледате податоците. На врвот на резултатот ќе добиете различни записи во зависност од сортирањето. За да работат веродостојно, барањата и агрегациите мора да бидат детерминистички, односно да ги даваат истите резултати секогаш кога ќе се извршат. Код кој содржи $limit(), но не $sort, нема да биде детерминистички и последователно може да предизвика грешки што ќе биде тешко да се пронајдат.
Заклучок
Единствениот начин да се разочарате од MongoDB е да го споредите директно со друг тип на база на податоци, како што е DBMS, или да дојдете до неговата употреба врз основа на одредени очекувања. Тоа е како да споредувате портокал со вилушка. Системите за бази на податоци служат за специфични цели. Најдобро е едноставно да ги разберете и цените самите овие разлики. Би било срамота да се изврши притисок врз програмерите на MongoDB за патека што ги принудила на патеката DBMS. Сакам да видам нови и интересни начини за решавање на старите проблеми, како што се обезбедување интегритет на податоците и создавање системи за податоци кои се отпорни на неуспех и злонамерни напади.
Воведувањето на ACID трансакционалност од MongoDB во верзија 4.0 е добар пример за воведување важни подобрувања на иновативен начин. Трансакциите со повеќе документи и повеќе извештаи сега се атомски. Исто така, можно е да се прилагоди времето потребно за стекнување брави и прекинување на заглавените трансакции, како и промена на нивото на изолација.
Прочитај повеќе:
Извор: www.habr.com