Dacă călătoriți prin teritoriul indecși MongoDB, este posibil să fi auzit de principiul: În cazul în care aveți nevoie de sortare, apoi adăugați caseta asortat la sfârșitul indicelui, care este utilizat în interogări. În multe cazuri, când interogările conțin condiții de egalitate, cum ar fi principiul potrivit căruia cele de mai sus sunt foarte utile.
Dar ce zici de el poate spune cu următorul exemplu:
Acest pachet nu este eficient, deși principiul este respectat. Pentru că există o capcană în care acest principiu vă poate conduce. Mai jos vom examina motivele defalcării acestei capcane și până la sfârșitul articolului veți avea o nouă regulă care vă va ajuta cu indexarea.
Să ne amintim elementele de bază din documentația MongoDB:
Indicii merită luați în considerare la începutul proiectului. Istoric, eficiența la nivelul accesului la date a fost transferată administratorilor bazei de date, ceea ce a dus la crearea unui strat de optimizare după proiectare. Cu baze de date orientate spre documente, este posibil să evităm acest lucru.
Întrebările indexate funcționează mai bine cu mai multe ordini de mărime, chiar și pe date mici. În timp ce fără un index interogarea poate dura 10 secunde, aceeași interogare poate dura 0 milisecunde cu indicele corespunzător.
Interogările utilizează indicii de la stânga la dreapta. Indexul poate fi utilizat numai dacă interogarea folosește toate câmpurile din index fără omisiuni.
Dacă interogarea conține sortarea, adăugați câmpul sortat în index.
- „Comenzi“
Acum întoarceți-vă la întrebarea noastră. Având la bază indexarea, pentru următoarea interogare:
Ar trebui să creăm un astfel de index:
Ce se întâmplă dacă majoritatea interogărilor din condiție utilizează o selecție a intervalului în locul unei comparații? Ca și în acest caz:
Aici am folosit operatorul $ în operator, dar pe lângă acesta există mai multe cum ar fi: $ gt, $ lt, și altele.
Dacă utilizați această interogare, veți vedea că aceasta nu este eficientă și vă amintiți elementele de bază - trebuie să rulați .explain () și să vedeți ce index este folosit și cum.
Ca rezultat al executării .explain (), veți vedea ce MongoDB înseamnă a face operațiuni de sortare și aceasta este o operație costisitoare. MongoDB sortează documentele în memorie. Prin urmare, trebuie să evitați seturi mari de date. este lentă și intensivă din punct de vedere al resurselor.
Nu uitați de ce scanAndOrder este lent, de ce MongoDB sortează rezultatul chiar dacă avem deja un index cu sortarea? Răspunsul este simplu: nu avem un index adecvat.
De ce? Motivul este simplu, punctul este în structura indexului pe care l-am creat. Pentru exemplul de mai sus, documentele care au și documentele sunt sortate în index, dar sunt sortate independent una de cealaltă. Nu sunt sortate împreună! Luați în considerare diagrama de mai jos:
Diagrama stângă arată ordinea de accesare cu crawlere a documentelor de către indexul pe care l-am creat. După ce toate documentele au fost găsite, acestea vor trebui sortate.
În dreapta, un indice alternativ <“carsOwned”: 1, “country”: 1>. În acest caz, documentele găsite vor fi deja sortate.
Acest punct de eficacitate subtil a condus la următoarele reguli de indexare:
Ordinea câmpurilor ar trebui să fie:
1. În primul rând, câmpurile sunt selectate în funcție de valorile exacte.
2. Alte câmpuri pe care va avea loc sortarea.
3. Și la sfârșitul câmpului pentru filtrul pentru interval.
Există vreun compromis? Da. Interogarea va vizita mai multe noduri index, care este una tehnică. Partea sortată va fi ocolită înainte de filtrare. Astfel, noua regulă ca un beneficiu net pentru multe interogări, dar nu uitați că complexitatea datelor dvs. poate duce la rezultate diferite.
Trimiteți-le prietenilor: