MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Gründe für und gegen den Wechsel von SQL Server zu MongoDB

Meiner Meinung nach sollte das Format Ihrer Daten das Hauptanliegen bei der Auswahl eines Speicher-Backends sein. Haben Sie Daten, die relationaler Natur sind? Wenn ja, kann und ist es sinnvoll, die Daten in Dokumenten zu modellieren? Datenmodellierung ist in einer Dokumentendatenbank genauso wichtig wie in einer relationalen Datenbank, es wird nur anders gemacht. Wie viele Arten von Objekten haben Sie und wie hängen sie zusammen? Können DBrefs in Mongodb den Trick machen oder werden Sie Fremdschlüssel so sehr vermissen, dass es schmerzhaft sein wird? Wie sehen Ihre Zugriffsmuster auf die Daten aus? Rufen Sie nur Daten eines Typs ab, der durch einen Feldwert gefiltert wird, oder haben Sie komplizierte Abrufmodi?

Benötigen Sie ACID-Transaktionsintegrität? Erzwingt die Domäne viele Einschränkungen für die Daten? Benötigen Sie den Skalierbarkeitsfaktor einer Dokumentendatenbank oder ist das nur eine "coole" Sache?

Was sind Ihre Anforderungen an Konsistenz und Datenintegrität? Einige NoSQL-Lösungen und insbesondere MongoDB sind ziemlich locker bei der Schreibkonsistenz, um Leistung zu erzielen. NoSQL ist keine einheitliche Landschaft und andere Produkte, z.B. CouchDB hat in diesem Bereich andere Eigenschaften. Einige sind auch abstimmbar.

All dies sind Fragen, die bei der Wahl des Speichers berücksichtigt werden sollten.

Einige Erfahrungen

  • Umfassende Berichte zu den gespeicherten Daten zu erstellen, kann schwieriger sein, wenn MongoDB oder eine andere Dokumentendatenbank verwendet wird, und einige Anwendungsfälle haben zu diesem Zweck RDBMS und document-db kombiniert.
  • (Sehr) Unterschiedliches Abfragemodell. MongoDB unterscheidet sich auch von anderen Dokumentendatenbanken.
  • Flexibel, Datenformat/Schema während der Entwicklung zu ändern
  • Unbekanntes Gebiet
  • unterschiedlicher Reifegrad der Treiber und Frameworks
  • Schnell
  • In vielerlei Hinsicht einfachere Produkt- und Verwaltungstools (im Vergleich zu vielen RDBMS-Produkten)
  • Keine Impedanzfehlanpassung mehr. Der Speicher passt zu den Daten, nicht umgekehrt.
  • Weniger Reibung und direkterer Zugriff auf Daten.
  • Domäne stärker an Persistenz gebunden (abhängig vom ORM-"Level" von NoRM, davon, wie sehr es das Backend abstrahiert. Ich habe NoRM nicht verwendet, daher kann ich das nicht beantworten.)