A cikk fordítása a tanfolyam kezdetének előestéjén készült .
Főbb jellemzők:
- Rendkívül fontos egy séma fejlesztése, még akkor is, ha a MongoDB-ben opcionális.
- Hasonlóképpen, az indexeknek meg kell egyeznie a sémával és a hozzáférési mintákkal.
- Kerülje a nagy objektumok és nagy tömbök használatát.
- Legyen óvatos a MongoDB beállításaival, különösen, ha a biztonságról és a megbízhatóságról van szó.
- A MongoDB nem rendelkezik lekérdezésoptimalizálóval, ezért óvatosnak kell lennie a lekérdezési műveletek végrehajtása során.
Nagyon régóta dolgozom adatbázisokkal, de csak nemrég fedeztem fel a MongoDB-t. Van néhány dolog, amit bárcsak tudtam volna, mielőtt elkezdtem dolgozni vele. Ha valakinek már van tapasztalata egy bizonyos területen, akkor előzetes elképzelései vannak arról, hogy mi az adatbázis, és mit csinál. Abban a reményben, hogy mások is könnyebben megértsék, bemutatom a gyakori hibák listáját.
MongoDB szerver létrehozása hitelesítés nélkül
Sajnos a MongoDB alapértelmezés szerint hitelesítés nélkül van telepítve. Helyileg elérhető munkaállomások esetében ez a gyakorlat normális. De mivel a MongoDB egy többfelhasználós rendszer, amely szereti a nagy mennyiségű memóriát használni, jobb lesz, ha olyan szerverre helyezi, ahol a lehető legtöbb RAM van, még akkor is, ha csak fejlesztésre használja. A szerverre az alapértelmezett porton keresztül történő telepítés problémás lehet, különösen akkor, ha a kérésben bármilyen javascript kód végrehajtható (pl. $where ötletként ).
Számos hitelesítési módszer létezik, de a legegyszerűbb egy felhasználói azonosító/jelszó beállítása. Használja ezt az ötletet, miközben a képzeletbeli hitelesítésen gondolkodik . Ami a biztonságot illeti, a MongoDB-t folyamatosan frissíteni kell, és a naplókat mindig ellenőrizni kell az illetéktelen hozzáférés szempontjából. Például szeretek másik portot kiválasztani alapértelmezett portként.
Ne felejtse el a támadási felületet a MongoDB-hez kötni
jó tippeket tartalmaz a hálózati behatolás és adatszivárgás kockázatának csökkentésére. Könnyű ecsetelni, és azt mondani, hogy egy fejlesztői szervernek nincs szüksége magas szintű biztonságra. Ez azonban nem ilyen egyszerű, és ez az összes MongoDB-kiszolgálóra vonatkozik. Különösen, ha nincs nyomós ok a használatára , vagy , le kell tiltania a tetszőleges kód használatát a JavaScriptben úgy, hogy beírja a konfigurációs fájlba . Mivel az adatfájlok nincsenek titkosítva a szabványos MongoDB-ben, ésszerű a MongoDB futtatása , amely teljes hozzáféréssel rendelkezik a fájlokhoz, csak korlátozott hozzáféréssel és az operációs rendszer saját fájlhozzáférési vezérlőinek használatával.
Hiba az áramkör fejlesztése közben
A MongoDB nem használ sémát. Ez azonban nem jelenti azt, hogy a rendszerre nincs szükség. Ha csak konzisztens minta nélkül szeretne dokumentumokat tárolni, tárolásuk gyors és egyszerű lehet, de későbbi előhívásuk nehézkes lehet. .
Klasszikus cikk " Érdemes elolvasni, és olyan funkciókkal rendelkezik, mint a harmadik féltől származó Studio 3T eszközben érdemes használni az áramkörök rendszeres ellenőrzésére.
Ne felejtse el a rendezési sorrendet
A rendezési sorrend elfelejtése több frusztrációt és több időt veszíthet, mint bármely más helytelen konfiguráció. Alapértelmezés szerint a MongoBD használja . De nem valószínű, hogy bárki számára hasznos lesz. A kis- és nagybetűket érzékeny, ékezetérzékeny, bináris típusokat a gyöngyökkel, kaftánokkal és göndör bajuszokkal együtt furcsa anakronizmusnak tekintették a múlt század 80-as éveiben. Most már megbocsáthatatlan a használatuk. A való életben a „motorkerékpár” ugyanaz, mint a „motorkerékpár”. És a „Britannia” és a „Nagy-Britannia” ugyanaz a hely. A kisbetű egyszerűen a nagybetű nagybetűs megfelelője. És ne kezdj bele a diakritikus jelek rendezésébe. Amikor adatbázist hoz létre a MongoDB-ben, használjon ékezetmentes leválogatást és , amelyek megfelelnek a nyelvnek és . Ez sokkal könnyebbé teszi a keresést a karakterlánc-adatok között.
Gyűjtemények létrehozása nagy dokumentumokkal
A MongoDB örömmel fogadja a nagyméretű, akár 16 MB-os dokumentumokat gyűjteményekben, és 16 MB-nál nagyobb dokumentumokhoz tervezték. De csak azért, mert nagy dokumentumokat lehet ott elhelyezni, nem jó ötlet ott tárolni őket. A MongoDB akkor működik a legjobban, ha néhány kilobájt méretű egyedi dokumentumokat tárol, és inkább egy széles SQL-tábla soraiként kezeli őket. A nagy dokumentumok problémák forrása lehet .
Dokumentumok készítése nagy tömbökkel
A dokumentumok tömböket tartalmazhatnak. A legjobb, ha a tömb elemeinek száma messze van a négyjegyű számtól. Ha gyakran adunk hozzá elemeket egy tömbhöz, akkor az túlnő az azt tartalmazó dokumentumon, és ennek így is kell lennie , ami azt jelenti, hogy szükség lesz rá . Egy nagy tömböt tartalmazó dokumentum újraindexelésekor az indexek gyakran felülírásra kerülnek, mivel , amely az indexét tárolja. Ez az újraindexelés akkor is megtörténik, amikor egy dokumentumot beillesztenek vagy törölnek.
A MongoDB-nek van valami neve , amely teret ad a dokumentumok növekedésének a probléma minimalizálása érdekében.
Azt gondolhatja, hogy megteheti a tömbindexelés nélkül is. Sajnos az indexek hiánya más problémákat is okozhat. Mivel a dokumentumokat az elejétől a végéig szkenneljük, a tömb végén lévő elemek keresése tovább tart, és az ilyen dokumentumokhoz kapcsolódó legtöbb művelet .
Ne felejtse el, hogy az összesítés szakaszainak sorrendje számít
Egy lekérdezés-optimalizálóval rendelkező adatbázis-rendszerben az Ön által írt lekérdezések magyarázatot adnak arra, hogy mit szeretne elérni, nem pedig azt, hogy hogyan. Ez a mechanizmus az étteremben történő rendeléssel analóg módon működik: általában egyszerűen rendel egy ételt, és nem ad részletes utasításokat a szakácsnak.
A MongoDB-ben te utasítod a szakácsot. Például meg kell győződnie arról, hogy az adatok áthaladnak reduce a lehető legkorábbi használat során $match и $project, és a rendezés csak azután történik reduce, és hogy a keresés pontosan a kívánt sorrendben történjen. Ha van egy lekérdezésoptimalizáló, amely kiküszöböli a felesleges munkát, optimálisan sorrendbe állítja a lépéseket, és kiválasztja az összekapcsolási típusokat, akkor elronthatja Önt. A MongoDB-vel a kényelem árán is nagyobb irányítást élvezhet.
Olyan eszközök, mint leegyszerűsíti az összesítő lekérdezések felépítését . Az Aggregation Editor szolgáltatás lehetővé teszi, hogy egy lépésben alkalmazza a folyamat utasításait, és minden szakaszban megvizsgálja a bemeneti és kimeneti adatokat a hibakeresés egyszerűsítése érdekében.
Gyors rögzítés használata
Soha ne állítsa be a MongoDB írási beállításait nagy sebességre, de alacsony megbízhatóságra. Ez a mód "fájl és felejt" gyorsnak tűnik, mert a parancs az írás előtt visszaadásra kerül. Ha a rendszer összeomlik az adatok lemezre írása előtt, az elveszik, és inkonzisztens állapotba kerül. Szerencsére a 64 bites MongoDB engedélyezte a naplózást.
Az MMAPv1 és a WiredTiger tárolómotorok naplózást használnak ennek megakadályozására, bár a WiredTiger képes helyreállni az utolsó konzisztensig , ha a naplózás le van tiltva.
A naplózás biztosítja, hogy az adatbázis konzisztens állapotban legyen a helyreállítás után, és minden adatot megőrz mindaddig, amíg a naplóba nem írják. A felvételek gyakorisága a paraméter segítségével állítható be .
A bejegyzések biztonsága érdekében győződjön meg arról, hogy a naplózás engedélyezve van a konfigurációs fájlban ), és a felvételek gyakorisága megfelel annak az információmennyiségnek, amelyet megengedhet magának.
Rendezés index nélkül
A keresés és az összesítés során gyakran szükség van az adatok rendezésére. Bízzunk benne, hogy ez az eredmény szűrése után valamelyik végső szakaszban megtörténik, hogy csökkentsük a rendezendő adatok mennyiségét. És még ebben az esetben is szüksége lesz a válogatáshoz . Használhat egyszeres vagy összetett indexet.
Ha nincs megfelelő index, a MongoDB megteszi nélküle. Az összes behelyezett dokumentum teljes méretére vonatkozóan 32 MB memóriakorlát van érvényben , és ha a MongoDB eléri ezt a határt, akkor vagy hibát dob, vagy visszatér .
Keresés index támogatás nélkül
A keresési lekérdezések az SQL JOIN műveletéhez hasonló funkciót hajtanak végre. A legjobb működéshez szükségük van az idegen kulcsként használt kulcs értékének indexére. Ez nem nyilvánvaló, mert a felhasználás nem tükröződik benne explain(). Az ilyen indexek a beírt indexen felül vannak explain(), amelyet viszont a csővezeték-üzemeltetők használnak $match и $sort, amikor a csővezeték elején találkoznak. Az indexek mostantól bármely szakaszt lefedhetnek .
Leiratkozás a több frissítés használatáról
módszer egy meglévő dokumentum egy részének vagy az egész dokumentumnak a módosítására használható, egészen a teljes cseréig, a megadott paramétertől függően . Ami nem annyira nyilvánvaló, hogy nem dolgozza fel a gyűjtemény összes dokumentumát, hacsak nem állítja be ezt a beállítást hogy frissítse az összes olyan dokumentumot, amely megfelel a kérési feltételeknek.
Ne felejtse el a kulcsok sorrendjének fontosságát a hash táblázatban
A JSON-ban egy objektum nulla méretű vagy több név/érték pár rendezetlen gyűjteményéből áll, 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 a keresés során nagy hangsúlyt fektet a sorrendre. A MongoDB-ben a kulcsok sorrendje a beépített objektumokon belül , azaz { firstname: "Phil", surname: "factor" } - ez nem ugyanaz { { surname: "factor", firstname: "Phil" }. Vagyis el kell tárolnia a név/érték párok sorrendjét a dokumentumaiban, ha biztosan meg akarja találni őket.
Ne keverje össze "Nulla" и "határozatlan"
Érték "határozatlan" szerint soha nem volt érvényes JSON-ban JSON (ECMA-404, 5. szakasz), annak ellenére, hogy a JavaScriptben használják. Sőt, a BSON esetében ez elavult, és erre konvertálódik $null, ami nem mindig jó megoldás. .
Használat $limit() nélkül $sort()
Amikor MongoDB-ben fejleszt, gyakran hasznos, ha csak egy mintát lát a lekérdezésből vagy összesítésből visszaadott eredményből. Ehhez a feladathoz szüksége lesz $limit(), de soha nem szerepelhet a végső kódban, hacsak nem használta korábban $sort. Erre a mechanikára azért van szükség, mert különben nem tudja garantálni az eredmény sorrendjét, és nem tudja megbízhatóan megtekinteni az adatokat. Az eredmény tetején a rendezéstől függően különböző bejegyzések jelennek meg. A megbízható működés érdekében a lekérdezéseknek és aggregációknak determinisztikusnak kell lenniük, azaz minden végrehajtáskor ugyanazokat az eredményeket kell produkálniuk. Kód, amely tartalmazza $limit(), de nem $sort, nem lesz determinisztikus, és később olyan hibákat okozhat, amelyeket nehéz lesz nyomon követni.
Következtetés
Csak úgy lehet csalódni a MongoDB-ben, ha közvetlenül összehasonlítjuk egy másik típusú adatbázissal, például egy DBMS-sel, vagy bizonyos elvárások alapján használjuk. Olyan ez, mint a narancsot a villához hasonlítani. Az adatbázis-rendszerek meghatározott célokat szolgálnak. A legjobb, ha egyszerűen megérted és értékeled ezeket a különbségeket. Kár lenne nyomást gyakorolni a MongoDB fejlesztőire egy olyan út miatt, amely a DBMS útjára kényszerítette őket. Szeretnék új és érdekes módszereket látni a régi problémák megoldására, például az adatok integritásának biztosítására, valamint olyan adatrendszerek létrehozására, amelyek ellenállóak a hibákkal és a rosszindulatú támadásokkal szemben.
A MongoDB által a 4.0-s verzióban bevezetett ACID-tranzakció jó példa a fontos fejlesztések innovatív módon történő bevezetésére. A több dokumentumból és több kimutatásból álló tranzakciók ma már atomi. Lehetőség van a zárak megszerzéséhez és a beragadt tranzakciók megszüntetéséhez szükséges idő beállítására, valamint az elkülönítési szint módosítására is.
Olvass tovább:
Forrás: will.com