🥇Co lepsze – Oracle czy Redis czy Jak uzasadnić wybór platformy

– To trzeba, – głośno powiedziała, nie zwracając się do nikogo. – To trzeba! Tak jest napisane – głównym zadaniem społeczeństwa jest osiąganie zysku w interesie akcjonariuszy. No pomyślcie! Niczego się nie boją!
Julij Dubow, „Mniejsze zło”

Widząc taki nagłówek, zapewne już zdecydowaliście, że artykuł jest – albo głupi, albo prowokacyjny. Ale nie spieszcie się z wnioskami: pracownicy dużych korporacji, zwłaszcza tych z udziałem państwowym, dość często muszą porównywać różne platformy, w tym zupełnie różne – na przykład te, które zostały wymienione w nagłówku.

Oczywiście, nikt tak nie porównuje DBMS, bo ich mocne i słabe strony są dobrze znane. Z reguły poddawane porównaniu są platformy rozwiązujące jakieś zastosowanie. W artykule pokażę metodologię, która jest przy tym stosowana, na przykładzie baz danych jako przedmiotu, znanego czytelnikom Habr. A więc,

Motywacja

Kiedy zaczynacie projekt edukacyjny lub projekt-hobby, motywacja do wyboru platformy może być bardzo różna: „tę platformę najlepiej znam”, „z tą chcę się zapoznać”, „tutaj jest najlepsza dokumentacja”… W przypadku firmy komercyjnej kryterium wyboru jest jedno: ile trzeba zapłacić i co za te pieniądze otrzymam.

Naturalnie, chcesz zapłacić mniej, a otrzymać więcej. Jednak trzeba określić, co jest ważniejsze – zapłacić mniej, czy otrzymać więcej, i przypisać każdemu węzłowi wagę. Załóżmy, że ważniejsze dla nas jest jakościowe rozwiązanie niż tanie, więc nadamy węzłowi „Koszt” wagę 40%, a węzłowi „Możliwości” – 60%.

W dużych korporacjach zazwyczaj jest odwrotnie – waga kosztu nie spada poniżej 50%, a może być nawet wyższa niż 60%. W modelowym przykładzie ważne jest jedynie to, że łączna waga podrzędnych węzłów każdego węzła nadrzędnego musi wynosić 100%.

Kryteria eliminacyjne

Stronie db-engines.com jest znanych około 500 systemów zarządzania bazami danych. Oczywiście, jeśli wybierasz docelową platformę z tej liczby opcji, może wyniknąć artykuł przeglądowy, ale nie projekt komercyjny. Aby zmniejszyć przestrzeń wyboru, formułuje się kryteria eliminacyjne, a jeśli platforma nie spełnia tych kryteriów, nie jest rozważana.

Kryteria eliminacyjne mogą dotyczyć cech technologicznych, na przykład:

Gwarancje ACID;
relacyjny model danych;
wsparcie dla języka SQL (zauważ, że to nie to samo, co "model relacyjny");
możliwość skalowania poziomego.

Mogą istnieć kryteria ogólne:

istnienie wsparcia komercyjnego w Polsce;
otwarty kod źródłowy;
istnienie platformy w Rejestrze Ministerstwa Cyfryzacji;
istnienie platformy w jakimś rankingu (na przykład w pierwszej setce rankingu db-engines.com);
istnienie ekspertów na rynku (na przykład na podstawie wyników wyszukiwania nazwy platformy w CV na stronie hh.pl).

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

istnienie specjalistów w zespole;
kompatybilność z systemem monitorowania X lub z systemem tworzenia kopii zapasowych Y, na którym oparty jest cały suport…

Najważniejsze, żeby istniała lista kryteriów eliminacyjnych. W przeciwnym razie na pewno znajdzie się jakiś ekspert (lub "ekspert"), cieszący się szczególnym zaufaniem kierownictwa, który powie "czemu nie wybraliście platformy Z, ja wiem, że jest najlepsza".

Ocena kosztów

Koszt rozwiązania składa się oczywiście z kosztów licencji, kosztów wsparcia i kosztów sprzętu.

Jeśli systemy są w przybliżeniu tej samej klasy (na przykład Microsoft SQL Server i PostgreSQL), to dla uproszczenia można założyć, że liczba sprzętu dla obu tych rozwiązań będzie mniej więcej taka sama. To pozwoli zaoszczędzić czas i wysiłek na ocenę sprzętu. Jeśli jednak trzeba porównywać zupełnie różne systemy (powiedzmy, Oracle vs. Redis), to jasno widać, że dla poprawnej oceny konieczne będzie przeprowadzenie sizingu (obliczenia liczby sprzętu). Sizing nieistniejącego systemu - kwestia niezwykle niewdzięczna, dlatego takie porównania są unikane. Można to zrobić prosto: w warunkach eliminacyjnych zapisuje się zerową utratę danych i model relacyjny lub na odwrót - obciążenie z 50 tysięcy transakcji na sekundę.

Aby ocenić licencje, wystarczy poprosić dostawcę lub jego partnerów o cenę licencji na określoną liczbę rdzeni i wsparcia na określony czas. Z reguły firmy mają już ugruntowane relacje z dostawcami oprogramowania, a jeśli dział zarządzania bazami danych nie może samodzielnie odpowiedzieć na pytanie o koszt, wystarczy jedno pismo, aby uzyskać te informacje.

Różni dostawcy mogą mieć różne metryki licencjonowania: na podstawie liczby rdzeni, objętości danych lub liczby węzłów. Baza standby może być bezpłatna lub licencjonowana tak samo jak baza główna. Jeśli tylko ujawnione zostaną jakieś różnice w metrykach, konieczne będzie szczegółowe opisanie modelowego środowiska i obliczenie kosztów licencji dla tego środowiska.

Ważnym punktem dla prawidłowego porównania są te same warunki wsparcia. Powiedzmy, że wsparcie Oracle kosztuje 22% wartości licencji rocznie, a za wsparcie PostgreSQL nie trzeba płacić. Czy jest to prawidłowe porównanie? Nie, ponieważ skutki błędu, który nie może być usunięty siłami własnymi, są zupełnie różne: w pierwszym przypadku specjaliści wsparcia szybko pomogą go usunąć, a w drugim przypadku istnieje ryzyko opóźnienia projektu lub przestoju gotowego systemu na nieokreślony czas.

Można zrównoważyć warunki obliczeniowe na trzy sposoby:

Korzystać z Oracle bez wsparcia (w rzeczywistości takie sytuacje nie występują).
Zakupić wsparcie dla PostgreSQL – na przykład w firmie Postgres Professional.
Wziąć pod uwagę ryzyka związane z brakiem wsparcia.

Na przykład obliczenie ryzyk może wyglądać następująco: w przypadku nieusuwalnej awarii bazy danych przestój systemu wyniesie 1 dzień roboczy. Planowany zysk z wykorzystania systemu to 40 miliardów mongolskich tugrików rocznie, a częstość awarii szacuje się na 1/400, w ten sposób ryzyko braku wsparcia szacuje się na około 100 milionów mongolskich tugrików rocznie. Oczywiście, "planowany zysk" i "szacowana częstość awarii" to wartości wirtualne, ale znacznie lepiej mieć taki model, niż nie mieć żadnego.

W rzeczywistości system może być zbyt ważny, a straty w reputacji spowodowane długotrwałym przestojem mogą być niedopuszczalne, dlatego wsparcie będzie potrzebne. Jeśli jednak przestój jest dopuszczalny, czasami rezygnacja z wsparcia może być dobrym sposobem na oszczędności.

Załóżmy, że po wszystkich obliczeniach koszt eksploatacji platformy A przez 5 lat wyniósł 800 mln mongolskich tugrików, koszt eksploatacji platformy B – 650 mln tugrików, a koszt eksploatacji platformy C – 600 mln tugrików. Platforma C jako zwycięzca otrzymuje za koszt pełny punkt, a platformy A i B – nieco mniej, proporcjonalnie do tego, o ile są droższe. W tym przypadku – odpowiednio 0.75 i 0.92 punktów.

Ocena możliwości

Ocena możliwości dzieli się na wiele grup, których liczba jest ograniczona tylko wyobraźnią osoby dokonującej oceny. Optymalnym rozwiązaniem wydaje się podział możliwości według zespołów, które będą z nich korzystać; w naszym przykładzie to programiści, administratorzy i oficerowie bezpieczeństwa informacji. Zakładając, że wagi tych funkcji są rozdzielane w proporcjach 40:40:20.

Funkcje rozwoju obejmują:

wygodę manipulowania danymi;
skalowalność;
obecność indeksów wtórnych.

Lista kryteriów, jak i ich wagi, jest bardzo subiektywna. Nawet przy rozwiązywaniu tego samego problemu, te listy, wagi punktów i odpowiedzi będą się znacznie różnić w zależności od składu twojego zespołu. Na przykład Facebook do przechowywania danych używa MySQL, a Instagram oparty jest na bazie Cassandra. Trudno powiedzieć, że twórcy tych aplikacji wypełniali takie tabele. Można tylko przypuszczać, że Mark Zuckerberg wybrał w pełni relacyjną model, płacąc za to koniecznością shardingu aplikacyjnego, podczas gdy Kevin Systrom postawił na skalowalność platformy, rezygnując z wygody dostępu do danych.

Funkcje administracji obejmują:

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

Zwróć uwagę, że sformułowania pytań powinny umożliwiać ocenę ilościową. Można nawet ustalić, jak oceniać daną funkcję. Spróbujmy na przykład ocenić narzędzia do tworzenia kopii zapasowych na przykładzie narzędzi dostarczanych z systemem zarządzania bazami danych Oracle:

Narzędzie
Komentarz
Ocena

imp/exp
Eksport i import danych
0.1

rozpoczęcie/koniec kopii zapasowej
Kopiowanie plików
0.3

RMAN
Możliwość inkrementalnego tworzenia kopii zapasowych
0.7

ZDLRA
Tylko inkrementalne tworzenie kopii zapasowych, najszybsze przywracanie do punktu
1.0

Jeśli brakuje wyraźnych kryteriów oceny, warto poprosić kilku ekspertów o wystawienie ocen, a następnie je uśrednić.

Na koniec wymieńmy funkcje bezpieczeństwa informacji:

istnienie polityki zarządzania hasłami;
możliwość podłączenia zewnętrznych narzędzi uwierzytelniających (LDAP, Kerberos);
model dostępu oparty na rolach;
możliwości audytu;
szyfrowanie danych na dysku;
szyfrowanie podczas przesyłania przez sieć (TLS);
ochrona danych przed administratorem.

Testowanie wydajności

Chciałbym również ostrzec przed używaniem jako argumentów wyników jakichkolwiek testów obciążeniowych, które zostały przeprowadzone przez kogoś innego.

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 producenci baz danych lubili chwalić się wynikami osiągniętymi w testach TPC, ale teraz wydaje się, że nikt już nie traktuje tych wyników poważnie.

Po drugie, wydajność systemu jest dość mocno uzależniona od tego, na jaką platformę pierwotnie napisano kod i na jakim sprzęcie przeprowadzono test. Widziałem wiele testów, w których Oracle porównywano z PostgreSQL. Wyniki - od niekwestionowanej przewagi jednego systemu po równie niekwestionowaną przewagę drugiego.

I wreszcie, po trzecie, nic nie wiesz o tym, kto przeprowadzał test. Ważne są zarówno kwalifikacje, wpływające na jakość konfiguracji systemu operacyjnego i platformy, jak i motywacja, która wpływa na wyniki testu bardziej niż wszystkie inne czynniki razem wzięte.

Jeśli wydajność jest krytycznym czynnikiem, przeprowadź test samodzielnie, najlepiej z udziałem specjalistów, którzy będą konfigurować i utrzymywać system przemysłowy.