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?
database-design
deployment
Nick Chammas
źródło
źródło
Odpowiedzi:
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:
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 .
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.
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! :)
źródło