sql >> Database >  >> NoSQL >> MongoDB

Redenen voor en tegen de overstap van SQL-server naar MongoDB

Naar mijn mening moet het formaat van uw gegevens de eerste zorg zijn bij het kiezen van een opslag-backend. Heeft u gegevens die relationeel van aard zijn? Zo ja, kan en is het een goed idee om de data in documenten te modelleren? Gegevensmodellering is net zo belangrijk in een documentendatabase als in een relationele database, het is alleen anders gedaan. Hoeveel soorten objecten heb je en hoe verhouden ze zich? Kunnen DBrefs in Mongodb het lukken of mis je buitenlandse sleutels zo erg dat het pijnlijk zal zijn? Wat zijn uw toegangspatronen voor de gegevens? Haalt u alleen gegevens van één type op, gefilterd op een veldwaarde, of heeft u ingewikkelde ophaalmodi?

Heeft u transactie-integriteit van ACID nodig? Legt het domein veel beperkingen op aan de gegevens? Heb je de schaalbaarheidsfactor van een documentdatabase nodig of is dat gewoon een "cool" ding om te hebben?

Wat zijn uw vereisten voor consistentie en gegevensintegriteit? Sommige NoSQL-oplossingen en in het bijzonder MongoDB zijn vrij los op de schrijfconsistentie om prestaties te krijgen. NoSQL is geen uniform landschap en andere producten, b.v. CouchDB heeft andere kenmerken op deze afdeling. Sommige zijn ook afstembaar.

Dit zijn allemaal vragen die bij de keuze van de opberger aan de orde moeten komen.

Enkele ervaringen

  • Uitgebreide rapportage over de opgeslagen gegevens kan moeilijker zijn bij het gebruik van MongoDB of een documentdatabase en in sommige gevallen is voor dat doel RDBMS en document-db gecombineerd.
  • (Heel) Ander querymodel. MongoDB verschilt ook van andere document-dbs.
  • Flexibel om gegevensindeling/schema te wijzigen tijdens ontwikkeling
  • Onbekend gebied
  • verschillende mate van volwassenheid in drijfveren en kaders
  • Snel
  • Eenvoudiger (in veel opzichten) product- en beheertools (vergeleken met veel RDBMS-producten)
  • Geen impedantie-mismatch meer. De opslag past bij de data, niet andersom.
  • Minder wrijving en meer directe toegang tot data.
  • Domein is meer gebonden aan persistentie (afhankelijk van het ORM-"niveau" van NoRM, hoeveel het de backend wegneemt. Ik heb NoRM niet gebruikt, dus daar kan ik geen antwoord op geven.)


  1. MongoDB index intersectie

  2. Opvragen van ingebedde objecten in Mongoid/rails 3 (lager dan, min-operators en sorteren)

  3. Node redis uitgever verbruikt te veel geheugen

  4. Filter opnieuw op bereik, sorteer en retourneer eerst 10