Projektowanie skalowalnych i wydajnych tabel
Napiwek
Zawartość tego artykułu dotyczy oryginalnej usługi Azure Table Storage. Jednak te same pojęcia dotyczą nowszej usługi Azure Cosmos DB dla tabel, która oferuje większą wydajność i dostępność, dystrybucję globalną i automatyczne indeksy pomocnicze. Jest również dostępny w trybie bezserwerowym opartym na użyciu. Istnieją pewne różnice między interfejsem API tabel w usłudze Azure Cosmos DB i usłudze Azure Table Storage. Aby uzyskać więcej informacji, zobacz Usługa Azure Cosmos DB dla tabeli. W celu ułatwienia programowania udostępniamy teraz ujednolicony zestaw AZURE Tables SDK , który może służyć zarówno do kierowania usług Azure Table Storage, jak i Azure Cosmos DB for Table.
Aby zaprojektować skalowalne i wydajne tabele, należy wziąć pod uwagę czynniki, takie jak wydajność, skalowalność i koszt. Jeśli wcześniej zaprojektowano schematy dla relacyjnych baz danych, te zagadnienia są znane, ale chociaż istnieją pewne podobieństwa między modelem usługi Azure Table Service Storage i modelami relacyjnymi, istnieją również istotne różnice. Te różnice zwykle prowadzą do różnych projektów, które mogą wyglądać odwrotnie intuicyjnie lub źle dla kogoś zaznajomionego z relacyjnymi bazami danych, ale mają sens, jeśli projektujesz magazyn kluczy/wartości NoSQL, taki jak usługa Azure Table Service. Wiele różnic projektowych odzwierciedla fakt, że usługa Table Service jest przeznaczona do obsługi aplikacji w skali chmury, które mogą zawierać miliardy jednostek (lub wierszy w terminologii relacyjnej bazy danych) danych lub zestawów danych, które muszą obsługiwać duże ilości transakcji. W związku z tym należy inaczej myśleć o tym, jak przechowujesz dane i rozumiesz, jak działa usługa Table Service. Dobrze zaprojektowany magazyn danych NoSQL umożliwia skalowanie rozwiązania znacznie dalej i przy niższych kosztach niż rozwiązanie korzystające z relacyjnej bazy danych. Ten przewodnik ułatwia zapoznanie się z tymi tematami.
Informacje o usłudze Azure Table Service
W tej sekcji przedstawiono niektóre kluczowe funkcje usługi Table Service, które są szczególnie istotne w projektowaniu pod kątem wydajności i skalowalności. Jeśli dopiero zaczynasz korzystać z usługi Azure Storage i usługi Table Service, najpierw przeczytaj artykuł Wprowadzenie do usługi Azure Table Storage przy użyciu platformy .NET przed przeczytaniem pozostałej części tego artykułu. Chociaż ten przewodnik koncentruje się na usłudze Table Service, obejmuje omówienie usług Azure Queue i Blob oraz sposób ich używania z usługą Table Service.
Co to jest usługa Table Service? Jak można oczekiwać od nazwy, usługa Table Service używa formatu tabelarycznego do przechowywania danych. W standardowej terminologii każdy wiersz tabeli reprezentuje jednostkę, a kolumny przechowują różne właściwości tej jednostki. Każda jednostka ma parę kluczy, aby ją jednoznacznie zidentyfikować, oraz kolumnę znacznika czasu używaną przez usługę Table Service do śledzenia czasu ostatniej aktualizacji jednostki. Znacznik czasu jest stosowany automatycznie i nie można ręcznie zastąpić znacznika czasu dowolną wartością. Usługa Table Service używa tej ostatnio zmodyfikowanej sygnatury czasowej (LMT) do zarządzania optymistyczną współbieżnością.
Uwaga
Operacje interfejsu API REST usługi Table Service zwracają również wartość ETag , która pochodzi z LMT. W tym dokumencie używane są terminy ETag i LMT zamiennie, ponieważ odwołują się one do tych samych danych bazowych.
Poniższy przykład przedstawia prosty projekt tabeli do przechowywania jednostek pracowników i działów. Wiele przykładów przedstawionych w dalszej części tego przewodnika jest opartych na tym prostym projekcie.
| PartitionKey | RowKey | Sygnatura czasowa | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | Department | 2014-08-22T00:50:30Z |
|
||||||||
| Sprzedaż | 00010 | 2014-08-22T00:50:44Z |
|
Do tej pory te dane są podobne do tabeli w relacyjnej bazie danych z kluczowymi różnicami, które są obowiązkowymi kolumnami, oraz możliwością przechowywania wielu typów jednostek w tej samej tabeli. Ponadto każda z właściwości zdefiniowanych przez użytkownika, takich jak FirstName lub Age, ma typ danych, taki jak liczba całkowita lub ciąg, podobnie jak kolumna w relacyjnej bazie danych. Mimo że w przeciwieństwie do relacyjnej bazy danych, bez schematu usługi Table Service oznacza, że właściwość nie musi mieć tego samego typu danych w każdej jednostce. Aby przechowywać złożone typy danych w jednej właściwości, należy użyć formatu serializowanego, takiego jak JSON lub XML. Aby uzyskać więcej informacji na temat usługi tabel, takich jak obsługiwane typy danych, obsługiwane zakresy dat, reguły nazewnictwa i ograniczenia rozmiaru, zobacz Opis modelu danych usługi Table Service.
Wybór wartości PartitionKey i RowKey jest fundamentalny dla dobrego projektu tabeli. Każda jednostka przechowywana w tabeli musi mieć unikatową kombinację wartości PartitionKey i RowKey. Podobnie jak w przypadku kluczy w tabeli relacyjnej bazy danych wartości PartitionKey i RowKey są indeksowane w celu utworzenia indeksu klastrowanego w celu umożliwienia szybkiego wyszukiwania. Jednak usługa Table Service nie tworzy żadnych indeksów pomocniczych, więc PartitionKey i RowKey są jedynymi właściwościami indeksowanych. Niektóre wzorce opisane w temacie Wzorce projektowe tabeli ilustrują, jak można obejść to widoczne ograniczenie.
Tabela składa się z co najmniej jednej partycji, a wiele podejmowanych decyzji projektowych będzie dotyczyć wybierania odpowiedniego klucza partycji i klawisza RowKey w celu zoptymalizowania rozwiązania. Rozwiązanie może składać się z pojedynczej tabeli zawierającej wszystkie jednostki zorganizowane w partycje, ale zazwyczaj rozwiązanie ma wiele tabel. Tabele ułatwiają logiczne organizowanie jednostek, ułatwiają zarządzanie dostępem do danych przy użyciu list kontroli dostępu i można usunąć całą tabelę przy użyciu jednej operacji magazynowania.
Partycje tabel
Nazwa konta, nazwa tabeli i klucz partycji razem identyfikują partycję w usłudze magazynu, w której usługa tabel przechowuje jednostkę. Oprócz bycia częścią schematu adresowania dla jednostek partycje definiują zakres transakcji (zobacz Transakcje grupy jednostek poniżej) i stanowią podstawę skalowania usługi tabeli. Aby uzyskać więcej informacji na temat partycji, zobacz Lista kontrolna wydajności i skalowalności dla usługi Table Storage.
W usłudze Table Service poszczególne węzły usług co najmniej jedną kompletną partycję, a usługa jest skalowana dynamicznie przez partycje równoważenia obciążenia między węzłami. Jeśli węzeł jest obciążony, usługa tabeli może podzielić zakres partycji obsłużonych przez ten węzeł na różne węzły. Gdy ruch ustąpi, usługa może scalić zakresy partycji z węzłów cichych z powrotem na jeden węzeł.
Aby uzyskać więcej informacji na temat wewnętrznych szczegółów usługi Table Service, a w szczególności sposobu zarządzania partycjami przez usługę, zobacz artykuł Microsoft Azure Storage: usługa magazynu w chmurze o wysokiej dostępności z silną spójnością.
Transakcje grupy jednostek
W usłudze Table Service transakcje grupy jednostek (EGT) są jedynym wbudowanym mechanizmem wykonywania aktualizacji niepodzielnych w wielu jednostkach. EgTs są czasami nazywane również transakcjami wsadowymi. Egts mogą działać tylko na jednostkach przechowywanych w tej samej partycji (czyli współużytkować ten sam klucz partycji w danej tabeli). Dlatego zawsze, gdy wymagane jest niepodzielne zachowanie transakcyjne w wielu jednostkach, należy upewnić się, że te jednostki znajdują się w tej samej partycji. Jest to często przyczyna przechowywania wielu typów jednostek w tej samej tabeli (i partycji), a nie używania wielu tabel dla różnych typów jednostek. Pojedynczy EGT może działać na co najwyżej 100 jednostkach. W przypadku przesyłania wielu współbieżnych żądań EGT do przetwarzania ważne jest, aby upewnić się, że te elementy EGT nie działają na jednostkach wspólnych dla sieci EGT; w przeciwnym razie przetwarzanie może być opóźnione.
Egts wprowadza również potencjalne kompromisy, które można ocenić w projekcie. Oznacza to, że użycie większej liczby partycji zwiększa skalowalność aplikacji, ponieważ platforma Azure ma większe możliwości równoważenia obciążenia żądań między węzłami. Jednak użycie większej liczby partycji może ograniczyć możliwość wykonywania niepodzielnych transakcji przez aplikację i utrzymania silnej spójności danych. Ponadto istnieją określone cele skalowalności na poziomie partycji, które mogą ograniczyć przepływność transakcji, których można oczekiwać dla jednego węzła. Aby uzyskać więcej informacji na temat celów skalowalności dla kont magazynu w warstwie Standardowa platformy Azure, zobacz Cele skalowalności dla kont magazynu w warstwie Standardowa. Aby uzyskać więcej informacji na temat celów skalowalności dla usługi Table Service, zobacz Cele skalowalności i wydajności dla usługi Table Storage.
Zagadnienia dotyczące pojemności
W poniższej tabeli opisano elementy docelowe pojemności, skalowalności i wydajności dla magazynu tabel.
| Zasób | Cel |
|---|---|
| Liczba tabel na koncie magazynu platformy Azure | Ograniczona tylko pojemnością konta magazynu |
| Liczba partycji w tabeli | Ograniczona tylko pojemnością konta magazynu |
| Liczba jednostek w partycji | Ograniczona tylko pojemnością konta magazynu |
| Maksymalny rozmiar pojedynczej tabeli | 500 TiB |
| Maksymalny rozmiar pojedynczej jednostki, w tym wszystkie wartości właściwości | 1 MiB |
| Maksymalna liczba właściwości w jednostce tabeli | 255 (w tym trzy właściwości systemu: PartitionKey, RowKey i Timestamp) |
| Maksymalny łączny rozmiar pojedynczej właściwości w jednostce | Różni się w zależności od typu właściwości. Aby uzyskać więcej informacji, zobacz sekcję Typy właściwości w artykule Omówienie modelu danych usługi Table Service. |
| Rozmiar właściwości PartitionKey | Ciąg o rozmiarze do 1024 znaków |
| Rozmiar właściwości RowKey | Ciąg o rozmiarze do 1024 znaków |
| Rozmiar transakcji grupy jednostek | Transakcja może obejmować maksymalnie 100 jednostek, a rozmiar ładunku musi być mniejszy niż 4 MiB. Transakcja grupy jednostek może zawierać aktualizację jednostki tylko jeden raz. |
| Maksymalna liczba przechowywanych zasad dostępu na tabelę | 5 |
| Maksymalna częstotliwość żądań na konto magazynu | 20 000 transakcji na sekundę przy założeniu, że jednostki mają rozmiar 1 KiB |
| Docelowa przepływność dla pojedynczej partycji tabeli (jednostki o rozmiarze 1 KiB) | Do 2 000 jednostek na sekundę |
Kwestie związane z kosztami
Magazyn tabel jest stosunkowo niedrogi, ale należy uwzględnić oszacowania kosztów zarówno dla użycia pojemności, jak i ilości transakcji w ramach oceny dowolnego rozwiązania usługi Table Service. Jednak w wielu scenariuszach przechowywanie zdenormalizowanych lub zduplikowanych danych w celu zwiększenia wydajności lub skalowalności rozwiązania jest prawidłowym podejściem. Aby uzyskać więcej informacji na temat cen, zobacz Cennik usługi Azure Storage.