Co jest lepsze – Oracle czy Redis, czyli Jak uzasadnić wybór platformy

„To konieczne” – powiedziała głośno, nie zwracając się do nikogo. - To jest niezbędne! Dokładnie tak jest napisane: głównym zadaniem spółki jest osiąganie zysku w interesie akcjonariuszy. Cóż Pomyśl o tym! Oni się niczego nie boją!

Yuliy Dubov, „Mniejsze zło”

Widząc taki nagłówek, prawdopodobnie już zdecydowałeś, że artykuł jest albo głupotą, albo prowokacją. Ale nie spieszcie się z wnioskami: pracownicy dużych korporacji, zwłaszcza korporacji z udziałem państwa, dość często muszą porównywać różne platformy, w tym zupełnie inne - na przykład te w tytule.

Co jest lepsze – Oracle czy Redis, czyli Jak uzasadnić wybór platformy

Oczywiście nikt nie porównuje w ten sposób SZBD, ponieważ ich mocne i słabe strony są dobrze znane. Z reguły porównywaniu podlegają platformy, które rozwiązują jakiś problem aplikacji. W artykule pokażę metodologię zastosowaną w tym przypadku na przykładzie baz danych jako tematu znanego czytelnikom Habr z pierwszej ręki. Więc,

Motywacja

Kiedy rozpoczynasz projekt edukacyjny lub projekt hobbystyczny, motywacja wyboru platformy może być bardzo zróżnicowana: „to jest platforma, którą znam najlepiej”, „chcę zrozumieć tę platformę”, „tutaj jest najlepsza dokumentacja” ... W przypadku spółki prawa handlowego kryterium wyboru jest takie samo: ile będę musiał zapłacić i co dostanę za te pieniądze.

To naturalne, że chcesz zapłacić mniej i zyskać więcej. Musisz jednak zdecydować, co jest ważniejsze – płacić mniej czy zyskać więcej i przypisać wagę do każdego węzła. Załóżmy, że ważniejsze jest dla nas rozwiązanie wysokiej jakości niż tanie i przypisujemy wagę 40% węzłowi „Koszt” i 60% węzłowi „Możliwości”.

Co jest lepsze – Oracle czy Redis, czyli Jak uzasadnić wybór platformy

W dużych korporacjach zwykle jest odwrotnie – waga kosztów nie spada poniżej 50%, a może i więcej niż 60%. W przykładzie modelu ważne jest jedynie, aby całkowita waga węzłów podrzędnych dowolnego węzła nadrzędnego wynosiła 100%.

Warunki odcięcia

Strona db-silniki.com Znanych jest około 500 systemów zarządzania bazami danych. Naturalnie, jeśli spośród tak wielu opcji wybierzesz platformę docelową, może skończyć się artykułem recenzyjnym, ale nie komercyjnym projektem. Aby zawęzić przestrzeń wyboru, formułuje się kryteria odcięcia i jeśli platforma tych kryteriów nie spełnia, nie jest brana pod uwagę.

Kryteria odcięcia mogą odnosić się do cech technologicznych, na przykład:

  • Gwarancje ACID;
  • relacyjny model danych;
  • Obsługa języka SQL (uwaga, to nie to samo, co „model relacyjny”);
  • możliwość skalowania poziomego.

Mogą istnieć kryteria ogólne:

  • dostępność wsparcia komercyjnego w Rosji;
  • otwarte źródło;
  • dostępność platformy w Rejestrze Ministerstwa Telekomunikacji i Komunikacji Masowej;
  • obecność platformy w jakimś rankingu (na przykład w pierwszej setce rankingu db-engines.com);
  • obecność ekspertów na rynku (na przykład na podstawie wyników wyszukiwania nazwy platformy w CV na stronie hh.ru).

W końcu mogą istnieć kryteria specyficzne dla przedsiębiorstwa:

  • dostępność specjalistów w personelu;
  • kompatybilność z systemem monitorowania X lub systemem zapasowym Y, na którym opiera się całe wsparcie...

Najważniejsze jest to, że istnieje lista kryteriów odcięcia. W przeciwnym razie na pewno znajdzie się jakiś ekspert (lub „ekspert”) cieszący się szczególnym zaufaniem ze strony kierownictwa, który powie „dlaczego nie wybrałeś platformy Z, wiem, że jest najlepsza”.

Oszacowanie kosztów

Na koszt rozwiązania składają się oczywiście koszty licencji, koszty wsparcia oraz koszt sprzętu.

Jeżeli systemy są w przybliżeniu tej samej klasy (np. Microsoft SQL Server i PostgreSQL), to dla uproszczenia możemy założyć, że ilość sprzętu dla obu rozwiązań będzie w przybliżeniu taka sama. Pozwoli to nie oceniać sprzętu, oszczędzając w ten sposób dużo czasu i wysiłku. Jeśli trzeba porównać zupełnie różne systemy (powiedzmy Oracle vs. Redis), to oczywistym jest, że do prawidłowej oceny konieczne jest wykonanie sizingu (obliczenia ilości sprzętu). Dobór nieistniejącego systemu jest bardzo niewdzięcznym zadaniem, dlatego nadal starają się unikać takich porównań. Można to łatwo zrobić: w warunkach odcięcia zapisuje się zerową utratę danych i model relacyjny lub odwrotnie - obciążenie 50 tysięcy transakcji na sekundę.

Aby ocenić licencje, wystarczy zapytać sprzedawcę lub jego partnerów o koszt licencji na ustaloną liczbę rdzeni i wsparcie na czas określony. Z reguły firmy mają już silne relacje z dostawcami oprogramowania i jeśli dział operacji bazodanowych nie jest w stanie samodzielnie odpowiedzieć na pytanie kosztowe, wystarczy jedno pismo, aby uzyskać tę informację.

Różni dostawcy mogą mieć różne wskaźniki licencyjne: liczbę rdzeni, ilość danych lub liczbę węzłów. Baza rezerwowa może być bezpłatna lub może być licencjonowana w taki sam sposób jak baza główna. W przypadku wykrycia różnic w metrykach konieczne będzie szczegółowe opisanie stoiska modelowego i obliczenie kosztu licencji na stanowisko.

Ważnym punktem dla prawidłowego porównania są te same warunki wsparcia. Na przykład wsparcie Oracle kosztuje 22% ceny licencji rocznie, ale nie musisz płacić za wsparcie PostgreSQL. Czy właściwe jest takie porównanie? Nie, ponieważ błąd, którego nie da się naprawić samodzielnie, ma zupełnie inne konsekwencje: w pierwszym przypadku specjaliści wsparcia szybko pomogą Ci go naprawić, ale w drugim przypadku istnieje ryzyko opóźnienia projektu lub przestoju gotowego produktu systemu na czas nieokreślony.

Warunki obliczeń można wyrównać na trzy sposoby:

  1. Używaj Oracle bez wsparcia (w rzeczywistości tak się nie dzieje).
  2. Kup wsparcie dla PostgreSQL - na przykład od Postgres Professional.
  3. Weź pod uwagę ryzyko związane z brakiem wsparcia.

Na przykład obliczenie ryzyka może wyglądać następująco: w przypadku krytycznej awarii bazy danych przestój systemu wyniesie 1 dzień roboczy. Przewidywany zysk z użytkowania systemu to 40 miliardów MNT rocznie, wypadkowość szacuje się na 1/400, tym samym ryzyko braku wsparcia szacuje się na około 100 milionów MNT rocznie. Oczywiście „planowany zysk” i „szacowana częstotliwość wypadków” to wartości wirtualne, ale o wiele lepiej jest mieć taki model, niż go nie mieć.

W rzeczywistości system może być zbyt ważny, aby koszty reputacji wynikające z długotrwałych przestojów były nie do zaakceptowania, dlatego konieczne będzie wsparcie. Jeśli dozwolone są przestoje, odmowa wsparcia może czasami być dobrym sposobem na zaoszczędzenie pieniędzy.

Załóżmy, że po wszystkich obliczeniach koszt obsługi platformy A przez 5 lat okaże się 800 mln MNT, koszt obsługi platformy B 650 mln MNT, a koszt obsługi platformy C 600 mln MNT. Platforma C jako zwycięzca otrzymuje pełny punkt za cenę, natomiast platformy A i B otrzymują nieco mniej, proporcjonalnie do tego, ile razy są droższe. W tym przypadku – odpowiednio 0.75 i 0.92 pkt.

Ocena możliwości

Ocena szans dzieli się na wiele grup, których liczbę ogranicza jedynie wyobraźnia osoby dokonującej oceny. Optymalną opcją wydaje się podział kompetencji na zespoły, które będą z nich korzystać; w naszym przykładzie są to programiści, administratorzy i specjaliści ds. bezpieczeństwa informacji. Załóżmy, że wagi tych funkcji mają rozkład 40:40:20.

Funkcje rozwojowe obejmują:

  • łatwość manipulacji danymi;
  • skalowanie;
  • obecność indeksów wtórnych.

Lista kryteriów, a także ich wagi są bardzo subiektywne. Nawet przy rozwiązywaniu tego samego problemu te listy, wagi elementów i odpowiedzi będą się znacznie różnić w zależności od składu Twojego zespołu. Na przykład Facebook używa MySQL do przechowywania danych, a Instagram opiera się na Cassandrze. Jest mało prawdopodobne, aby twórcy tych aplikacji wypełnili takie tabele. Można się tylko domyślać, że Mark Zuckerberg wybrał pełnoprawny model relacyjny, płacąc za to koniecznością stosowania shardingu, zaś Kevin Systrom budował skalowanie z wykorzystaniem platformy, rezygnując z łatwości dostępu do danych.

Funkcje administracyjne obejmują:

  • możliwości systemu tworzenia kopii zapasowych;
  • łatwość monitorowania;
  • łatwość zarządzania pojemnością – dyskami i węzłami;
  • możliwości replikacji danych.

Należy pamiętać, że pytania muszą być sformułowane w sposób ilościowy. Można nawet uzgodnić, jak ocenić konkretną funkcję. Spróbujmy na przykład ocenić narzędzia do tworzenia kopii zapasowych na przykładzie narzędzi dostarczanych z Oracle DBMS:

Narzędzie
Komentarz
Ocena

imp/wyr
Przesyłanie i ładowanie danych
0.1

rozpocząć/zakończyć tworzenie kopii zapasowej
Kopiowanie plików
0.3

RMAN
Możliwość kopiowania przyrostowego
0.7

ZDLRA
Tylko kopiowanie przyrostowe, najszybsze odzyskiwanie do punktu
1.0

Jeżeli nie ma jasnych kryteriów oceny, warto poprosić kilku ekspertów o wystawienie ocen, a następnie je uśrednić.

Na koniec po prostu wymieniamy funkcje bezpieczeństwa informacji:

  • dostępność zasad zarządzania hasłami;
  • możliwość podłączenia zewnętrznych narzędzi uwierzytelniających (LDAP, Kerberos);
  • wzór dostępu;
  • możliwości audytu;
  • szyfrowanie danych na dysku;
  • szyfrowanie podczas transmisji przez sieć (TLS);
  • ochrony danych przez administratora.

Test wydajności

Osobno przestrzegam przed wykorzystywaniem jako argumentów wyników jakichkolwiek testów obciążeniowych, które nie zostały przez Ciebie wykonane.

Po pierwsze, struktura danych i profil obciążenia testowanych aplikacji mogą znacznie różnić się od problemu, który zamierzasz rozwiązać. Około 10-15 lat temu dostawcy baz danych uwielbiali chwalić się wynikami osiąganymi w testach TPC, ale obecnie wydaje się, że nikt nie traktuje tych wyników poważnie.

Po drugie, wydajność systemu dość mocno zależy od platformy, na jaką pierwotnie napisano kod i na jakim sprzęcie przeprowadzono test. Widziałem wiele testów, w których porównywano Oracle z PostgreSQL. Wyniki wahają się od bezwarunkowej wyższości jednego systemu do równie bezwarunkowej wyższości innego.

I wreszcie, po trzecie, nie wiesz nic o tym, kto przeprowadził test. Obie kwalifikacje są ważne, wpływają na jakość konfiguracji systemu operacyjnego i platformy, a także motywacja, która wpływa na wyniki testu bardziej niż wszystkie inne czynniki razem wzięte.

Jeśli wydajność jest czynnikiem krytycznym, przeprowadź test samodzielnie, najlepiej z pomocą osób, które będą konfigurować i utrzymywać system produkcyjny.

Doświadcz mocnych i skutecznych rezultatów

Na koniec wynikiem całej wykonanej pracy powinien być arkusz kalkulacyjny, w którym wszystkie szacunki są łączone, mnożone i sumowane:

Co jest lepsze – Oracle czy Redis, czyli Jak uzasadnić wybór platformy

Jak rozumiesz, zmieniając skalę i dostosowując oceny, możesz osiągnąć dowolny pożądany rezultat, ale to zupełnie inna historia…

Źródło: www.habr.com

Dodaj komentarz