Projekt bazy danych: schemat i skalowalność
Bazy danych, jak można sobie wyobrazić, obejmują szeroką gamę aplikacji i wymagań. W tym celu omawiamy kilka konkretnych wzorców projektowych, jakie muszą stosować twórcy baz danych podczas tworzenia systemów baz danych.
Wymuszanie schematów
Ogólnie systemy baz danych wymagają pewnych informacji dotyczących typów i struktur danych, które mają być przechowywane w ich bazach danych. W przypadku systemów relacyjnych baz danych schemat jest zdefiniowany formalnie w następujący sposób:
- Krotki (wiersze) składające się z atrybutów (kolumn), z których wszystkie są zdefiniowane jako określony typ.
- Relacja (tabela) składająca się z wielu krotek tego samego typu.
- Ograniczenia, które definiują zestaw zasad dla krotek, atrybutów i relacji.
Schematy nie są tylko wytycznymi, ale są wymuszane w systemach relacyjnych. Bazy danych oparte na schematach mają następujące zalety:
- Schematy wyrażają model danych w sposób umożliwiający konstruowanie złożonych operacji i zapytań. Na przykład sprzężenie (gdzie dane są wnioskowane z co najmniej dwóch odrębnych tabel) jest stosunkowo łatwe do wyrażenia w relacyjnej bazie danych.
- Schematy mogą zawierać ograniczenia, których można używać do wymuszania logiki programu na poziomie bazy danych. Na przykład proste ograniczenia mogą sprawdzać, czy wiek osoby jest liczbą dodatnią, natomiast księga bankowa wdrożona jako zestaw tabel w relacyjnej bazie danych może wymusić właściwość (przy użyciu ograniczenia złożonego), że suma wszystkich kredytów i obciążeń w systemie musi być równa 0. System może automatycznie odrzucać lub zwracać transakcje naruszające te ograniczenia.
- Systemy relacyjne wykorzystują informacje podane w schemacie w celu konstruowania złożonych i wydajnych planów zapytań. Dzięki temu baza danych może efektywnie odpowiadać na zapytania dotyczące przechowywanych danych.
Jednakże sztywne wymuszanie schematu jest barierą dla elastyczności. W miarę rozwoju aplikacji zmiana schematu tabeli wypełnionej wierszami będzie trudna, a być może nawet niemożliwa, w zależności od tabeli i podanych ograniczeń.
Z drugiej strony istnieją systemy, które mają elastyczne schematy lub nie stosują żadnych schematów. Przykładem systemu praktycznie bez schematu jest ogólny magazyn par klucz-wartość, który zasadniczo działa jako mapowanie między kluczami pewnego typu a powiązaną z nimi wartością. Niektóre magazyny par klucz-wartość są bardzo elastyczne — umożliwiają przechowywanie w ramach określonego klucza dowolnych danych binarnych. Niektóre magazyny par klucz-wartość, takie jak AWS Dynamo DB, wymagają, aby typ klucza (ciąg, liczba całkowita itp.) był jawny podczas tworzenia nowej tabeli. Niektóre systemy, takie jak magazyn Azure Table, zezwalają na obecność zagnieżdżonych wartości w atrybutach danych, zwykle przechowywanych jako pliki JSON lub XML.
Inną odmianą są takie systemy jak BigTable i Apache HBase, które mają częściowo elastyczny schemat. Te systemy wymagają zadeklarowania liczby kolumn podczas tworzenia tabeli, ale kolumna może zawierać dowolną liczbę zagnieżdżonych kolumn podrzędnych. Systemy te zostaną szczegółowo omówione w następnym module.
Przetwarzanie transakcyjne a analityczne
Kluczową decyzją, jaką trzeba podjąć podczas optymalizacji systemu bazy danych, jest optymalizacja pod kątem typowego typu zapytań, które będą odbierane przez system. W obciążeniach baz danych pojawiły się dwa główne wzorce.
Obciążenia transakcyjne, znane również jako przetwarzanie transakcyjne online (OLTP), są obciążeniami, które składają się głównie z krótkich transakcji online. Obciążenia OLTP składają się głównie z wstawień, aktualizacji i/lub usunięć. W systemach OLTP nacisk kładziony jest na szybkie przetwarzanie zapytań i utrzymywanie integralności danych w środowiskach z jednoczesnym dostępem. Dobrym przykładem obciążenia OLTP są transakcje finansowe. Zapytania zazwyczaj obejmują tylko kilka tabel i wierszy oraz nie wymagają rozległych skanów bazy danych.
Z drugiej strony niektóre systemy agregują i analizują dane w celu uzyskania szczegółowych wniosków oraz pozyskania informacji z danych. Systemy te są nazywane systemami przetwarzania analitycznego online (OLAP). Systemy OLAP zazwyczaj obejmują niższą liczbę transakcji, ale poszczególne zapytania mogą być złożone i obejmować zagregowane obliczenia obejmujące wiele wierszy i tabel. Typowe zapytania OLAP są więc przetwarzane znacznie dłużej niż zapytania OLTP.
Poniższy film wideo zawiera omówienie olTP a OLAP:
Skalowalność
W miarę upływu czasu oraz wraz ze wzrostem bazy użytkowników i ilości danych system może wymagać pewnej formy skalowania, które zwiększyłoby jego pojemność i/lub wydajność w celu obsłużenia większej liczby użytkowników i/lub danych. Skalowanie bazy danych jest złożone z różnych powodów, które szczegółowo omówimy w następującym filmie wideo:
Skalowanie w pionie
Skalowanie w pionie (lub skalowanie w górę) to proces zwiększania pojemności bazy danych lub zdolności do obsługi obciążenia bez dodawania większej liczby hostów. Można to zrobić za pomocą uaktualnień sprzętowych, np. instalacji szybszego procesora, zwiększenia pamięci RAM lub instalacji dysków o większej pojemności i/lub większej liczbie operacji we/wy na sekundę (IOPS). Skalowalność ze skalowaniem pionowym jest ograniczona przez procesor, pamięć RAM i dysk, które można skonfigurować na jednym komputerze.
Skalowanie w poziomie
Skalowanie w poziomie (lub skalowanie wszerz) oznacza skalowanie baz danych poprzez dodawanie większej liczby węzłów do obsługi zapytań baz danych. Poszczególne produkty RDBMS oferują różne sposoby skalowania wszerz, w tym replikację i fragmentowanie bazy danych. W przypadku replikacji te same dane są przechowywane w wielu węzłach. Dzięki temu system zarządzania relacyjnymi bazami danych może równolegle obsłużyć dodatkowe żądania, zwiększając liczbę transakcji na sekundę. Takie podejście działa, gdy baza danych jest obciążona operacjami odczytu. We fragmentowaniu duża tabela jest partycjonowana na wiele węzłów (zwykle w indeksie lub kluczu). W takim przypadku ilość danych udostępnianych w węzłach jest ograniczona, a ograniczone udostępnianie jest preferowane, ponieważ zmniejsza liczbę problemów ze spójnością replikowanych danych.
Replikacja jest procesem duplikowania danych na wielu serwerach w celu zwiększenia liczby dostępnych ścieżek do poszczególnych fragmentów danych. Dane można replikować w celu zwiększenia wydajności, dostępności i/lub odporności na uszkodzenia. Zreplikowane dane zwiększają wydajność, szczególnie operacji odczytu, ponieważ replikacja pozwala na dostęp równoległy do wielu kopii tych samych danych. Replikacja pomaga w zapewnianiu dostępności i odporności na uszkodzenia, ponieważ dane są dostępne w lokalizacji zapasowej, jeśli część systemu bazy danych ulegnie awarii.
Inną, prostopadła do replikacji, metodą jest fragmentowania. Fragmentowania to proces polegający na tym, że dane są podzielone na sekcje (znane jako fragmenty) i dystrybuowane w wielu systemach baz danych. W przeciwieństwie do replikacji każdy fragment działa jako pojedyncze źródło podzestawu zawartych w nim danych. Fragmentowanie to technika, która jest stosowana do poprawy wydajności baz danych, a w szczególności wydajności operacji zapisu.
W idealnym przypadku pofragmentowana baza danych równomiernie rozłoży dane na wszystkie partycje. Niestety jest to trudne do osiągnięcia, ponieważ dystrybucja danych między wszystkimi partycjami powinna być mniej lub bardziej zrównoważona. Popularną techniką stosowaną w wielu bieżących systemach baz danych jest spójne tworzenie skrótów.
Spójne tworzenie skrótów jest specjalnym rodzajem techniki tworzenia skrót, która pozwala na skuteczne rozszerzenie tablicy skrótów. Jeśli K jest łączną liczbą kluczy, a n to liczba zasobników w danej tabeli skrótów, spójne tworzenie skrótów wymaga tylko ponownego zmapowania średnio K/n kluczy przy każdym dodaniu do tabeli skrótów nowego zasobnika1.
Niektóre systemy używają kombinacji replikacji i fragmentowania, aby zapewnić doskonałą wydajność przy zachowaniu wysokiej dostępności i odporności na uszkodzenia. Jednakże podczas korzystania z replikacji istotną kwestią jest spójność, którą omówimy za chwilę.
Odwołania
- Karger, David and Lehman, Eric i Leighton, Tom i Panigrahy, Rina i Levine, Matthew i Lewin, Daniel (1997 r.). Spójne tworzenie skrótów i drzewa losowe: rozproszone protokoły Buforowanie do zwalniania punktów aktywnych na całym świecie sprawozdanie z dwudziestego dziewiątego rocznego sympozjum ACM na temat teorii obliczeń