Eine Plattform entwerfen: eine Datenbank oder mehrere Datenbanken?
Wir bauen eine Webplattform auf, die mehrere Dienste mit jeweils eigenen zugrunde liegenden Daten umfasst. Diese Dienste werden unabhängig nach den Prinzipien von Service-Oriented Architecture erstellt, sie handeln jedoch mit potenziell verwandten Daten. Wir überlegen, ob diese Dienste eine große Datenbank gemeinsam nutzen sollen oder ob jede eine eigene Datenbank hat. (Wir planen, SQL Server 2008 Enterprise in einem Windows 2008-Cluster zu verwenden.)
Einige der Vorteile für jeden Ansatz, den wir bereits in Betracht gezogen haben, sind:
Einzelne Datenbank
- Das Verknüpfen von Daten aus verschiedenen Diensten kann durch Fremdschlüsseleinschränkungen miteinander verbunden sein
- Analytische Extrakte sind einfacher zu schreiben und schneller auszuführen
- Im Katastrophenfall ist es einfacher, die Plattform in einem konsistenten Zustand wiederherzustellen
- Bei Daten, auf die von mehreren Diensten verwiesen wird, werden Daten, die von einem Dienst zwischengespeichert werden, wahrscheinlich bald darauf von einem anderen Dienst verwendet
- Verwaltung und Überwachung sind im Vorfeld einfacher und kostengünstiger
Mehrere Datenbanken
- Wartungsarbeiten, Hardwareprobleme, Sicherheitsverletzungen usw. wirken sich nicht unbedingt auf die gesamte Plattform aus
- Angenommen, jede Datenbank befindet sich auf einer separaten Hardware, bietet das Skalieren mehrerer Computer mehr Leistungsvorteile als das Skalieren eines großen Computers
Ist es aus betrieblicher Sicht vorteilhafter, dass jeder Dienst auf dieser Plattform eine eigene Datenbank erhält oder dass alle in derselben Datenbank gespeichert sind? Welche Schlüsselfaktoren bestimmen eine Antwort auf diese Frage?
Meiner Meinung nach ist das Hauptunterscheidungsmerkmal von true SOA -Systemen (über die Pseudo-SOA, ntier/verteilte Systeme, die allgegenwärtig werden), dass es keine Interaktion zwischen diskreten Diensten geben sollte. Wo dies erreicht wird Jede Anwendung, die Sie aus diesen Diensten zusammenstellen, kann und sollte so erstellt werden, dass der Ausfall eines konsistenten Teils toleriert wird. Ein Fehler verringert die Funktionalität, der Dienst bleibt jedoch erhalten.
In diesem Szenario ist es logisch oder erforderlich, die zugrunde liegende Datenbank für jeden Dienst zu trennen. Wenn Sie jedoch Dienste haben, die voneinander abhängig sind, kann aus einer Aufteilung wenig (vielleicht nichts) gewonnen werden.
Ich würde empfehlen, Websites wie HighScalability.com zu lesen, die sich mit den Architekturen befassen, die von Websites vom Typ Never-Fail übernommen wurden. Einer meiner Favoriten in letzter Zeit war die Geschichte von Netflix Chaos Monkey , die auf Coding Horror erwähnt wurde.
Ansprechen einiger Punkte in Ihrer Frage:
Im Katastrophenfall ist es einfacher, die Plattform in einem konsistenten Zustand wiederherzustellen.
Dies ist wahr, aber Sie sollten vielleicht darüber nachdenken, wie Sie diese Dienste besser entkoppeln können, damit dies kein Problem mehr darstellt. Alternativ gibt es Methoden, um die Synchronisation über mehrere Datenbanken hinweg sicherzustellen, z. B. Transaktionsmarken in SQL Server .
Bei Daten, auf die von mehreren Diensten verwiesen wird, werden Daten, die von einem Dienst zwischengespeichert werden, wahrscheinlich bald darauf von einem anderen Dienst verwendet.
Verteilte Cache-Lösungen (memcached et al.) Könnten hier helfen, aber Sie würden die Prinzipien der Dienstunabhängigkeit verletzen. Dies wäre vergleichbar mit zwei Diensten, die direkt miteinander kommunizieren, oder schlimmer noch mit einem Dienstzugriff auf einen anderen Datenspeicher, bei dem die Dienstschnittstelle insgesamt umgangen wird. Zwangsläufig werden Daten in Beziehung gesetzt und von der anrufenden Plattform zwischen den Diensten weitergegeben. Die schwierigen Entscheidungen betreffen in der Regel, welcher Dienst welche Daten besitzt. StackOverflow- oder Programmierer-Sites sind möglicherweise besser geeignet, um bei allgemeineren Problemen zu helfen SOA).
Angenommen, jede Datenbank befindet sich auf einer separaten Hardware, bietet die Skalierung mehr Leistungsvorteile.
Sicherlich kann es billiger sein, auf mehrere Maschinen mit niedrigeren Spezifikationen zu skalieren, als auf eine einzelne Maschine zu skalieren. Die niedrigeren Hardwarekosten können jedoch in den Gesamtbetriebskosten in den Schatten gestellt werden, wenn die weichen Kosten für zusätzlichen Entwicklungsaufwand und die betriebliche Komplexität berücksichtigt werden.
Wenn dies nicht SOA] ist und Sie nur einen Fall haben, in dem die Komponentendienste dieser Plattform aus logistischen Gründen von verschiedenen Teams/Lieferanten erstellt werden, bleiben Sie bei einer einzigen Datenbank und ignorieren Sie alles oben Genannte vollständig ! :)