Jak wybrać odpowiednią bazę danych do swojej aplikacji

Wybór „właściwej” bazy danych często może mieć kluczowe znaczenie dla powodzenia aplikacji. Zamiast korzystać z porady dostawców lub korzystać z bazy danych, ponieważ już ją masz, warto rozważyć podstawowy cel i wymagania magazynu danych.

Oto najważniejsze pytania, jakie należy zadać podczas wybierania bazy danych:

  • Ile danych spodziewasz się przechowywać, gdy aplikacja będzie dojrzała?
  • Ilu użytkowników spodziewasz się obsługiwać jednocześnie w szczytowym obciążeniu?
  • Jakiej dostępności, skalowalności, opóźnień, przepustowości i spójności danych potrzebuje Twoja aplikacja?
  • Jak często będą się zmieniać schematy bazy danych?
  • Jakie jest rozmieszczenie geograficzne populacji użytkowników?
  • Jaki jest naturalny „kształt” Twoich danych?
  • Czy Twoja aplikacja wymaga przetwarzania transakcji online (OLTP), zapytań analitycznych (OLAP), czy obu?
  • Jakiego stosunku odczytów do zapisów spodziewasz się w produkcji?
  • Czy potrzebujesz zapytań geograficznych i / lub pełnotekstowych?
  • Jakie są Twoje ulubione języki programowania?
  • Masz budżet? Jeśli tak, czy obejmie licencje i umowy serwisowe?
  • Czy istnieją ograniczenia prawne dotyczące przechowywania danych?

Rozwińmy te pytania i ich konsekwencje.

Ile danych będziesz przechowywać?

Jeśli oszacowanie jest w gigabajtach lub mniej, prawie każda baza danych będzie obsługiwać dane, a bazy danych w pamięci są całkowicie wykonalne. Wciąż istnieje wiele opcji baz danych do obsługi danych w zakresie terabajtów (tysięcy gigabajtów).

Jeśli odpowiedź jest w petabajtach (miliony gigabajtów) lub więcej, tylko kilka baz danych będzie Ci dobrze służyć i musisz być przygotowany na znaczne koszty przechowywania danych, czy to w wydatkach kapitałowych na przechowywanie w siedzibie, czy w magazyn w chmurze. W tej skali możesz potrzebować warstwowej pamięci masowej, aby zapytania dotyczące „żywych” danych mogły być uruchamiane w pamięci lub na lokalnych dyskach SSD w celu uzyskania szybkości, podczas gdy pełny zestaw danych znajduje się na obracających się dyskach w celu obniżenia kosztów.

Ilu jednoczesnych użytkowników?

Szacowanie obciążenia wielu jednoczesnych użytkowników jest często traktowane jako ćwiczenie dotyczące rozmiaru serwera, które należy wykonać tuż przed zainstalowaniem produkcyjnej bazy danych. Niestety, wiele baz danych po prostu nie może obsłużyć tysięcy użytkowników wysyłających zapytania o terabajty lub petabajty danych z powodu problemów ze skalowaniem.

Szacowanie liczby jednoczesnych użytkowników jest znacznie łatwiejsze w przypadku bazy danych używanej przez pracowników niż w przypadku publicznej bazy danych. W tym drugim przypadku może być konieczne skalowanie w poziomie do wielu serwerów w przypadku nieoczekiwanych lub sezonowych obciążeń. Niestety, nie wszystkie bazy danych obsługują skalowanie poziome bez czasochłonnego ręcznego dzielenia dużych tabel na fragmenty.

Jakie są Twoje wymagania dotyczące „-zdolności”?

Do tej kategorii zaliczam dostępność, skalowalność, opóźnienia, przepustowość i spójność danych, mimo że nie wszystkie terminy kończą się na „-ility”.

Dostępność jest często kluczowym kryterium dla transakcyjnych baz danych. Chociaż nie każda aplikacja musi działać 24 godziny na dobę, 7 dni w tygodniu z dostępnością na poziomie 99,999%, niektóre tak. Kilka baz danych w chmurze oferuje dostępność „pięć dziewiątek”, o ile są uruchamiane w wielu strefach dostępności. Lokalne bazy danych można zwykle skonfigurować pod kątem wysokiej dostępności poza zaplanowanymi okresami konserwacji, zwłaszcza jeśli możesz sobie pozwolić na skonfigurowanie pary serwerów aktywny-aktywny.

Skalowalność, zwłaszcza pozioma, była historycznie lepsza w przypadku baz danych NoSQL niż baz danych SQL, ale kilka baz danych SQL nadrabia zaległości. Dynamiczna skalowalność jest znacznie łatwiejsza do osiągnięcia w chmurze. Bazy danych o dobrej skalowalności mogą obsługiwać wielu jednoczesnych użytkowników przez skalowanie w górę lub w dół, aż przepustowość będzie wystarczająca dla obciążenia.

Opóźnienie odnosi się zarówno do czasu odpowiedzi bazy danych, jak i do czasu odpowiedzi aplikacji od końca do końca. W idealnym przypadku każde działanie użytkownika będzie miało czas reakcji poniżej sekundy; często oznacza to, że baza danych musi odpowiedzieć w czasie krótszym niż 100 milisekund na każdą prostą transakcję. Zapytania analityczne często mogą zająć sekundy lub minuty. Aplikacje mogą oszczędzać czas odpowiedzi, uruchamiając skomplikowane zapytania w tle.

Przepustowość bazy danych OLTP jest zwykle mierzona w transakcjach na sekundę. Bazy danych o dużej przepustowości mogą obsługiwać wielu jednoczesnych użytkowników.

Spójność danych jest zwykle „silna” w przypadku baz danych SQL, co oznacza, że ​​wszystkie odczyty zwracają najnowsze dane. W przypadku baz danych NoSQL spójność danych może być różna, od „ewentualnej” do „silnej”. Ostateczna spójność zapewnia mniejsze opóźnienia, co grozi odczytaniem nieaktualnych danych.

Spójność to litera „C” we właściwościach ACID wymagana do zachowania ważności w przypadku błędów, partycji sieciowych i awarii zasilania. Cztery właściwości ACID to atomowość, spójność, izolacja i trwałość.

Czy schematy bazy danych są stabilne?

Jeśli schematy bazy danych prawdopodobnie nie zmienią się znacząco w czasie i chcesz, aby większość pól miała spójne typy od rekordu do rekordu, bazy danych SQL będą dobrym wyborem. W przeciwnym razie bazy danych NoSQL, z których niektóre nie obsługują nawet schematów, mogą być lepsze dla Twojej aplikacji. Są jednak wyjątki. Na przykład Rockset umożliwia tworzenie zapytań SQL bez narzucania stałego schematu lub spójnych typów danych, które importuje.

Geograficzne rozmieszczenie użytkowników

Gdy użytkownicy bazy danych są na całym świecie, prędkość światła narzuca niższy limit opóźnienia bazy danych dla użytkowników zdalnych, chyba że udostępnisz dodatkowe serwery w ich regionach. Niektóre bazy danych pozwalają na rozproszone serwery do odczytu i zapisu; inne oferują rozproszone serwery tylko do odczytu, w których wszystkie zapisy muszą przechodzić przez jeden serwer główny. Dystrybucja geograficzna sprawia, że ​​kompromis między spójnością a opóźnieniem jest jeszcze trudniejszy.

Większość baz danych obsługujących globalnie rozproszone węzły i silną spójność wykorzystuje grupy konsensusu w celu przyspieszenia zapisu bez poważnej degradacji spójności, zwykle przy użyciu algorytmów Paxos (Lamport, 1990) lub Raft (Ongaro i Ousterhout, 2013). Rozproszone bazy danych NoSQL, które są ostatecznie spójne, zazwyczaj wykorzystują replikację typu peer-to-peer bez konsensusu, co może prowadzić do konfliktów, gdy dwie repliki otrzymują współbieżne zapisy do tego samego rekordu, konflikty, które zwykle są rozwiązywane heurystycznie.

Kształt danych

Bazy danych SQL klasycznie przechowują dane o jednoznacznie określonym typie w prostokątnych tabelach z wierszami i kolumnami. Opierają się na zdefiniowanych relacjach między tabelami, używają indeksów do przyspieszania wybranych zapytań i używają JOINS do wykonywania zapytań do wielu tabel jednocześnie. Bazy danych dokumentów zazwyczaj przechowują kod JSON o słabym typie, który może zawierać tablice i zagnieżdżone dokumenty. Grafowe bazy danych przechowują wierzchołki i krawędzie, trójki lub kwadraty. Inne kategorie baz danych NoSQL obejmują magazyny klucz-wartość i kolumny.

Czasami dane są generowane w kształcie, który będzie również nadawał się do analizy; czasami tak nie jest i konieczna będzie transformacja. Czasami jeden rodzaj bazy danych jest budowany na innym. Na przykład magazyny klucz-wartość mogą stanowić podstawę prawie każdego rodzaju bazy danych.

OLTP, OLAP czy HTAP?

Aby rozszyfrować powyższe akronimy, należy zadać sobie pytanie, czy aplikacja potrzebuje bazy danych do transakcji, analizy, czy też obu. Potrzeba szybkich transakcji oznacza dużą szybkość zapisu i minimalne indeksy. Konieczność analizy oznacza dużą szybkość odczytu i dużą liczbę indeksów. Systemy hybrydowe wykorzystują różne sztuczki do obsługi obu wymagań, w tym podstawowy magazyn transakcyjny zasilający dodatkowy magazyn analiz poprzez replikację.

Współczynnik odczytu / zapisu

Niektóre bazy danych są szybsze w odczytach i zapytaniach, a inne są szybsze w zapisie. Połączenie odczytów i zapisów, których oczekujesz od swojej aplikacji, jest użyteczną liczbą, którą należy uwzględnić w kryteriach wyboru bazy danych, i może kierować twoimi wysiłkami związanymi z testowaniem porównawczym. Optymalny wybór typu indeksu różni się między aplikacjami wymagającymi dużej ilości odczytu (zwykle B-drzewo) i aplikacjami wymagającymi dużej ilości zapisu (często drzewo łączenia o strukturze dziennika, inaczej drzewo LSM).

Indeksy i zapytania geoprzestrzenne

Jeśli masz dane geograficzne lub geometryczne i chcesz wykonywać wydajne zapytania w celu znalezienia obiektów wewnątrz granicy lub obiektów w określonej odległości od lokalizacji, potrzebujesz innych indeksów niż w przypadku typowych danych relacyjnych. R-drzewo jest często preferowanym wyborem dla indeksów geoprzestrzennych, ale istnieje ponad tuzin innych możliwych struktur danych indeksów geoprzestrzennych. Istnieje kilkadziesiąt baz danych obsługujących dane przestrzenne; większość obsługuje niektóre lub wszystkie standardy Open Geospatial Consortium.

Indeksy i zapytania pełnotekstowe

Podobnie, wydajne wyszukiwanie pełnotekstowe pól tekstowych wymaga innych indeksów niż dane relacyjne lub geoprzestrzenne. Zazwyczaj tworzy się odwrócony indeks listy tokenizowanych słów i przeszukuje go, aby uniknąć kosztownego skanowania tabeli.

Preferowane języki programowania

Chociaż większość baz danych obsługuje interfejsy API dla wielu języków programowania, preferowany język programowania w aplikacji może czasami wpływać na wybór bazy danych. Na przykład JSON jest naturalnym formatem danych dla JavaScript, więc możesz wybrać bazę danych, która obsługuje typ danych JSON dla aplikacji JavaScript. Korzystając z języka programowania o jednoznacznie określonym typie, możesz chcieć wybrać bazę danych o jednoznacznie określonym typie.

Ograniczenia budżetowe

Ceny baz danych wahają się od bezpłatnych do bardzo drogich. Wiele baz danych ma zarówno wersję bezpłatną, jak i płatną, a czasami oferuje więcej niż jeden poziom płatnej oferty, na przykład oferującą wersję Enterprise i różne czasy odpowiedzi usługi. Ponadto niektóre bazy danych są dostępne w chmurze na warunkach płatności zgodnie z rzeczywistym użyciem.

Jeśli wybierzesz bezpłatną bazę danych o otwartym kodzie źródłowym, być może będziesz musiał zrezygnować ze wsparcia dostawcy. Tak długo, jak masz własne doświadczenie, może to być w porządku. Z drugiej strony może być bardziej produktywne dla pracowników, jeśli skupią się na aplikacji i pozostawią administrację i konserwację bazy danych dostawcom lub dostawcom chmury.

Ograniczenia prawne

Istnieje wiele przepisów dotyczących bezpieczeństwa danych i prywatności. W UE RODO ma daleko idące konsekwencje dla prywatności, ochrony danych i lokalizacji danych. W USA HIPAA reguluje informacje medyczne, a GLBA reguluje sposób, w jaki instytucje finansowe traktują prywatne informacje klientów. W Kalifornii nowa CCPA wzmacnia prawa do prywatności i ochronę konsumentów.

Niektóre bazy danych mogą obsługiwać dane w sposób zgodny z niektórymi lub wszystkimi tymi przepisami, o ile przestrzegasz najlepszych praktyk. Inne bazy danych mają wady, które bardzo utrudniają wykorzystanie ich do przechowywania danych osobowych, bez względu na to, jak bardzo jesteś ostrożny.

Szczerze mówiąc, była to długa lista czynników, które należy wziąć pod uwagę przy wyborze bazy danych, prawdopodobnie więcej, niż chciałbyś wziąć pod uwagę. Niemniej jednak warto spróbować odpowiedzieć na wszystkie pytania najlepiej jak potrafisz, zanim zaryzykujesz zlecenie projektu w niewłaściwej lub zbyt kosztownej bazie danych.