Pokud jste v posledních několika letech vytvořili středně velkou až velkou webovou aplikaci, pravděpodobně jste zvážili její založení na otevřeném zdroji LAMP nebo MEAN. Starší zásobník LAMP používá operační systém Linux, webový server Apache, relační databázi MySQL a programovací jazyk PHP. MEAN používá databázi MongoDB NoSQL, rámec webových aplikací Express back-end, platformu Angular application a běhový modul Java Node.js. MEAN je v podstatě koncový zásobník JavaScriptu. Linux není v akronymu výslovně zmíněn, ale obvykle se jedná o OS pod Node.
V této recenzi budu diskutovat o databázi MongoDB, nyní ve verzi 4. MongoDB je vysoce škálovatelná, operační databáze dostupná ve verzích open source i v komerčních podnicích a lze ji provozovat místně nebo jako spravovanou cloudovou službu. Spravovaná cloudová služba se nazývá MongoDB Atlas.
MongoDB je zdaleka nejoblíbenější databází NoSQL. Jeho datový model dokumentů poskytuje vývojářům velkou flexibilitu, zatímco jeho distribuovaná architektura umožňuje velkou škálovatelnost. Výsledkem je, že MongoDB se často volí pro aplikace, které musí spravovat velké objemy dat, které těží z horizontální škálovatelnosti a které zpracovávají datové struktury, které se nehodí k relačnímu modelu.
Protože MongoDB je vhodný pro širokou škálu případů použití, je často uváděn jako náhrada za relační databáze. Přestože osvobození od přísných omezení schémat je často výhodné, je třeba mít na paměti, že žádná databáze dokumentů není univerzálním řešením - ani MongoDB.
Počátky MongoDB
Společnost, která stojí za MongoDB, byla založena v roce 2007 jako 10gen týmem, který stál za společností DoubleClick, internetovou reklamou. Původní motivací pro databázi MongoDB byla schopnost zvládnout agilitu a rozsah potřebný pro internetovou reklamu. Jako příklad rozsahu DoubleClick v roce 2007 zobrazil 400 000 reklam za sekundu a snažil se dosáhnout výkonu s existujícími databázemi té doby.
MongoDB je obchod založený na dokumentech, který má také implementovaný obchod založený na grafech. Dalšími druhy databází NoSQL jsou úložiště klíčů a sloupců. Všechny druhy databází NoSQL sdílejí schopnost škálovat způsoby, které nebyly možné v relačních databázích SQL z roku 2007, ale různé varianty databází NoSQL mají různé silné a slabé stránky a případy použití.
Mezi hlavní konkurenty NoSQL pro MongoDB jako operační databáze patří Amazon DynamoDB (úložiště klíč-hodnota), Google Cloud BigTable (úložiště sloupců), Google Cloud Datastore (úložiště dokumentů), Redis (v paměti, úložiště klíč-hodnota), Couchbase (multi-model key-value and document store), DataStax / Cassandra (column store), and Azure Cosmos DB (multi-model including a SQL option as well as several NoSQL stores).
Co je MongoDB?
Společnost MongoDB Inc. popisuje MongoDB jako „databázi dokumentů s požadovanou škálovatelností a flexibilitou při dotazování a indexování, které potřebujete.“ Abychom to mohli analyzovat, musíme nejprve pochopit povahu databáze dokumentů, což je jeden z druhů návrhů NoSQL.
Spíše než ukládání silně zadaných dat do souvisejících normalizovaných tabulek s pevnými schématy, jako je relační databáze, ukládá databáze dokumentů související data v de-normalizované formě vložené do dokumentů typu JSON typu název-hodnota. MongoDB ve skutečnosti neukládá JSON: MongoDB ukládá BSON (binární JSON), který rozšiřuje reprezentaci JSON (řetězce) o další typy, jako je int, dlouho, datum, plovoucí bod, desítkové128a geoprostorové souřadnice, jak je znázorněno na následujícím obrázku. Dokumenty BSON obsahují jedno nebo více polí a každé pole obsahuje hodnotu konkrétního datového typu, včetně polí, binárních dat a vnořených dokumentů. BSON také sleduje velikost každého dokumentu, což umožňuje efektivní vyhledávání.
MongoDB Typizace BSON se vkládá do indexování polí. MongoDB může generovat multimodální grafy, geoprostorové indexy, B-stromy a fulltextové indexy na jedné kopii dat, přičemž pomocí typu dat vygeneruje správný typ indexu. MongoDB umožňuje vytvářet indexy v libovolném poli dokumentu.
MongoDB MongoDB má databáze, sbírky (tabulky), dokumenty (řádky), pole (sloupce), indexy, $ vyhledávání nebo vložené dokumenty (spojení), primární klíče, agregační kanál a transakce. Chcete-li dosáhnout lepšího výkonu a vyhnout se potřebě transakcí s více dokumenty, pravděpodobně budete chtít v MongoDB používat vnořené dokumenty a pole, nikoli ukládat data v normalizované podobě, jako byste to dělali v databázi SQL.
MongoDB 4 dělá mít transakce s více dokumenty, což znamená, že stále můžete získat vlastnosti KYSELIN, i když musíte normalizovat návrh dat. Předchozí verze ne.
Za to, co to stojí, mi zástupci MongoDB řekli, že transakce s jedním dokumentem zpracovávají 90 procent případů použití, které vyžadují vlastnosti ACID. Když zákazníci před verzí 4 potřebovali ACID pro transakce s více dokumenty, implementovali jej v zásadě sami na úrovni aplikace.
Ve výchozím nastavení používá MongoDB dynamická schémata, někdy nazývaná bez schémat. Dokumenty v jedné kolekci ano ne musíte mít stejnou sadu polí a datový typ pro pole se může u různých dokumentů v kolekci lišit. Struktury dokumentů můžete kdykoli změnit.
Schéma řízení je však k dispozici. Počínaje MongoDB 3.6 podporuje MongoDB ověření schématu JSON. Chcete-li jej zapnout, použijte $ jsonSchema operátor ve vašem ověřovacím výrazu. Ověření probíhá během aktualizací a vkládání.
Jak můžete vidět na snímku dokumentace a snímku obrazovky MongoDB Atlas níže, MongoDB má svůj vlastní dotazovací jazyk, implementovaný v prostředí Mongo, v 12 podporovaných API ovladačů jazyků (a mnoha dalších z komunity) a v grafickém uživatelském rozhraní Compass a Karta Atlas Collections (Průzkumník dat). Dotazovací jazyk MongoDB není vůbec stejný jako SQL, ale mezi nimi existuje víceméně přímé mapování. Říkám „víceméně“, protože relační databáze nepodporují vložené dokumenty, ale MongoDB ano. To nemusí být nutně Všechno dobře, jak uvidíte v další části.
MongoDB 
MongoDB Agregační rámec MongoDB používá operátory potrubí, které jsou víceméně ekvivalentem SQL SKUPINA VYTVOŘENÁ a KDE doložky. Například následující dotaz používá databázi skupin uživatelů MongoDB k vypsání minulých událostí a celkového počtu RSVP pro každou událost v prostředí Mongo:
> db.past_events.aggregate ([{'$ match': {'batchID': 101, 'event.status': 'past', 'event.group.urlname': {'$ in': ['Atlanta-MongoDB -User-Group ',' Austin-MongoDB-User-Group ',' Baltimore-MongoDB-Users-Group ',' Bangalore-MongoDB-User-Group ',' Belfast-MongoDB-User-Group ',' Bergen-NoSQL ',' Bordeaux-MongoDB-User-Group ',' Boston-MongoDB-User-Group ']}}},{'$ group': {'_id': {'urlname': '$ event.group.urlname', 'year': {'$ year': '$ event.time'}}, 'event_count': {' $ sum ': 1},' rsvp_count ': {' $ sum ':' $ event.yes_rsvp_count '}}},
{'$ project': {'_id': 0, 'group': '$ _id.urlname', 'year': '$ _id.year', 'event_count': 1, 'rsvp_count': 1}}])
Dotaz používá agregát funkce s $ shoda, $ v, $ skupina, $ součet, a $ projekt operátory a vrátí následující:
{"event_count": 2, "rsvp_count": 27, "group": "Boston-MongoDB-User-Group", "year": 2017}{"event_count": 5, "rsvp_count": 94, "group": "Boston-MongoDB-User-Group", "year": 2016}
{"event_count": 5, "rsvp_count": 231, "group": "Boston-MongoDB-User-Group", "year": 2015}
{"event_count": 3, "rsvp_count": 175, "group": "Boston-MongoDB-User-Group", "year": 2014}
{"event_count": 10, "rsvp_count": 489, "group": "Boston-MongoDB-User-Group", "year": 2013}
{"event_count": 12, "rsvp_count": 444, "group": "Boston-MongoDB-User-Group", "rok": 2012}
{"event_count": 2, "rsvp_count": 118, "group": "Boston-MongoDB-User-Group", "rok": 2011}
{"event_count": 6, "rsvp_count": 84, "group": "Atlanta-MongoDB-User-Group", "year": 2011}
{"event_count": 3, "rsvp_count": 74, "group": "Baltimore-MongoDB-Users-Group", "rok": 2012}
{"event_count": 1, "rsvp_count": 5, "group": "Bergen-NoSQL", "year": 2015}
{"event_count": 15, "rsvp_count": 286, "group": "Atlanta-MongoDB-User-Group", "rok": 2012}
{"event_count": 11, "rsvp_count": 321, "group": "Baltimore-MongoDB-Users-Group", "rok": 2013}
{"event_count": 8, "rsvp_count": 124, "group": "Bangalore-MongoDB-User-Group", "year": 2015}
{"event_count": 6, "rsvp_count": 381, "group": "Bangalore-MongoDB-User-Group", "year": 2013}
{"event_count": 7, "rsvp_count": 242, "group": "Bangalore-MongoDB-User-Group", "year": 2012}
{"event_count": 13, "rsvp_count": 233, "group": "Atlanta-MongoDB-User-Group", "year": 2013}
{"event_count": 10, "rsvp_count": 171, "group": "Baltimore-MongoDB-Users-Group", "rok": 2014}
{"event_count": 3, "rsvp_count": 28, "group": "Austin-MongoDB-User-Group", "year": 2017}
{"event_count": 2, "rsvp_count": 52, "group": "Austin-MongoDB-User-Group", "year": 2016}
{"event_count": 1, "rsvp_count": 8, "group": "Atlanta-MongoDB-User-Group", "year": 2018}
Více zadejte „it“
>
MongoDB má také mapReduce funkce. Compass GUI má agregační pipeline builder, který umožňuje vytváření dotazů, jako je ten výše, poměrně jednoduché.
MongoDB podporuje řadu úrovní konzistence dat serveru počínaje číst nezávazně a jdu do kauzální. Příčinná konzistence byla přidána pouze ve verzi 3.6 a je také podporována v relacích klienta. Klient nastaví čtení a zápis obavy k určení požadované úrovně konzistence.
V MongoDB je operace zápisu atomická na úrovni jednoho dokumentu, i když operace upravuje více vložených dokumentů v jednom dokumentu. Při jedné operaci zápisu (např. db.collection.updateMany ()) upravuje více dokumentů, úprava každého dokumentu je atomová, ale operace jako celek není atomová. Počínaje verzí 4.0 pro situace, které vyžadují atomicitu pro aktualizace více dokumentů nebo konzistenci čtení pro více dokumentů, poskytuje MongoDB transakce s více dokumenty pro sady replik za cenu výkonu.
