Projektowanie platformy: jedna baza danych czy wiele baz danych?

31

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?

Nick Chammas
źródło
co ostatecznie wybrałeś?
Frank Visaggio
@BobSinclar - To już dawno, ale skończyło się na wielu bazach danych.
Nick Chammas
Czy zmiany schematu są trudniejsze czy nie? Powiedzmy, że musiałeś zaktualizować schemat każdej bazy danych.
Frank Visaggio
@BobSinclar - Nie jestem tym, o co pytasz. Kiedy trzeba zaktualizować schemat każdej bazy danych na raz, jeśli platforma została zbudowana zgodnie z zasadami SOA? Różne systemy powinny być luźno połączone.
Nick Chammas
Wiem, że minęło trochę czasu, ale czy masz coś przeciwko udostępnieniu różnych baz danych, które wybrałeś i dlaczego?
azngunit81,

Odpowiedzi:

18

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! :)

Mark Storey-Smith
źródło
Dobra uwaga dotycząca rozwiązań rozproszonej pamięci podręcznej. Jednak w przypadku buforowania na poziomie sieci SAN lub bazy danych nie stanowi to problemu. Nie czerpiesz korzyści z buforowania dzięki topologii wdrażania (tzn. Różne usługi korzystają z tego samego sprzętu), a nie bezpośredniej komunikacji między usługami, jak w przypadku pamięci memcached.
Nick Chammas