Hybrid-DB-System: NoSQL-Daten, SQL-Code für Beziehungen. Best-Practice?
Ich Baue eine app, deren DB-system wird entscheidend sein, und muss skalierbar sein, da alle seine Wert in den Daten.
Mache ich ein live-voting-system.
Ich bin wohl mit SQL und MongoDB, so ist es fast kein Faktor, der die Entscheidung (obwohl ich eher zu wie MongoDB Struktur und JS mehr, diese Zeiten 🙂 )
Aber von allem, was ich gelesen habe im web, ich fühle mich immer noch unwohl mit meiner Entscheidung.
Was ich will zu tun ist, um vereint die Vorteile von beiden:
- Mit noSQL-Dokumente für Objekte (Benutzer, Artikel, Kommentare etc.)
- Mit SQL-Tabellen für Beziehungen (Tabelle, User-Artikel, User-Kommentare, etc.)
- Duplizieren der Abstimmungsergebnisse in einer noSQL-Dokument, wenn es einer Abstimmung oder in einem regelmäßigen Intervall (to gain speed auch auf Abstimmungsergebnisse anzeigen)
Große Vorteile, die ich sehe sind:
- Beim Abfragen einer Dokument (zB. ein Benutzer auf die Anzeige seines Profils), ich habe alle NoSQL-Vorteile (Geschwindigkeit, die alle in einem Ort, der schema-Flexibilität etc.)
- Wenn dabei die stats (zB. Anzahl der Stimmen), ich habe alle SQL-Vorteile
- Parallelisierbarkeit: kann ich Holen die Abstimmung in SQL und der Dokumente, die im asynchronen Modus
- Schnell Lesen, schreiben slowish (und es spielt keine Rolle, in meinem Fall)
- Beziehung Integrität ist stets erhalten
Meine Fragen sind :
- Ist es eine gute Praxis, dies zu tun ? Das web scheint ziemlich schüchtern es
- Bin ich optimieren Erdnüsse, auch bei hohen DB laden ? (Vergleich-Dokument abrufen, um die vollständige SQL und Abfragen wie select * from table where primary_key = XXX)
- Gute Frage. Ich habe das Spiel mit der gleichen Idee für eine kleine Weile mit verschiedenen NoSQL-Technologien. Vielleicht später beantworten, sobald ich ein wenig Zeit, um wirklich zu schreiben, eine Antwort.
- Wenn verstehe ich das richtig, das Sie verwenden möchten MongoDB wie eine Art cache ? Von dem, was du beschrieben hast, ich glaube nicht, dass es eine schlechte Idee, Sie müssen nur sicherstellen, dass MongoDB ist im Einklang mit Ihrem RDBMS bei den application-layer (Erhöhung der code-Komplexität für die Geschwindigkeit grundsätzlich)
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Wenn der einzige Grund, warum Sie gerne eine NoSQL-Datenbank zusammen mit einem RDBMS zu gewinnen, Geschwindigkeit und Flexibilität, ich würde empfehlen ein caching-server statt (z.B. Memcache). Sie könnten bauen ein Dokument/Ergebnis unter Verwendung von sql-Anweisungen, und speichern Sie es mit einem einzelnen Schlüssel-Wert in memcache für das abrufen später. Seine viel einfacher zu implementieren als beispielsweise MongoDB. Aber es hängt natürlich von Ihren Anforderungen, wenn Sie wirklich nur die Absicht, das zu tun-Dokument-lookups, indem mit einem Schlüssel oder plan verwenden komplexere Abfragen für Ihre Dokumente.
"Best practice" ist ein schrecklicher Begriff - er wird Häufig verwendet, um zu rechtfertigen, Bauchgefühl, "das ist, wie wir es immer getan haben", oder andere Vorurteil.
Jedoch die Lösung, die Sie beschreiben, hat eine Reihe von Vorteilen (Sie nennen), aber auch einige erhebliche Nachteile, vor allem, weil Sie durch die Aufteilung des Problems Domäne zwischen zwei inkompatiblen Daten speichert, und das eröffnet viele Chancen für eine Vervielfältigung, aber auch für die Inkonsistenz.
Beispielsweise das wissen, dass ein bestimmter Benutzer wird identifiziert durch eine bestimmte Kennung geteilt zwischen Ihrer NoSQL-system und Ihre Datenbank. Wenn ein system löscht die Benutzer, die andere ist in einem inkonsistenten Zustand. Einem bestimmten Benutzer Profil unterteilt sich in zwei Systeme, und weder ein vollständiges Bild, man würde Sie brauchen viel Zimmerreinigung Synchronisations-code.
Entwickler auf Ihre Plattform benötigen expertise in Technologie-stacks - haben Sie jemals versucht zu Debuggen, warum ein bestimmter Benutzer die Anzahl der Kommentare scheint falsch zu sein.
Haben Sie nun zwei Punkte des Scheiterns - wenn entweder NoSQL oder SQL-Datenbanken fehlschlagen, wird das gesamte system bricht. Und Fehler kann nicht bedeuten, Absturz - es kann auch bedeuten, performance-Probleme, oder Probleme mit upgrades oder Probleme mit sicherungen.
Es ist nicht ungewöhnlich, dass software-Lösungen für mehrere Systeme haben jeden besitzenden einen Teil der Daten, der split ist in der Regel entlang der business-domain-Linien (das CRM-system weiß Ihrem Profil, der die Zahlung-system-die details Ihrer Kreditkarte, die E-Commerce-system weiß, was Sie bestellt haben); die Aufteilung der Teilung entlang technischen Linien schaffen würde, eine komplexe Architektur mit mehreren points-of-failure.
Ich glaube nicht, dass die Vorteile überwiegen diese Nachteile.
Ich würde wie zu werfen, ein weiterer Vorschlag für die Modellierung von Objekten und Beziehungen, die würde der Maßstab.
Einige Denkanstöße: