A cikk fordítása a kurzus megkezdése előtt készült .
Főbb pontok:
- Nagyon fontos, hogy készítsünk sémát, bár a MongoDB-ben ez nem kötelező.
- Hasonlóképpen, az indexeknek is a sémához és a hozzáférési mintákhoz kell illeszkedniük.
- Kerüljük a nagy objektumok és tömbök használatát.
- Legyünk óvatosak a MongoDB beállításaival, különösen a biztonság és megbízhatóság szempontjából.
- A MongoDB-ben nincs lekérdezés-optimalizáló, ezért óvatosnak kell lennünk a lekérdezési műveletek végrehajtásakor.
Két évtizede dolgozom adatbázisokkal, de csak nemrég ismertem meg a MongoDB-t. Van néhány dolog, amit jó lett volna tudni, mielőtt elkezdtem foglalkozni vele. Amikor valakinek van tapasztalata egy adott területen, hajlamosak vagyunk előítéletekkel viszonyulni az adatbázisokhoz és azok működéséhez. Azért, hogy másoknak megkönnyítsem a megértést, összeállítottam egy gyakori hibák listáját.
MongoDB szerver létrehozása hitelesítés nélkül
Sajnálatos módon a MongoDB alapértelmezés szerint hitelesítés nélkül települ. Egy olyan munkaállomás esetén, amelyhez helyben férnek hozzá, ez a gyakorlat normális. De mivel a MongoDB egy többfelhasználós rendszer, amely nagy mennyiségű memóriát igényel, jobb, ha a szerverre a lehető legnagyobb memória kerül, még akkor is, ha csak fejlesztés céljára szánjuk. Az alapértelmezett portra történő telepítés problémás lehet, különösen, ha a lekérdezés során bárminemű JavaScript kódot végrehajthatunk (például, $where ötletként ).
Több hitelesítési módszer létezik, de a legegyszerűbb, ha egy felhasználónak ID/jelszót állítunk be. Használjuk ezt az ötletet, míg nem gondolkodunk az összetettebb hitelesítésen, mint a . Ha a biztonságról van szó, akkor a MongoDB-t folyamatosan frissíteni kell, és a naplókat mindig be kell nézni az illetéktelen hozzáférés nyomaira. Például engem mindig vonz más port használni az alapértelmezett helyett.
Ne felejtsd el összekapcsolni a támadási felületet a MongoDB-vel
jó tanácsokat tartalmaz a hálózati behatolás és az adatvesztés kockázatának csökkentésére. Könnyen el lehet hessegetni, és azt mondani, hogy a fejlesztési szervernek nincs szüksége magas szintű biztonságra. Azonban a helyzet nem ilyen egyszerű, és ez minden MongoDB szerverre vonatkozik. Különösen, ha nincs meggyőző oka a használatának. , vagy , ki kell kapcsolni a JavaScript szabad kód használatát a konfigurációs fájlban történő bejegyzéssel. . Mivel a standard MongoDB adatfájljai nincsenek titkosítva, érdemes a MongoDB-t a következőkkel futtatni: , amelynek teljes hozzáférése van a fájlokhoz, korlátozott hozzáféréssel csak a számára, és a lehetőséggel, hogy saját fájlhozzáférés-vezérlő eszközeit használhassa az operációs rendszeren.
Hiba a séma megtervezésében
A MongoDB nem használ sémát. De ez nem jelenti azt, hogy a séma felesleges. Ha csak egyszerűen dokumentumokat szeretne tárolni bármiféle egységes séma nélkül, azokat gyorsan és egyszerűen lehet tárolni, de később előhívni azokat .
A klasszikus "6 empirikus szabály a MongoDB sémák tervezéséhez" Schema Explorer Ne felejtsd el a rendezési sorrendet!
A rendezési sorrend figyelmen kívül hagyása a legnagyobb csalódást okozhatja, és több időt veszthet, mint bármilyen más hibás konfiguráció használata esetén. Alapértelmezés szerint a MongoDB
binaris rendezést a kis- és nagybetűktől független rendezési beállításokat, nyelvének és kultúrájának. Így jelentősen megkönnyíti a szöveges adatok keresését. . Так вы значительно упростите поиск по строковым данным.
Создание коллекций с большими документами
A MongoDB örömmel támogatja a 16 MB-ot elérő nagy dokumentumok tárolását a kollekciókban, és a nagyobb, 16 MB-nál nagyobb dokumentumok számára készült. De még ha nagy dokumentumokat is tárolhatunk ott, a tárolásuk nem a legjobb ötlet. A MongoDB a legjobban úgy működik, ha több kilobytes méretű egyedi dokumentumokat tárolunk, amelyeket inkább széles SQL-táblák sorainak tekintünk. A nagy dokumentumok problémákat fognak okozni .
Nagy tömbökkel rendelkező dokumentumok létrehozása
A dokumentumok tartalmazhatnak tömböket. A legjobb, ha a tömb elemeinek száma messze elmarad a négyszámjegyű értéktől. Ha az elemekhez gyakran adnak hozzá, a tömb meghaladja a tartalmazó dokumentumot, és azt kell, ami azt jelenti, hogy . A nagy tömbű dokumentum újraindexelésekor az indexek gyakran felülíródnak, mivel minden elemhez tartozik egy , amely az indexét tárolja. Ez az újraindexelés akkor is megtörténik, amikor a dokumentumot beillesztik vagy eltávolítják.
A MongoDB-ben van egy úgynevezett , amely helyet biztosít a dokumentumok növekedésére, hogy minimalizálja ezt a problémát.
Gondolhatja, hogy meg lehet oldani a tömbök indexelése nélkül. Sajnos, az indexek hiánya más problémákhoz vezethet. Mivel a dokumentumokat elejétől a végéig nézik át, a tömb végén lévő elemek keresése több időt fog igénybe venni, és a dokumentumokkal kapcsolatos legtöbb művelet .
Ne feledje, hogy az aggregálás fázisainak sorrendje fontos
Az optimalizálóval rendelkező adatbázisban az Ön által írt lekérdezések a kívánt kimenet magyarázatai, nem pedig a megszerzésének módja. A mechanizmus hasonlóan működik, mint egy étteremben való rendelés: általában csak ételeket rendel, nem ad részletes utasításokat a szakácsnak.
A MongoDB-ben Ön instruálja a szakácsot. Például győződjön meg arról, hogy az adatok a lehető legkorábban áthaladnak a reduce $match és és $projectsegítségével, és a rendezés csak később történik. reduce, és hogy a keresés pontosan abban a sorrendben történik, ahogyan szüksége van rá. Egy lekérdezésoptimalizáló megléte, amely megszabadítja a felesleges munkától, optimálisan rendezi a lépéseket és választja ki a kapcsolat típusát, elkényeztetheti Önt. A MongoDB-ben több kontrollal rendelkezik az egyszerűség áráért.
Az olyan eszközök, mint megkönnyítik az aggregációs lekérdezések létrehozását a . Az Aggregációs Szerkesztő funkció lehetővé teszi, hogy lépésről lépésre alkalmazza a csőoperátorokat, valamint ellenőrizze a bemeneti és kimeneti adatokat minden lépésnél a könnyebb hibakeresés érdekében.
A gyors írás használata
Soha ne állítsa be a MongoDB-ben a gyors írási beállításokat, amelyek gyorsak, de alacsony megbízhatóságúak. Ez a mód „file-and-forget” gyorsnak tűnik, mivel a parancs visszatér, mielőtt a felvétel megtörténik. Ha a rendszer összeomlik, mielőtt az adatok felkerülnének a lemezre, elvesznek, és inkonzisztens állapotba kerülnek. Szerencsére a 64 bites MongoDB-ben be van kapcsolva a naplózás.
A MMAPv1 és a WiredTiger tárolómotorok naplózást használnak ennek megelőzésére, bár a WiredTiger vissza tud állni az utolsó konzisztens , ha a naplózás ki van kapcsolva.
A naplózás biztosítja, hogy az adatbázis konzisztens állapotban legyen a helyreállítás után, és minden adatot tárol, amíg az naplózásra kerül. A bejegyzések gyakorisága konfigurálható a .
Annak érdekében, hogy biztos legyen a bejegyzésekben, győződjön meg róla, hogy a konfigurációs fájlban a naplózás be van kapcsolva ), és a bejegyzések gyakorisága megfelel annak a mennyiségű információnak, amelyet el tud engedni.
Rendezés index nélkül
Keresés és aggregálás során gyakran felmerül a szükség a adatok rendezésére. Reméljük, hogy ezt az utolsó lépések egyikeként végzik, miután a találati eredményeket szűrték a rendezendő adatok mennyiségének csökkentése érdekében. Még ilyen esetben is szüksége lesz a rendezéshez . Használhat egyedi vagy összetett indexet.
Ha nem áll rendelkezésre megfelelő index, a MongoDB anélkül is működni fog. Van egy 32 MB-os memóriahatár az összes dokumentum összesített méretére a , és ha a MongoDB elérte ezt a határt, akkor vagy hibát ad vissza, vagy visszaad .
index nélküli keresés
A keresési lekérdezések funkciója analóg az SQL JOIN műveletével. Jobb működés érdekében szükségük van a kulcsérték-indexre, amelyet külső kulcsként használnak. Ez nem nyilvánvaló, mivel a használat nem tükröződik a explain(). Az ilyen indexek kiegészítik az indexet, amely a explain(), és amelyet az aggregációs pipeline operátorai használnak és és $sort, amikor az a pipeline elején találkozik. Az indexek most bármely szakaszt lefedhetnek .
A több frissítés használatának elhagyása
Módszer a meglévő dokumentum egy részének vagy az egész dokumentumnak a módosítására szolgál, a megadott paramétertől függően teljes cserére is lehetőség van . Nem így nyilvánvaló, hogy nem dolgozza fel az összes dokumentumot a gyűjteményben, amíg nem állítja be a paramétert az összes olyan dokumentum frissítésére, amely megfelel a lekérdezés kritériumainak.
Ne feledje a kulcsok sorrendjének fontosságát a hash-táblában
A JSON objektum egy rendezetlen kollekcióból áll, amely nulla vagy annál több név/érték párt tartalmaz, ahol a név egy karakterlánc, az érték pedig egy karakterlánc, szám, logikai érték, nulla, objektum vagy tömb.
Sajnos a BSON nagy jelentőséget tulajdonít a sorrendnek a keresések során. A MongoDB-ben a beágyazott objektumok kulcsainak sorrendje , azaz { firstname: "Phil", surname: "factor" } nem ugyanaz, mint { { surname: "factor", firstname: "Phil" }. Tehát meg kell őriznie a dokumentumokban a név/érték párok sorrendjét, ha biztos akar lenni abban, hogy megtalálja őket.
Ne keverje össze a null és undefined
Value undefined soha nem volt érvényes a JSON-ban a JSON (ECMA-404, 5. szakasz), annak ellenére, hogy a JavaScript-ben használják. Ezenkívül a BSON számára elavult, és átalakításra kerül $null, ami nem mindig jó megoldás. .
Használat $limit() nélkül $sort()
Nagyon gyakran, amikor a MongoDB-n belül fejlesztést végez, hasznos egyszerűen látni az eredménymintát, amely vissza fog jönni a lekérdezésből vagy aggregálásból. Ezen feladat elvégzéséhez hasznos lesz $limit(), de soha nem kellene a kód végső verziójában lennie, hacsak előtte nem használ egyet. $sort. Ez a mechanika szükséges, mivel különben nem garantálhatja az eredmények sorrendjét, és nem tud megbízhatóan adatokat megtekinteni. Az eredmények tetején különböző bejegyzéseket kap, a rendezéstől függően. A megbízható működéshez a lekérdezéseknek és aggregációknak determináltnak kell lenniük, azaz minden végrehajtáskor ugyanazokat az eredményeket kell adniuk. A kódban, amelyben van $limit(), de nincs $sort, nem lesz determinált, és ennek következményeként nehezen észlelhető hibákat okozhat.
Zárás
Az egyetlen módja, hogy csalódjon a MongoDB-ben, ha közvetlenül más típusú adatbázisokkal, mint például a relációs adatbázisokkal hasonlítja össze, vagy bizonyos elvárások alapján közelít a használatához. Olyan ez, mintha egy narancsot egy villával hasonlítana össze. Az adatbázis rendszerek bizonyos célokat szolgálnak. A legjobb, ha egyszerűen megérti és értékeli ezeket a különbségeket. Kár lenne nyomást gyakorolni a MongoDB fejlesztőire a relációs adatbázisok irányába kényszerítő út miatt. Szeretném látni az új és izgalmas módszereket a régi problémák megoldására, mint például az adatintegritás biztosítása és a hibákkal és rosszindulatú támadásokkal szemben ellenálló adatkezelő rendszerek létrehozása.
A MongoDB 4.0 verziójában bevezetett ACID tranzakciós támogatás jó példa arra, hogy fontos fejlesztéseket innovatív módon vezetnek be. Mostantól a többdokumentumos és többoperátoros tranzakciók atomikusak. Lehetőség nyílik a zárak megszerzéséhez szükséges idő szabályozására, az akadozó tranzakciók lezárására és az izolációs szint módosítására is.
Tovább olvasva:
Forrás: habr.com
