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

Przed Tobą druga część publikacji poświęcona bliższej analizie różnic pomiędzy edycją Standard oraz Enterprise. Po lekturze pierwszej części publikacji, może wstępnie rysować się obraz jedynie niewielkich różnić pomiędzy edycjami, analizujmy zatem dalej.

Alwayson Availability Groups – to jedna z funkcjonalności o największym stopniu zróżnicowania w sposobie działania pomiędzy edycjami. Koncepcja grup dostępności wprowadzona została w wersji 2012 i sukcesywnie rozwijała się, aż do obecnej postaci. Obecna wersja silnika baz danych oferuje m.in możliwości tworzenia klastrów AG pomiędzy serwerami w ramach grup roboczych(wcześniej wymagane było dołączenie serwerów do domeny), bardzo wydajny przepływ danych pomiędzy węzłami i odtwarzania transakcji na zapasowych replikach (głównie dzięki wydajnej kompresji strumienia danych oraz wielowątkowej operacji REDO), a także dystrybuowane grupy dostępności, które pozwalają zoptymalizować budowę rozproszonych środowisk i osiągnąć poziom 16 replik danych.

Jednym z założeń budowy AlwaysOn AG jest możliwość zbudowania grup, stanowiących element przenaszalny pomiędzy węzłami klastra. Elementem pojedynczej grupy może być kilka baz danych, które w przypadku awarii przenoszone są na awaryjny serwer jako „całość”. Tymczasem funkcjonalność wprowadzona w edycji standard (Basic AG), to możliwość budowy grupy dostępności, której elementem jest dokładnie jedna baza danych.(TYLKO JEDNA!). Dodatkowo w przypadku grup dostępności edycji enterprise istnieje możliwość uruchomienia do 8 replik (w tym 3 synchronicznych), które mogę działać w trybie odczytu  danych (readable replica). Funkcjonalność edycji standard, to wyłącznie 2 repliki ( główna i zapasowa) oraz brak możliwości uruchomienia repliki zapasowej w trybie odczytu danych.

Drugim z elementów w znaczący  sposób różnicującym edycje, jest silnik Analysis Services. Co prawda edycja standard otrzymała w wersji 2016 możliwość uruchomienia silnika Analysis Services zarówno w trybie wielowymiarowym (multidimensional) oraz tabelarycznym (tabular), to oba modele ograniczone są limitem wielkości:

  • Tabular: 16 GB
  • MOLAP: 64 GB

W tym miejscu nie mogę powstrzymać się przed komentarzem – baza OLAP o rozmiarze 64 GB, to ok 1/10, a może nawet 1/20 najmniejszej kostki(a nie bazy), z którymi pracowałem w ostatnich projektach (rozwijane i utrzymywane przez mój zespół kostki miały średni rozmiar ok. 1 TB). Podobnie zresztą sytuacja miała miejsce w przypadku modeli tabelarycznych. Jednak dla chcącego nic trudnego – pomysłem na obejście limitu 16 GB może być np. zbudowanie modelu korzystającego z zapytań w trybie DirectQuery, w którym zapytanie realizowane jest bezpośrednio na bazie relacyjnej, która jest źródłem danych modelu, bez tworzenia kopii danych w bazie OLAP (ilustracja poniżej).

directquery

Należy jednak pamiętać, że w przypadku takiej architektury niezbędne są mechanizmy zapewniające wydajną realizację zapytań w bazie relacyjnej. Zaraz! Przecież edycja Standard po SP1 ma  indeksy kolumnowe – owszem, z tym, że trzeba pamiętać, o ograniczeniach z nimi związanymi – które zostały opisane m.in w części pierwszej publikacji. Zakładając, że chcemy zapewnić użytkownikom komfortową pracę, tym razem edycja Standard, pomimo różnorodności swoich funkcji i pomysłowości w architekturze, może nie być najlepszym pomysłem.

Pozostając w obszarze funkcjonalności Analysis Services, warto zwrócić również uwagę (co zresztą już zostało podniesione przez jednego z moich obecnych klientów) na inne ograniczenia – tłumaczenia (translations) – niby niewiele, ale okazuje się, że jeśli ktoś skorzystał z tej funkcjonalności mając np. edycję SQL Server 2014 BI, a teraz ze względu na brak edycji BI chciałby zastąpić ją edycją Standard, to niestety trzeba pozbyć się tłumaczeń lub….wykorzystać edycję Enterprise.

Na zakończenie jeszcze dwa elementy:

  • Pierwszy z obszaru bezpieczeństwa – szyfrowanie na poziomie plików bazy danych, czyli Transparent Data Encryption. Funkcjonalność pomimo dużych zmian w ramach SP 1 nie została wprowadzona do edycji Standard – szkoda, ponieważ w przypadku wielu wdrożeń, szyfrowanie fizycznych plików, aby uniemożliwić przeniesienie bazy danych na inny serwer jest jedną z oczekiwanych funkcjonalności.
  • Drugi ze wspomnianych elementów to obszar raportowy – wyłącznie edycja Enterprise oferuje możliwość wykorzystania funkcjonalności raportów mobilnych oraz definiowanych na poziomie portalu raportowego wskaźników KPI.

Czy są to jednoznaczne argumenty za wyborem edycji Enterprise? Nadal masz wątpliwości, a może zastanawiasz się nad „złotym środkiem”? W kolejnej odsłonie postaram się podsumować spostrzeżenia, a także podpowiem jak taki złoty środek osiągnąć…

 

One Reply to “Dlaczego mimo wszystko warto wybrać edycję Enterprise? – część 2”

Comments are closed.