Jakich dużych ograniczeń należy się spodziewać po połączonych serwerach SQL?

Nasz produkt oparty jest na Microsoft SQL Server. Obecnie korzystamy z trzech baz danych i zawsze wdrażaliśmy je w jednym wystąpieniu programu SQL Server.

Trzy bazy danych to OLTP, OLAP i audyt. Baza danych OLAP ma ogromne dane przychodzące na EOD zarówno z OLTP, jak i audytu, przy użyciu zapytań między bazami danych.

pytania

Jeśli mielibyśmy wdrożyć te trzy bazy danych w trzech oddzielnych instancjach Standard Edition na jednym fizycznym serwerze i powiązać je ze sobą za pomocą funkcji Połączonego serwera SQL Server:

1. Jak przejrzysta będzie dla kodu aplikacji? Jakiej zmiany powinienem się spodziewać?
2. Dane przychodzące do OLAP wyniosły 50–100 tys. Wierszy, ładunek 200–500 MB na EOD. Jakiego spadku wydajności należy się spodziewać?
3. Jakich innych dużych ograniczeń należy się spodziewać?

tło

Obecnie udostępniamy nasz potencjalnie pierwszego klienta ponad 500 równoczesnym użytkownikom.

Projektujemy specyfikację serwera, która obejmuje 64 rdzenie i 256 GB pamięci RAM. Aby SQL Server mógł wykorzystać wszystkie te obfite zasoby, klient musiałby kupić Enterprise Edition, która dla SQL Server 2016 jest dostępna tylko w ramach licencji na rdzeń.

Obawiamy się, że sam koszt licencji (64 x 7400 USD) obniży je. Zastanawiam się więc nad podzieleniem bazy danych na trzy instancje edycji standardowej i połączenie ich ze sobą, mając nadzieję, że funkcja powiązania będzie przezroczysta dla kodu aplikacji.

Jak przejrzysta będzie dla kodu aplikacji? Jakiej zmiany powinienem się spodziewać?

W ogóle nieprzejrzyste. Spodziewaj się poważnych zmian.

Powinieneś być przygotowany na bardzo znaczny spadek wydajności.

Zapytanie rozproszone (struktura połączonych serwerów) używa ogólnego modelu OLEDB, niezależnie od tego, jaki jest serwer na drugim końcu. Prawdą jest, że cel programu SQL Server może być w stanie zaoferować pełniejsze informacje (metadane, statystyki itp.), Ale wynik wciąż nie jest tak ściśle zintegrowany lub zdolny jak natywna operacja między bazami danych.

Zdalne zapytania mają zasłużoną reputację ze względu na niską wydajność i zły wybór planu przez optymalizator. Instrukcje, które zmieniają dane (usuwaj, wstawiaj, aktualizuj, scalaj) są szczególnie podatne, ponieważ podstawowym modelem jest często kursor.

Jeśli nigdy nie musisz wykonywać kwerend ad-hoc między instancjami, być może będziesz w stanie ręcznie dostroić każde zapisane zapytanie w celu uzyskania akceptowalnej wydajności, ale jest to dużo pracy i sukces nie jest w żaden sposób gwarantowany.

W przypadku operacji zbiorczych krzyż instancji, można byłoby znacznie lepiej wyłączyć za pomocą operacji prawdziwy luzem ( bcp, BULK INSERT, SSIS ... itd.) Pomiędzy przypadkach niż przy użyciu połączonych serwerów.

To powiedziawszy, podstawowy pomysł wydaje się o wiele większym kłopotem, niż jest dla mnie wart. Określ sprzęt, który będzie działał w ramach ograniczeń wersji standardowej; lub, jeśli klient wymaga wyższej wydajności, zdobądź większy serwer i użyj wersji Enterprise.