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

Question

Ich weiß, dass dies eine große Frage ist und es keine Ja- oder Nein-Antwort gibt, aber wir entwickeln Webanwendungen und sind dabei, MongoDB für unsere Persistenzlösung zu verwenden. Die Kombination von MongoDB mit NoRM für die Objektspeicherung.

Was ich fragen möchte, ist, welche Fallstricke haben Sie mit dem Wechsel von SQL zu Mongo erlebt? Wann ist Mongo einfach nicht die richtige Lösung und sind die Vorteile von Mongodb ausreichend, um die Entwicklung von SQL zu verlagern?

Answer 1

Meiner Meinung nach sollte das Format Ihrer Daten bei der Auswahl eines Speicher-Backends im Vordergrund stehen. Haben Sie Daten, die relationaler Natur sind? Wenn ja, ist es möglich und sinnvoll, die Daten in Dokumenten zu modellieren? Die Datenmodellierung ist in einer Dokumentendatenbank genauso wichtig wie in einer relationalen Datenbank, sie wird nur anders durchgeführt. Wie viele Objekttypen gibt es und wie sind sie miteinander verbunden? Können DBrefs in Mongodb die Aufgabe erfüllen oder werden Sie Fremdschlüssel so sehr vermissen, dass es schmerzhaft wird? Wie sehen Ihre Zugriffsmuster für die Daten aus? Holen Sie nur Daten eines Typs, gefiltert nach einem Feldwert, oder haben Sie komplizierte Abrufmodi?

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

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

Dies sind alles Fragen, die bei der Wahl des Speichers eine Rolle spielen sollten.

Einige Erlebnisse

• Die Erstellung umfangreicher Berichte über die gespeicherten Daten kann bei der Verwendung von MongoDB oder einer anderen Dokumentendatenbank schwieriger sein, und in einigen Anwendungsfällen wurden RDBMS und Dokumentendatenbanken zu diesem Zweck kombiniert.
• (Sehr) anderes Abfragemodell. MongoDB unterscheidet sich auch von anderen Dokumenten-Datenbanken.
• Flexible Änderung des Datenformats/Schemas während der Entwicklung
• Unbekanntes Gebiet
• unterschiedlicher Reifegrad der Treiber und Rahmenbedingungen
• Schnell
• Einfachere (in vielerlei Hinsicht) Produkt- und Verwaltungswerkzeuge (im Vergleich zu vielen RDBMS-Produkten)
• Keine Impedanzfehlanpassung mehr. Die Speicherung passt sich den Daten an, nicht umgekehrt.
• Weniger Reibungsverluste und direkterer Zugang zu Daten.
• Domäne mehr an Persistenz gebunden (je nach ORM-"Ebene" von NoRM, je nachdem, wie sehr es das Backend abstrahiert. Ich habe NoRM nicht verwendet, daher kann ich das nicht beantworten).

Answer 2

Nachteile

1. (das Fehlen / die unterschiedliche Sichtweise auf) Haltbarkeit (lesen http://www.mikealrogers.com/2010/07/mongodb-performance-durability )
2. Keine Transaktionen
3. Keine Zwänge
4. Die Aggregation mit MapReduce ist langsam und Sie müssen Code für etwas wie Group-by schreiben
5. Die Berichterstellung ist schwieriger, da der Entwickler die Beziehungen definiert, aber Geschäftsanalysten können keine eigenen Abfragen erstellen, sie können z. B. kein 'Minus' ('except' im SQL-Server-Jargon) machen.

Profis

1. Sie können leicht neue "Spalten" und "Tabellen" hinzufügen
2. Geschwindigkeit
3. Sharding (noch Beta)
4. ein Dokument entspricht eher einem Objekt als eine Reihe von relationalen Tabellen, so dass die Zuordnung einfacher wird
5. Es erweitert den Geist

Answer 3

Dies ist ein schnelles Diagramm, das ich erstellt habe, um die Geschwindigkeit der Aktualisierung mehrerer "Tabellenzeilen" (nicht-hierarchisches flaches Dokument in MongoDB) mit und ohne Index zu vergleichen, um uns eine Vorstellung davon zu geben, wie es für unsere Anwendung skalieren würde.

Answer 4

Ich habe jetzt ein paar Tage damit herumgespielt. Das ist, was ich darüber sagen kann:

FOR:

• Keine SQL-Anweisungen mehr
• Ihre Datenbank ähnelt Ihren Klassen, nicht umgekehrt.
• Ihr "Schema" ist flexibler
• Gut skaliert
• Sehr einfacher Einstieg in die Arbeit
• < Meinung>Es ist cool< / Meinung>

GEGEN:

• Ich bin derzeit versuchen, eine benutzerdefinierte Mitgliedschaft Provider und Role Provider für meine Mongo-App zu implementieren, aber irgendwie meine MemberShip-Benutzerklasse hat NULL-Felder, wenn ich versuche, es von Mongo abrufen.
• Irgendwo habe ich über den C#-Treiber gelesen, dass er relativ jung ist, sich aber stabilisiert, so dass einige Änderungen zu erwarten sind. (Obwohl dies würde mich nicht zurückhalten)

Eine Sache, die mir aufgefallen ist, fehlt in den Tutorials: Initialisiere deine Listen innerhalb deines Objekts, sonst gibt es einen Fehler beim Versuch, .save(yourobj) zu speichern. Am sichersten ist es, einen Konstruktor in deine Klasse zu schreiben, der sicherstellt, dass du keine NULL-Objekte innerhalb deines Objekts hast. Auf diese Weise erhalten Sie keine Fehlermeldung, wenn Sie etwas vergessen.

Answer 5

Einige Vor- und Nachteile der Verwendung einer NoSQL-Datenbank (einschließlich MongoDB) finden Sie in diesem Erste Schritte mit NoSQL . Eine kurze Zusammenfassung wäre: ein anderes Datenmodell (denken Sie daran, ob ein Mapping vom Objektmodell auf "dieses neue Modell" erforderlich ist, wird es gut funktionieren), ein anderes Abfragemodell (MongoDB-Abfragen sind jedoch im Vergleich zu anderen ziemlich leistungsfähig), keine Transaktionen (Sie haben jedoch einige atomare Operationen).

Wie auch immer, aus meiner Sicht ist die wichtigste Änderung das Datenmodell und die Art und Weise, wie Sie Ihre Anwendung mit diesem neuen Ansatz gestalten.