it-swarm-eu.dev

Kdy by někdo použil MongoDB (nebo podobný) přes relační DBMS?

Jsem trochu zmatený o celé věci NoSQL a tak. Kdy byste se rozhodli použít něco jako MongoDB než něco jako Oracle nebo MySQL? Opravdu nerozumím „rozdílu“, pokud jde o použití mezi nimi.

Podle mého chápání databáze typu NoSQL nemají nahradit RDBMS, ale co přesně mají dělat?

138
user6791

CouchDB jsem už dříve použil pro tři domácí zvířata.

  • Systém mikro blogů.
  • Pro uložení informací pro malou poznámku, kterou jsem udělal aplikaci.
  • Univerzální brainstormingová aplikace.

Hlavním důvodem, proč jsem si to vybral před něčím, jako je MSSQL nebo MySQL, je flexibilita, kterou získáte při jeho používání. Žádné pevné schéma. Pokud po třech měsících dolů potřebujete určitý stůl, abyste měli další pole, a to a to, prostě to změníte a zvlní se odtamtud ven.

Použil jsem Beginning CouchDB od Apress, abych se naučil, jak jej používat.

Například CouchDB používá json ke komunikaci do/z databáze. Pokud váš jazyk umí POST= data), můžete jej použít ke komunikaci s DB.

Přečtěte si také: Proč bych měl používat relační databázi místo databáze relací? na StackOverflow

34
Sergio

Je nám líto přidat další odpověď, ale žádná z odpovědí zde není velmi uspokojivá. Tato odpověď je specifická pro MongoDB (na rozdíl od velkého množství dalších možností ukládání dat tam, které nejsou relační databáze).

Pros:

  • MongoDB má nižší latenci na dotaz a tráví méně času CPU na dotaz, protože dělá mnohem méně práce (např. Žádné spojení, transakce). Výsledkem je zvládne vyšší zatížení, pokud jde o dotazy za sekund, a proto se často používá, pokud máte velké množství uživatelů.
  • MongoDB je snazší ostřelování (použití v klastru), protože se nemusí starat o transakce a konzistenci.
  • MongoDB má rychlejší zápisová rychlost, protože se nemusí starat o transakce nebo vrácení peněz (a tak se nemusí starat o uzamčení).
  • MongoDB nemá schéma v případě, že máte speciální případ použití, který jej může využít.

Nevýhody:

  • MongoDB nepodporuje transakce. Takto získá většinu svých výhod.
  • Obecně MongoDB vytváří pro klientský server více práce (např. Vyšší náklady na CPU). Například pro připojení dat je třeba vydat více dotazů a provést připojení na klientovi.
  • I zde v roce 2017 existuje menší podpora nástrojů pro MongoDB než pro relační databáze jednoduše proto, že je novější. Existuje také méně odborníků na MongoDB než jejich relační protějšky.

Body často nepochopené:

  • Indexování podporují jak MongoDB, tak relační databáze. Výkon jejich dotazu je podobný, pokud jde o provádění velkých dotazů.
  • MongoDB neodstraní potřebu migrací nebo konkrétněji, aktualizuje vaše stávající data podle vývoje vašeho schématu. Například: Pokud máte aplikaci, která se spoléhá na tabulku uživatelů, která obsahuje určitá data, a tuto tabulku upravíte tak, aby obsahovala různá data (řekněme, že přidáte pole s profilovým obrázkem), budete stále muset buď:
    • Napiš vám aplikaci pro manipulaci s objekty, pro které je tato vlastnost nedefinovaná NEBO
    • Napište jednorázovou migraci a zadejte výchozí hodnotu pro tuto vlastnost NEBO
    • Napište kód pro poskytnutí výchozí hodnoty v době dotazu, pokud toto pole není k dispozici NEBO
    • S chybějícím polem zacházejte jiným způsobem
26
Pace

Nestydatě ukrást z Renesis (vlastně dělám tuto odpověď CW):


Používání RDBMS namísto jiných typů:

13
Matthew Read

Pokud vaše data nejsou relační, může mít použití databází NoSQL velké výhody, jako je výkon a škálovatelnost (samozřejmě v závislosti na okolnostech). Některá vzorování, jako je CQRS, usnadňují využití nes relačních dat v oblastech, které by obvykle vyžadovaly výhradní použití databáze SQL.

Pro data v mezipaměti je běžné používat databáze jako mongo. Například, pokud potřebujete vygenerovat sestavu, můžete udělat komplikovaný dotaz SQL, který spojuje a agreguje spoustu dat za běhu, nebo můžete jednoduše načíst jeden dokument json z vaší mongo databáze, který již obsahuje vše, co potřebujete pro vygenerování hlášení. Díky tomu je čtení dat opravdu snadné (a rychlé!), Ale může to značně komplikovat zápis dat (zde přichází CQRS).

9
Graeme Hill

Databáze jako MongoDB jsou skvělé, když obvykle víte, kde jsou vaše data (na rozdíl od potřeby psát několik komplikovaných dotazů). U Mongo jsou „související“ data buď vnořena do nadřazených dat, nebo mají primární/cizí klíče. To je skvělé, pokud máte například příspěvky a komentáře; obecně nebudete zobrazovat komentáře mimo kontext příspěvku, takže má smysl, aby komentáře byly obsaženy v příspěvku (tímto způsobem získáte všechny komentáře k příspěvku, aniž byste museli hledat samostatnou tabulku).

MongoDB je schemaless. To znamená, že z větší části vezme jakoukoli strukturu dat, která na něj hodíte.

Na druhou stranu, pokud potřebujete používat agregované funkce a cítíte potřebu dotazovat data složitými způsoby, kterých nelze dosáhnout vložením nebo jednoduchými vztahy v Mongo, pak víte, že je čas použít RDBMS jako MySQL nebo PostgreSQL.

MongoDB nemá nahradit SQL. Jednoduše splňuje různé potřeby a MongoDB a RDBMS lze použít ve spojení. Podle mého názoru MongoDB není vše, co potřebujete, pokud nepotřebujete, aby vaše data byla flexibilní nebo vložena do nadřazeného dokumentu. Vývoj s MongoDB je velmi zábavný, protože je mnohem méně kroků zapojených do zprovoznění projektu (řekněme v Rails). Potřebujete provést změnu? Žádný problém. Stačí přidat atribut do svého modelu. Hotovo.

Nemohu mluvit o mnoha dalších databázích NoSQL, i když vím, že jsou obvykle navrženy tak, aby splňovaly konkrétní potřeby, které RDBMS nemůže splnit. Někteří bydlí zcela v paměti nebo jsou schopni snadno ostříhat nebo upravovat měřítko. Jsem si docela jistý, že Cassandra je navržen tak, aby pokračoval v práci bez ztráty dat, pokud uzel klesne. Redis je v podstatě úložiště klíčových hodnot, které je uloženo v paměti (s periodickým zápisem disků pro vytrvalost), ale také má schopnost ukládat datové typy jako sady a třídit je.

8
Ravenstine

Hlavní výhra je, když chcete stříhat data nebo mít více master databází. V MySQL můžete stříhat data, ale to se stává velkou bolestí. Pokud děláte hodně zápisů, je často užitečné shardovat data na více serverech, problém je v tom, že pokud chcete mít silnou referenční konzistenci, může to být velmi obtížné, ne-li nemožné, vyhledat teorém CAP.

SQL databáze mají velmi dobrou konzistenci, ale opravdu špatnou podporu pro vytváření oddílů, databáze NoSQL mají tendenci jít opačným směrem. Snadné rozdělení, ale často to, co se nazývá eventuální konzistence. Pokud stavíte web pro zasílání zpráv, který je v pořádku, pro banku pravděpodobně není v pořádku.

Výhodou je, že nyní existuje více modelů, jak ukládat data, takže existuje možnost, jak implementovat věci, zatímco dříve jste měli jen databáze SQL.

SE Radio má na toto téma několik dobrých epizod.

6
Zachary K

MongoDB funguje dobře, když píšete hodně dat, a když vaše dotazy nejsou příliš komplikované. Proto MongoDB je vhodný, když implementujete CQRS s Event Sourcing na straně Command - tj. Váš obchod s událostmi je MongoDB databáze.

Na straně dotazování stále používáme SQL Server db s pohledy a WCF Data Services nahoře, kvůli jeho flexibilitě. Myslím, že ve většině případů budete opravdu potřebovat sílu relační DB pro dotazování.

1
Roy Dictus

Základním datovým modelem je okamžitý a zásadní rozdíl mezi MongoDB a RDBMS. Relační databáze strukturuje data do tabulek a řádků, zatímco MongoDB strukturuje data do sbírek dokumentů JSON. JSON je samopopisující, lidsky čitelný datový formát. Původně navržený pro lehké výměny mezi prohlížečem a serverem, je široce přijímán pro mnoho typů aplikací.

Dokumenty JSON jsou zvláště užitečné pro správu dat z několika důvodů. Dokument JSON se skládá ze sady polí, které jsou samy páry párů klíč-hodnota. To znamená, že každý dokument JSON s sebou nese svůj vlastní čitelný design schématu, ať už jde kdekoli, což umožňuje dokumentům snadno se pohybovat mezi databázovými a klientskými aplikacemi, aniž by ztratily smysl.

JSON je také přirozený formát dat pro použití v aplikační vrstvě. JSON podporuje bohatší a flexibilnější strukturu dat než tabulky složené ze sloupců a řádků. Kromě podporujících typů polí, jako je číslo, řetězec, booleovský atd., Mohou být pole JSON pole nebo vnořené dílčí objekty. To znamená, že můžeme reprezentovat řadu sofistikovaných vztahů, které jsou bližším znázorněním objektů, se kterými naše aplikace pracují. Použití dokumentů JSON v naší databázi znamená, že nepotřebujeme objektový relační mapovač mezi naší databází a aplikacemi, které obsluhuje. Můžeme zachovat naše data ve správné formě

1
Diwakar upadhyay

Pokud vaše data vyžadují hodně dotazování, pak řešení NoSQL není dobré a když potřebujete transakční podporu (ACID), pak NoSql není nejlepší. Myslím, že NoSQL svítí, když máte spoustu čtení, které musí být rychlé a když je struktura poněkud adhoc, načte se dokumentem nebo strukturou stránky, něco takového. Ale mnoho řešení NoSQL se zlepšuje velmi rychle, takže nedostatky možná brzy budou pryč. Každopádně si myslím, že relační databáze jsou stále vhodné pro většinu aplikací.

1
marko