Plusy / minusy korzystania z wielu baz danych w porównaniu do korzystania z jednej bazy danych

Pracowałem nad nowym projektem, który wymaga użycia 7 baz danych, argumentując, że wydajność, stabilność i optymalizacja są łatwiejsze do wdrożenia.

Chociaż nie zgadzam się, mam problem z gromadzeniem dobrych argumentów do korzystania z jednej bazy danych (dzielenie tabel na domeny logiczne).

Jednym z moich argumentów jest integralność danych (nie mogę używać kluczy obcych między bazami danych).

Jakie są dobre zalety / wady korzystania z jednej lub wielu baz danych?

[podsumowanie do tej pory]

Argumenty przeciwko wielu bazom danych:

• Utrata integralności danych (nie można używać kluczy obcych w bazach danych)

• Utrata integralności przywracania

• Zyskanie złożoności (użytkownicy / role db)

• Mały serwer szans / baza danych ulegnie awarii

Rozwiązania:

• Użyj schematów do oddzielenia domen.

• POC: Użyj fałszywych danych, aby udowodnić punkt w planach wykonania 7/1 db

Żadna wydajność, stabilność, optymalizacja nie są prawdziwe. Czy ktoś ma solidny argument lub artykuł referencyjny, dlaczego są one prawdziwe?

Zasoby nie są przydzielane do bazy danych: wystąpienie programu SQL Server równoważy zasoby, więc nie ma znaczenia

Przegrałeś:

• integralność danych
• przywróć integralność (dane w DB7 będą później niż DB1)

Zyskujesz złożoność:

• bezpieczeństwo (użytkownicy, role itp.) musi znajdować się we wszystkich bazach danych
• będziesz mieć dane, które nie pasują do 1 bazy danych

Opcje:

• dzielenie bazy danych na osobne dyski można wykonać za pomocą aplikacjami
• użyj schematów do logicznego oddzielenia danych (na podstawie innej odpowiedzi)

Jeśli chcesz podzielić dane według domeny logicznej, zawsze możesz skorzystać ze schematów w SQL2008 (odchodząc od domyślnego dbo.), Ale nawet to jest bolesne i może powodować problemy z OR / M, które nie oczekują standardowy schemat.

Byłem w stanie zestawiać dane z więcej niż jednej bazy danych i jest to bolesne i dalekie od wysokiej wydajności. W końcu buforujesz dane lub przynajmniej używasz sztuczek, aby utrzymać szybkość.

W ramach testu zbuduj 7 fałszywych baz danych. Zbuduj zapytanie, które wymaga danych jednocześnie ze wszystkich 7 lub co najmniej sporej ich liczby.

Następnie porównaj plany wykonania! Myślę, że wygrasz swoją sprawę właśnie tam.

Dobrym powodem do utworzenia oddzielnych baz danych byłoby wsparcie różnych wymagań dotyczących dostępności lub uproszczenie administracji. Na przykład, jeśli twoje bazy danych wymagają bardzo różnych harmonogramów tworzenia kopii zapasowych lub różnych modeli odzyskiwania. Innym powodem może być uruchomienie ich w różnych instancjach.

Nie ma dostępnych optymalizacji wydajności z wieloma bazami danych, których nie można osiągnąć przy pomocy jednej bazy danych. Czy możesz podać więcej szczegółów na temat tego, co rozumiesz przez „wydajność, stabilność, optymalizację”?

Eksperyment myślowy: Zamiast dzielić bazę danych na siedem części, zamiast tego podziel ją na 7 000 elementów. Jakie jest prawdopodobieństwo, że awaria sprzętu wpłynie na twoją aplikację? Jeśli istnieje szansa 0,1% na to, że jakiś serwer może umrzeć w danym dniu, czy masz większe lub mniejsze szanse, że wystąpi awaria sprzętu podczas zwiększania liczby maszyn, od których jesteś zależny?

Myślę, że ważne jest podzielenie pojęcia „bazy danych” na dwie części: schemat i dane w porównaniu ze sprzętem używanym do obsługi danych.

Przerwanie bazy danych na wielu komputerach nie przynosi korzyści z wielu powodów wyjaśnionych przez inne odpowiedzi w tym temacie.

Jeśli zamierzasz używać wielu komputerów w celu zapewnienia niezawodności i zwiększonej wydajności, być może możesz je tak ustrukturyzować, aby mieć serwer główny z wieloma urządzeniami rezerwowymi w trybie ciepłym / gorącym, które mogą być również używane do dystrybucji zapytań. W ten sposób, jeśli jakaś maszyna ulegnie awarii, nie stracisz żadnych danych, aw najgorszym przypadku będziesz musiał ponownie uruchomić zapytanie. Oczywiście jest to bardziej skomplikowane, ale obowiązują podstawy.

Zgadzam się z jednym DB i zamiast tego używam opcji pliku i schematu.

Zdarzają się przypadki, w których podział na wiele części ma sens.

Konfiguracja środowiska aplikacji (deweloper, test, prod), takie jak serwery FTP, ścieżki eksportu plików itp., Rzeczy, które chcesz zapisać na serwerze, i nie zostaną zastąpione podczas przywracania.

Również jako sposób na wyizolowanie zmian procedur specyficznych dla klienta.

Są to jednak problemy związane ze wsparciem, a nie wydajnością.