Az elmúlt néhány évben webalkalmazásokat építettem a MongoDB köré. Ebben a rövid cikkben szeretnék válaszolni néhány, a fejlesztők többségében felmerülő kérdésre vagy félreértésre, amikor értékeljük:
- Mi az engedélyeztetés?
- Mit jelent a MongoDB egy NoSQL adatbázis?
- Mi van a MongoDB fellépéseivel?
Engedélyezés
Igen, a MongoDB a Free Software Foundation GNU AGPL v3.0 licenc alatt áll . Gyakorlatilag ez azt jelenti, hogy a MongoDB fejlesztéseit el kell engedni a közösségnek. Minden levezetett mű forráskódját is terjeszteni kell.
Kíváncsi lehet, hogy az alkalmazás származtatott-e. Be kell vallanom, hogy soha nem találtam ilyen kifejezés egyszerű meghatározását. A MongoDB konkrét esetben azonban egyszerűen felismerik, hogy az adatbázisukat használó alkalmazások külön munka. Sőt, támogatott illesztőprogramjaikat Apache License v2.0 alatt bocsátják ki. Ez megengedő licenc. Ehhez nem szükséges a forráskód közzététele, és az alkalmazás általában csak illesztőprogram segítségével beszél a MongoDB-vel.
Ennek következtében nem kell foglalkoznia a MongoDB engedélyezésével, hogy köré építse az alkalmazását. Kérdések esetén aláírt leveleket is küldenek az ígéret megerősítéséről a jogi osztályoknak. Kereskedelmi engedélyeket is nyújtanak, ha az aláírt levél nem elég.
Megjegyzés: bár a nagy tapasztalatok miatt megbízhatok ebben az elemzésben, nem vagyok jogász. Az itt bemutatott nézet személyes megértésem és nem hivatalos.NoSQL
Igen, a MongoDB egy NoSQL adatbázis. Ez a szó elég zavaró lehet. Megpróbálom elemezni a leggyakoribb ötleteket, különös tekintettel arra, hogy ez miként vonatkozik a MongoDB-re.
Dokumentumorientált
A hagyományos SQL adatbázisokban az adatokat táblák és sorok formájában rendezik el. Minden sorban rögzített számú oszlop található, amelyek csak meghatározott típusú adatokat képesek tárolni (pl. Egész szám, Szöveg, Időidő). Ez meghatározza az adatok sémáját .
Az MongoDB-ben az adatokat BSON objektumok formájában tárolják, gyűjteményekbe rendezve . Az adatokáltalában JSON objektumok formájában kezelik. Ezáltal az objektumok leképezése az adatbázisba egyszerű feladat, általában kiküszöböli az objektum-relációs leképezéshez hasonlót .
Tranzakciós
A v4 előtt a MongoDB csak dokumentum-szintű tranzakciókat nyújtott. Az írásokat soha nem alkalmazták részlegesen egy beillesztett vagy frissített dokumentumra. A művelet abban az értelemben atomi volt, hogy vagy kudarcot vall, vagy sikerrel jár. A dokumentum teljes egészében azt mondták, hogy a dokumentum szintjén savas. Ennek következtében nem volt lehetőség több dokumentumot átfogó atomváltozásokra. Emulálnia kellett a szükséges adatbázis-tranzakciókat (pl. 2 fázisú lekötés).
A v4 óta a MongoDB támogatja a több dokumentumot tartalmazó ACID tranzakciókat, így ez az egyetlen nyílt forráskódú adatbázis, amely egyesíti a dokumentum modellt az ACID garanciákkal.
Séma nélküli (tényleg?)
Ez azt jelenti, hogy nem kell elmondania az adatbázisnak az adatainak felépítését és a használandó primitív típusokat, mielőtt kezelni tudná azokat. Ez azt is jelenti, hogy különböző struktúrájú dokumentumokat keverhet össze ugyanabban az adatgyűjtésben.
Az egyik nagy előny, hogy a sémamigrációk könnyebbé válnak (az adatbázis kiigazításainak többsége átlátható és automatikus). A visszagörgetés valószínűleg nem okoz problémát. További előny, hogy a meglévő adatmodellek dinamikus kiterjesztése futás közbeni egyedi attribútumokkal egyszerű .
Demindez nem jelenti azt, hogy egyáltalán nincs sémája. Ha nincs kifejezetten deklarálva, akkor implicit módon rávilágít az alkalmazás logikájára. Lehet, hogy más módon deklarálják az űrlap / adatok érvényesítését. Egyébként még mindig kifejezetten meg kell mondania az adatbázisnak, hogyan kell indexeket létrehozni a jó teljesítmény biztosítása érdekében.
Valójában a séma kialakítása a félelmetes adatbázisok készítésének sarokköve, akár SQL, akár nem. Ha nem érti adatait, valamint a hardver és a szoftver korlátait, akkor nem tudja hatékonyan megtervezni a sémát.
Nem relációs (tényleg?)
Ez azt jelenti, hogy az összesített adatstruktúrák kezeléséhez nem kell mindig kapcsolatot létrehozni két dokumentum között.
Valójában a relációs adatbázisokban az SQL JOIN záradék lehetővé teszi két vagy több tábla sorainak kombinálását, közös mező használatával. A dokumentumorientált adatbázisok, például a MongoDB, denormalizált adatok tárolására szolgálnak . Ideális esetben nem lehet kapcsolat a gyűjtemények között: ha ugyanazokra az adatokra van szükség két vagy több dokumentumban, akkor meg kell ismételni. Az egyik nagy előny, hogy egyetlen adatolvasás szükséges az összes adat megszerzéséhez.
De továbbra is létrehozhat kapcsolatokat, és hivatkozhat egy másik dokumentumra, ha szeretné, vagy szüksége van rá:
- azonosító alapján, akkor manuálisan „feltöltheti” egy második lekérdezéssel, vagy a DBRefs használatával
- bármely más mezővel, akkor használhatja az
$lookupoperátort
Ez igazán rugalmasvá teszi a MongoDB-t, és lehetővé teszi, hogy eseti alapon kiválaszthassa, hogyan kezelje az objektumai közötti kapcsolatokat .
Teljesítmény
Ír olvas
Igen, a MongoDB, mint bármely más „igaz” adatbázis, hatalmas mennyiségű adat kezelésére készült. Dióhéjban több száz vagy ezer objektum nem jelent semmilyen adatbázist, így nem kell aggódnia, ha ilyen száma van. Sok referenciaértéket találhat a környéken. Itt van egy egyszerű, amely durva nagyságrendet ad. A tárolt dokumentumok valóban egyszerűek, és jellemzően időbélyeggel ellátott mérést jelentenek:
{ value: random(0,100), timestamp: date}Mivel a MongoDB delegálja a memóriakezelést az operációs rendszerre, a bonyolultabb dokumentumok (amelyek általában több tíz attribútumot tartalmaznak) nem befolyásolja jelentősen az eredményeket
Mindkét attribútum indexelésre került. A MongoDB automatikusan hozzáadja és indexeli a dokumentum egyedi azonosítóját. Három kérést teszteltem:
- az aggregációs keretrendszer segítségével keresse meg a gyűjtemény maximális értékét
- keresse meg a 100 legnagyobb értéket, amely nagyobb, mint 99,9
- egyetlen dokumentumot szerezzen be azonosító szerint
A „maximális kérelem” nem részesül előnyben az indexekből az összesítés miatt, míg a „nagyobb mint” és „azonosító szerint” kérelmek felhasználhatják. Meglátja, hogy ez mennyire fontos a teljesítmény szempontjából.
A tesztkonfiguráció MongoDB 3.4.1 64 bit volt - OS Windows 7 Pro SP1 - CPU Core i7–4712HQ 2,3 GHz - 16Go RAM - SSD HD, és a teszt eredményei a következők voltak:
Tehát, ha a megfelelő indexeket egymilliárd dokumentum lekérdezésével állítja össze, akkor is elég hatékony a legtöbb alkalmazás számára egyetlen kiszolgálón. Ha szükséges, a szilánkosítással növelheti a teljesítményt.
Here are the scripts used to create/query the database for this test:
And the run commands:
// Launch server./mongod --dbpath "C:\Program Files\MongoDB\Server\3.4\data" --port 27018// Insertion exemple for 10e7./mongo --port 27018 --eval "var arg1=10000000" create_collection.js// Requests./mongo --port 27018 --eval "" query_collection.jsMemory
Yes, MongoDB often looks like it uses all available RAM. It actually relies on different storage engines. WiredTiger is the default starting in MongoDB 3.2, and MMAPv1 is the default for MongoDB versions before 3.2. However, they work pretty similarly. Via the file system cache, they automatically use all free memory that is not used by the engine cache or by other processes. And this is coherent if you’d like to have maximum performances.
So system resource monitors often show that MongoDB uses a lot of memory, but its usage is dynamic. If another process suddenly needs half the server’s RAM, MongoDB will yield cached memory to the other process.
As a consequence, the single parameter you can tune to optimize memory usage is the engine cache size. For example, by default, the WiredTiger engine uses 50% of RAM minus 1 GB, which can be pretty large on servers with a lot of memory. This can even cause some trouble if you use containers with limited memory, so simply find out the right balance for your use case.
Conclusion
I hope you know have a more precise idea of the benefits provided by MongoDB if it suits your needs. Recently, MongoDB has started a Database as a Service offer called MongoDB Atlas that might be useful for you to test out.
If you liked this article feel free to have a look at our Open Source solutions, the Kalisio team !