Budujemy platformę internetową, która zawiera wiele usług, każda z własnymi danymi bazowymi. Usługi te są budowane niezależnie zgodnie z zasadami architektury zorientowanej na usługi , ale transakcje dotyczą potencjalnie powiązanych danych. Zastanawiamy się, czy te usługi powinny mieć jedną dużą bazę danych, czy każda z nich ma własną bazę danych. (Planujemy używać SQL Server 2008 Enterprise w klastrze Windows 2008).

Niektóre zalety każdego podejścia, które już rozważaliśmy, obejmują:

Jedna baza danych

• Powiązanie danych z różnych usług może być powiązane ograniczeniami klucza obcego
• Ekstrakty analityczne są łatwiejsze do napisania i szybsze do wykonania
• W przypadku katastrofy przywracanie platformy do spójnego stanu jest łatwiejsze
• W przypadku danych, do których odwołuje się wiele usług, dane buforowane przez jedną usługę prawdopodobnie wkrótce zostaną wykorzystane przez inną usługę
• Administracja i monitorowanie są z góry prostsze i tańsze

Wiele baz danych

• Prace konserwacyjne, problemy ze sprzętem, naruszenia bezpieczeństwa itp. Niekoniecznie wpływają na całą platformę
• Zakładając, że każda baza danych jest na osobnym sprzęcie, skalowanie wielu komputerów daje większe korzyści wydajnościowe niż skalowanie jednego dużego

Z perspektywy operacyjnej, czy bardziej korzystne jest to, że każda usługa na tej platformie ma własną bazę danych, czy wszystkie znajdują się w tej samej bazie danych? Jakie kluczowe czynniki decydują o odpowiedzi na to pytanie?

Moim zdaniem kluczowym wyróżnikiem prawdziwych systemów SOA (w stosunku do pseudo SOA, ntier / systemów rozproszonych, które stają się wszechobecne) jest brak interakcji między usługami dyskretnymi. Jeśli zostanie to osiągnięte, każda aplikacja tworzona z tych usług może i powinna być zbudowana tak, aby tolerować awarię dowolnej spójnej części. Awaria zmniejsza funkcjonalność, ale usługa jest utrzymywana.

W tym scenariuszu jest logiczne lub wymagane oddzielenie bazowej bazy danych dla każdej usługi. Jeśli jednak masz usługi, które są od siebie zależne, nie ma (być może nic) korzyści z podziału.

Polecam lekturę witryn takich jak HighScalability.com, które zagłębiają się w architektury przyjęte przez witryny typu „nigdy nie zawiodłem”. Jednym z moich ulubionych ostatnio była historia Netflix Chaos Monkey, o której wspominano w Coding Horror .

Odnosząc się do kilku punktów w twoim pytaniu:

W przypadku katastrofy przywracanie platformy do spójnego stanu jest łatwiejsze.

To prawda, ale być może powinieneś pomyśleć o tym, jak lepiej oddzielić te usługi, aby przestało to być problemem. Alternatywnie istnieją metody zapewniające synchronizację między wieloma bazami danych, na przykład znaki transakcji w SQL Server .

W przypadku danych, do których odwołuje się wiele usług, dane buforowane przez jedną usługę prawdopodobnie wkrótce zostaną wykorzystane przez inną usługę.

Rozwiązania rozproszonej pamięci podręcznej (memcached i in.) Mogą tu pomóc, ale naruszasz zasady niezależności usług. Byłoby to porównywalne z posiadaniem dwóch usług komunikujących się ze sobą bezpośrednio, lub, co gorsza, posiadaniem usługi dostępu do innego magazynu danych, z pominięciem interfejsu usługi. Nieuchronnie dane będą powiązane i będą przekazywane między usługami przez platformę wywołującą, trudne decyzje zwykle dotyczą tego, która usługa będzie właścicielem, które części danych. Witryny StackOverflow lub programistów mogą być lepiej przygotowane do pomocy w bardziej ogólnych problemach z SOA.

Zakładając, że każda baza danych jest na osobnym sprzęcie, skalowanie w górę zapewnia więcej korzyści w zakresie wydajności.

Z pewnością skalowanie na wielu maszynach o niższej specyfikacji może być tańsze niż skalowanie na jednym komputerze. Chociaż niższe koszty sprzętu mogą być drastyczne w stosunku do całkowitego kosztu posiadania, gdy uwzględni się miękkie koszty dodatkowego wysiłku rozwojowego i złożoności operacyjnej.

Jeśli nie jest to SOA, a masz po prostu przypadek, w którym usługi składowe tej platformy są budowane przez różne zespoły / dostawców ze względów logistycznych, trzymaj się jednej bazy danych i całkowicie ignoruj ​​wszystko powyżej! :)