Dlaczego mimo wszystko warto wybrać edycję Enterprise? – część 1

Zgodnie z obietnicą postanowiłem przyjrzeć się nieco dokładniej dlaczego po wprowadzonych w edycji Standard, wraz z Service Packiem 1 do  SQL Server 2016 zmian, mimo wszystko warto nadal skupiać swoją uwagę na edycji Enterprise. Chciałbym też postawić sprawę jasno, osobiście uważam, że obecnie w wielu przypadkach edycja Standard może być bardzo dobrym wyborem i zupełnie nie ma potrzeby sięgania pod edycję wyższą, jednak pomimo tak dużych zmian, za edycją enterprise przemawiają silne argumenty dla konkretnych scenariuszy.

Na początku rzut oka na funkcjonalności, które zagościły w SQL Server jeszcze w poprzednich wersjach, a dopiero teraz trafiły do edycji Standard, a także co więcej, faktycznie nie różnią się pomiędzy edycjami. Pierwszą z takich funkcjonalności są migawki (snapshot) baz danych. Migawki to funkcjonalność, która pozwala na uchwycenie stanu bazy danych, bez konieczności wykonywania pełnej jej kopii. Mechanizm migawek dość dobrze sprawdza się w sytuacji, gdy potrzebny jest stan bazy danych z określonej godziny lub dnia, np. w celach raportowych, lub potrzebna jest możliwość szybkiego powrotu do stanu bazy z określonego momentu w czasie – odtworzenie bazy z migawki. Warto podkreślić, że w przypadku migawek edycja Standard i Enterprise oferują obecnie dokładnie ten sam poziom funkcjonalności.

Kolejny obszar rozszerzony w edycji Standard to partycjonowanie. Dla tych, którzy nie pamiętają, jeszcze za czasów SQL Server 2005/2008/2008R2, ilość partycji ograniczona była do 1000 (co wbrew pozorom wcale nie jest zbyt dużą ilością). Począwszy od wersji 2012, aż do teraz obsługiwane jest 15 000 partycji. Tutaj dość miłe zaskoczenie, również edycja Standard obsługuje taką ilość partycji. Należy jednak pamiętać, że stosowanie dużej ilości partycji to spore zapotrzebowanie na pamięć operacyjną, dlatego też należy ograniczać ich liczbę, w przypadku systemów o ilości pamięci mniejszej niż 16 GB (W tym miejscu jedynie uwaga – partycjonowanie dostępne jest również w edycji Express, która jak zapewne pamiętasz obsługuje tylko 1 GB RAMu, Standard to co prawda max 128 GB RAMu, ale warto pamiętać, o tym magicznym poziomie 16 GB w kontekście partycjonowania, bo jakże często edycja Standard działa w środowisku o zbliżonej ilości pamięci)

We recommend that you use at least 16 GB of RAM if a large number of partitions are in use. If the system does not have enough memory, Data Manipulation Language (DML) statements, Data Definition Language (DDL) statements and other operations can fail due to insufficient memory. Systems with 16 GB of RAM that run many memory-intensive processes may run out of memory on operations that run on a large number of partitions. Therefore, the more memory you have over 16 GB, the less likely you are to encounter performance and memory issues.

Źródło: https://msdn.microsoft.com/en-us/library/ms190787.aspx

Trzecią z funkcjonalności, która w mojej ocenie jest bardzo istotna, to możliwość wykorzystania kompresji. O kompresji na poziomie wierszy i stron nie trzeba się zbyt dużo rozpisywać, ale fakt, że w edycji standard można posługiwać się teraz również funkcją COMPRESS, to na prawdę ukryty skarb, wart uwagi.

No cóż trzy przytoczone funkcjonalności, w trzech obecna edycja Standard raczej nie odbiega funkcjonalnie od Enterprise. Zobaczmy zatem co dalej.

W tym miejscu czas przejść do funkcjonalności, które są obecnie najbardziej pożądanym elementem baz danych, czyli tabele zoptymalizowane do przetwarzania w pamięci (In-memory OLTP) oraz indeksy kolumnowe (columnstore indexes). Oczywiście obie funkcjonalności dostępne w edycji Standard, z tym, że tym razem obie dostępne z gwiazdką. Gwiazdka w przypadku in-memory OLTP oznacza ograniczenie, do 25% zasobów pamięci dla obszaru bufora danych, co w rzeczywistości  maksymalnie zapewnia  możliwość wykorzystania poniżej 32 GB. Dla funkcjonalności indeksów kolumnowych, obowiązuje dokładnie taki sam limit wykorzystania pamięci oraz dodatkowo wykorzystanie maksymalnie dwóch rdzeni (MAXDOP=2). Tym samym jest to jedno z ograniczeń, które zapewne na początku nie spowoduje zbyt wielu komplikacji, warto jednak pamiętać, że apetyt rośnie wraz z użyciem, niektórych funkcjonalności i jeśli nie od razu, to po pewnym czasie, właśnie te ograniczenia skutecznie uniemożliwią skalowalność systemu i jego efektywne wykorzystanie. W tym miejscu zadaj sobie proszę pytanie, czy faktycznie przy zastosowaniu indeksów kolumnowych, zakładamy, że ich użycie będzie tak znikome, że wystarczą  raptem 2 rdzenie do ich obsługi. Nawet jeśli uważasz, że te ograniczenia Cię nie dotyczą – warto zostawić sobie otwartą drogę do migracji do edycji Enterprise, jeśli zaszłaby taka potrzeba (o drodze migracji nieco więcej w drugiej części artykułu).

Na zakończenie pierwszej części artykułu zostawiłem funkcjonalność, która odmieniła samą wersję 2016 w momencie jej premiery, Wcześniej znana wyłącznie z edycji PDW, czyli Parallel Data Warehouse. Chodzi tutaj oczywiście o Polybase i możliwość dostępu do danych na serwerach Hadoop. O samym Polybase można dowiedzieć się więcej m.in. z jednego z przygotowanych przeze mnie nagrań, dostępnych na Channel9. Na potrzeby tego artykułu, kluczową informacją jest to, że Polybase ma zapewniać skalowalną architekturę dla obsługi zapytań pomiędzy SQL Server, a hadoop, poprzez budowę grup skalowalności i dołączenie kolejnych węzłów obliczeniowych,co dość dobrze obrazuje poniższa ilustracja:

polybase.png

Tymczasem w przypadku edycji Standard, przetwarzanie realizowane jest bez możliwości skalowania zapytań w obrębie grupy, co w efekcie zmniejsza potencjalną wydajność rozwiązania. Biorąc pod uwagę, że Polybase raczej nie jest uwzględniany w scenariuszach zakładających pracę z kilkoma tysiącami pojedynczych rekordów po stronie serwera Hadoop – zdecydowanie są setki milionów. W przypadku tego typu zapytań, chodzi głównie właśnie o wydajność, której w edycji standard po prostu może zabraknąć. A fakt, że rolę węzła głównego (head node), może pełnić wyłącznie edycja Enterprise, skutecznie uniemożliwia skalowanie architektury, opartej wyłącznie o węzły działające w oparciu o edycję Standard.

 

O czym w kolejnej części? Trochę o Analysis Services, budowaniu rozwiązań wysokiej dostępności i związanych z tym niedogodności w edycji Standard oraz jakże istotnym bezpieczeństwie danych. Już teraz zapraszam…

3 Replies to “Dlaczego mimo wszystko warto wybrać edycję Enterprise? – część 1”

Comments are closed.