sql >> Databáze >  >> NoSQL >> MongoDB

Používáte MongoDB vs MySQL se spoustou polí JSON?

Takže, abych přímo odpověděl na otázky...

Bezschémové úložiště je jistě přesvědčivým důvodem, proč jít s MongoDB, ale jak jste zdůraznili, je poměrně snadné uložit JSON také do RDBMS. Síla MongoDB je v bohatých dotazech na úložiště bez schématu.

Pokud bych mohl poukázat na malou chybu v ilustraci o aktualizaci pole JSON, není to jen otázka získání aktuální hodnoty, aktualizace dokumentu a jeho vložení zpět do databáze. Celý proces musí být zabalen do transakce. Transakce bývají poměrně jednoduché, dokud nezačnete denormalizovat svou databázi. Pak něco tak jednoduchého, jako je zaznamenání hlasu pro, může uzamknout tabulky v celém vašem schématu.

S MongoDB neprobíhají žádné transakce. Ale operace mohou být téměř vždy strukturovány způsobem, který umožňuje atomické aktualizace. To obvykle zahrnuje určité dramatické posuny od paradigmat SQL, ale podle mého názoru jsou docela zřejmé, jakmile se přestanete snažit vnutit objekty do tabulek. Přinejmenším spousta dalších lidí se setkala se stejnými problémy, kterým budete čelit, a komunita Mongo bývá poměrně otevřená a hlasitá ohledně výzev, které překonali.

Předpokládám, že "bezpečným zápisem" máte na mysli možnost zapnout automatické "getLastError()" po každém zápisu. Máme velmi tenký obal nad DBCollection, který nám umožňuje jemně zrnitou kontrolu nad voláním getLastError(). Naše zásady však nevycházejí z toho, jak „důležitá“ data jsou, ale spíše z toho, zda kód následující za dotazem očekává, že při následujících čteních budou okamžitě viditelné nějaké úpravy.

Obecně řečeno, toto je stále špatný indikátor a místo toho jsme migrovali na findAndModify() pro stejné chování. V případě, kdy stále explicitně voláme getLastError(), je to tehdy, když databáze pravděpodobně odmítne zápis, jako když vložíme() s _id, které může být duplikát.

Obávám se, že nemohu mluvit o tom, zda jsou naše zásady zálohování/obnovy účinné, protože jsme ještě obnovení nemuseli. Řídíme se doporučeními MongoDB pro zálohování; @mark-hillick odvedl skvělou práci při jejich shrnutí. Používáme sady replik a migrovali jsme verze MongoDB a také jsme zavedli nové členy replik. Doposud jsme neměli žádné prostoje, takže si nejsem jistý, jestli mohu k tomuto bodu dobře mluvit.

Takže podle mých zkušeností MongoDB nabízí ukládání dat bez schématu se sadou dotazovacích primitiv dostatečně bohatých na to, aby transakce mohly být často nahrazeny atomickými operacemi. Bylo těžké odnaučit se 10+ let zkušeností s SQL, ale každý problém, se kterým jsem se setkal, byl vyřešen přímo komunitou nebo 10gen. Neztratili jsme data ani neměli žádné výpadky, které si pamatuji.

Jednoduše řečeno, MongoDB je nejlepší ekosystém pro ukládání dat, jaký jsem kdy použil, pokud jde o dotazy, údržbu, škálovatelnost a spolehlivost. Pokud bych neměl aplikaci, která by byla tak jasně relační, že bych nemohl s čistým svědomím používat nic jiného než SQL, vynaložil bych veškeré úsilí na použití MongoDB.

Nepracuji pro 10gen, ale jsem velmi vděčný za lidi, kteří to dělají.



  1. Laravel a redis scan

  2. Jednoduchý prefixový dotaz Mongodb s regulárním výrazem a řazením je pomalý

  3. Přineste si své vlastní účty Azure – Hosting pro MongoDB® &Redis™ na ScaleGrid

  4. mongoose nemůže naplnit pomocí typu String