Wir bauen eine Webplattform auf, die mehrere Dienste mit jeweils eigenen zugrunde liegenden Daten umfasst. Diese Dienste werden unabhängig nach den Prinzipien der serviceorientierten Architektur erstellt , sie werden jedoch mit potenziell verwandten Daten abgewickelt. Wir überlegen, ob diese Dienste eine große Datenbank gemeinsam nutzen sollen oder jede über eine eigene Datenbank verfügt. (Wir planen die Verwendung von SQL Server 2008 Enterprise in einem Windows 2008-Cluster.)

Zu den Vorteilen jedes Ansatzes, den wir bereits in Betracht gezogen haben, gehören:

Einzelne Datenbank

• Das Verknüpfen von Daten aus verschiedenen Diensten kann durch Fremdschlüsseleinschränkungen miteinander verbunden werden
• Analytische Extrakte sind einfacher zu schreiben und schneller auszuführen
• Im Katastrophenfall ist es einfacher, die Plattform in einen konsistenten Zustand zu versetzen
• Bei Daten, auf die von mehreren Diensten verwiesen wird, werden die von einem Dienst zwischengespeicherten Daten wahrscheinlich bald darauf von einem anderen Dienst verwendet
• Verwaltung und Überwachung sind im Vorfeld einfacher und kostengünstiger

Mehrere Datenbanken

• Wartungsarbeiten, Hardwareprobleme, Sicherheitslücken usw. wirken sich nicht unbedingt auf die gesamte Plattform aus
• Unter der Annahme, dass sich jede Datenbank auf einer separaten Hardware befindet, bietet das Skalieren mehrerer Computer mehr Leistungsvorteile als das Skalieren eines großen Computers

Ist es aus betrieblicher Sicht vorteilhafter, wenn jeder Dienst auf dieser Plattform eine eigene Datenbank erhält oder alle in derselben Datenbank gespeichert sind? Welche Schlüsselfaktoren bestimmen eine Antwort auf diese Frage?

Meiner Meinung nach ist das Hauptunterscheidungsmerkmal echter SOA-Systeme (gegenüber den immer häufiger vorkommenden Pseudo-SOA-Systemen / verteilten Systemen), dass zwischen diskreten Diensten keine Interaktion stattfinden sollte. Wenn dies erreicht wird, kann und sollte jede Anwendung, die Sie aus diesen Diensten erstellen, so erstellt werden, dass sie den Ausfall eines konsistenten Teils toleriert. Ein Fehler verringert die Funktionalität, der Service 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, können Sie aus einer Aufteilung wenig (möglicherweise nichts) ziehen.

Ich würde empfehlen, Websites wie HighScalability.com zu lesen, die sich mit den Architekturen befassen, die von Websites des Typs Never -Fail übernommen wurden. Einer meiner Favoriten in letzter Zeit war die Geschichte des Netflix Chaos Monkey, die in Coding Horror erwähnt wurde .

Ansprechen einiger Punkte in Ihrer Frage:

Im Katastrophenfall ist es einfacher, die Plattform in einen konsistenten Zustand zu versetzen.

Dies ist richtig, aber Sie sollten sich vielleicht überlegen, wie Sie diese Dienste besser entkoppeln können, damit dies kein Problem darstellt. Alternativ gibt es Methoden, um die Synchronisation über mehrere Datenbanken hinweg sicherzustellen, beispielsweise Transaktionsmarken in SQL Server .

Bei Daten, auf die von mehreren Diensten verwiesen wird, werden von einem Dienst zwischengespeicherte Daten wahrscheinlich bald darauf von einem anderen Dienst verwendet.

Verteilte Cache-Lösungen (memcached et al.) Könnten hier Abhilfe schaffen, aber Sie würden die Prinzipien der Dienstunabhängigkeit verletzen. Dies wäre vergleichbar mit der direkten Kommunikation zwischen zwei Diensten oder, schlimmer noch, mit einem Dienstzugriff auf einen anderen Datenspeicher, der die Dienstschnittstelle insgesamt umgeht. Unweigerlich werden Daten in Beziehung gesetzt und von der aufrufenden Plattform zwischen den Diensten ausgetauscht. Die kniffligen Entscheidungen betreffen in der Regel, welcher Dienst welche Daten besitzt. StackOverflow- oder Programmierer-Sites sind möglicherweise besser in der Lage, bei allgemeinen SOA-Problemen zu helfen.

Unter der Annahme, dass sich jede Datenbank auf einer separaten Hardware befindet, bietet die Skalierung weitere Leistungsvorteile.

Sicherlich kann es billiger sein, mehrere Maschinen mit niedrigeren Spezifikationen zu skalieren, als eine einzelne Maschine zu skalieren. Die niedrigeren Hardwarekosten können jedoch in den Gesamtbetriebskosten in den Schatten gestellt werden, wenn die weichen Kosten des zusätzlichen Entwicklungsaufwands und der Betriebskomplexitä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! :)