Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Rozwiązania usługi Table Service mogą być intensywnie odczytywane, intensywnie korzystające z zapisu lub mieszane. Ten artykuł koncentruje się na kwestiach, które należy wziąć pod uwagę podczas projektowania usługi Table Service w celu wydajnego obsługi operacji odczytu. Zazwyczaj projekt, który efektywnie obsługuje operacje odczytu, jest również wydajny w przypadku operacji zapisu. Jednak podczas projektowania operacji zapisu należy wziąć pod uwagę dodatkowe kwestie, które opisano w artykule Projektowanie modyfikacji danych.
Dobrym punktem wyjścia do projektowania rozwiązania usługi Table Service w celu umożliwienia wydajnego odczytywania danych jest pytanie "Jakie zapytania będą musiały zostać wykonane przez moją aplikację, aby pobrać potrzebne dane z usługi Table Service?"
Uwaga
W przypadku usługi Table Service ważne jest, aby projekt został poprawiony z góry, ponieważ jego zmiana jest trudna i kosztowna później. Na przykład w relacyjnej bazie danych często można rozwiązać problemy z wydajnością, dodając indeksy do istniejącej bazy danych: nie jest to opcja w usłudze Table Service.
Ta sekcja koncentruje się na kluczowych problemach, które należy rozwiązać podczas projektowania tabel na potrzeby wykonywania zapytań. Tematy omówione w tej sekcji obejmują:
- Jak wybór opcji PartitionKey i RowKey wpływa na wydajność zapytań
- Wybieranie odpowiedniego klucza partycji
- Optymalizowanie zapytań dla usługi Table Service
- Sortowanie danych w usłudze Table Service
Jak wybór opcji PartitionKey i RowKey wpływa na wydajność zapytań
W poniższych przykładach założono, że usługa tabel przechowuje jednostki pracowników z następującą strukturą (większość przykładów pomija właściwość Znacznik czasu dla przejrzystości).
| Nazwa kolumny | Typ danych |
|---|---|
| PartitionKey (nazwa działu) | Sznurek |
| RowKey (identyfikator pracownika) | Sznurek |
| FirstName | Sznurek |
| LastName | Sznurek |
| Wiek | Integer |
| Adres e-mail | Sznurek |
W artykule Omówienie usługi Azure Table Storage opisano niektóre kluczowe funkcje usługi Azure Table Service, które mają bezpośredni wpływ na projektowanie zapytań. W rezultacie są to następujące ogólne wytyczne dotyczące projektowania zapytań usługi Table Service. Należy pamiętać, że składnia filtru używana w poniższych przykładach pochodzi z interfejsu API REST usługi Table Service, aby uzyskać więcej informacji, zobacz Query Entities (Jednostki zapytań).
- Zapytanie punktowe jest najbardziej wydajnym wyszukiwaniem do użycia i jest zalecane do użycia w przypadku odnośników o dużej ilości lub wyszukiwań wymagających najmniejszego opóźnienia. Takie zapytanie może używać indeksów do bardzo wydajnego lokalizowania pojedynczej jednostki, określając zarówno wartości PartitionKey , jak i RowKey . Na przykład: $filter=(PartitionKey eq 'Sales') i (RowKey eq '2')
- Drugą najlepszą opcją jest zapytanie zakresowe, które używa klucza partycji i filtruje wartości w zakresie RowKey, aby zwrócić więcej niż jedną jednostkę. Wartość PartitionKey identyfikuje określoną partycję, a wartości RowKey identyfikują podzbiór jednostek w tej partycji. Na przykład: $filter=PartitionKey eq "Sales" i RowKey ge "S" i RowKey lt "T"
- Trzecim najlepszym rozwiązaniem jest skanowanie partycji używające klucza partycji i filtrów w innej właściwości innej niż klucz, która może zwrócić więcej niż jedną jednostkę. Wartość PartitionKey identyfikuje określoną partycję, a wartości właściwości wybierają podzbiór jednostek w tej partycji. Na przykład: $filter=PartitionKey eq "Sales" i LastName eq "Smith"
- Skanowanie tabeli nie uwzględnia PartitionKey i jest bardzo nieefektywne, ponieważ przeszukuje wszystkie partycje tworzące tabelę, aby znaleźć dowolne pasujące jednostki. Wykona skanowanie tabeli niezależnie od tego, czy filtr używa RowKey. Na przykład: $filter=LastName eq "Jones"
- Zapytania zwracające wiele jednostek zwracają je posortowane w kolejności PartitionKey i RowKey . Aby uniknąć przełączania jednostek w kliencie, wybierz RowKey, który definiuje najczęściej używaną kolejność sortowania.
Należy pamiętać, że użycie "lub" do określenia filtru na podstawie wartości RowKey powoduje skanowanie partycji i nie jest traktowane jako zapytanie zakresu. Dlatego należy unikać zapytań korzystających z filtrów, takich jak: $filter=PartitionKey eq "Sales" i (RowKey eq "121" lub RowKey eq "322")
Przykłady kodu po stronie klienta, który używa biblioteki klienta usługi Storage do wykonywania wydajnych zapytań, zobacz:
- Wykonywanie zapytania punktu przy użyciu biblioteki klienta usługi Storage
- Pobieranie wielu jednostek przy użyciu LINQ
- Projekcja po stronie serwera
Przykłady kodu po stronie klienta, który może obsługiwać wiele typów jednostek przechowywanych w tej samej tabeli, zobacz:
Wybieranie odpowiedniego klucza partycji
Wybór klucza PartitionKey powinien równoważyć konieczność włączenia korzystania z transakcji grupy jednostek (w celu zapewnienia spójności) względem wymagania dystrybucji jednostek na wiele partycji (w celu zapewnienia skalowalnego rozwiązania).
Z jednej strony, można przechowywać wszystkie jednostki w jednej partycji, ale może to ograniczać skalowalność rozwiązania i uniemożliwić usłudze tabeli równoważenie obciążenia żądań. W drugiej skrajności można przechowywać jedną jednostkę na partycję, co byłoby wysoce skalowalne i umożliwia usłudze tabel równoważenie obciążenia żądań, ale uniemożliwiłoby korzystanie z transakcji grupy jednostek.
Idealnym kluczem partycji jest ten , który umożliwia korzystanie z wydajnych zapytań i ma wystarczające partycje, aby upewnić się, że rozwiązanie jest skalowalne. Zazwyczaj okaże się, że Twoje jednostki mają odpowiednią cechę, która rozmieszcza je na wystarczającą liczbę partycji.
Uwaga
Na przykład w systemie, który przechowuje informacje o użytkownikach lub pracownikach, identyfikator UserID może być dobrym kluczem PartitionKey. Może istnieć kilka jednostek, które używają danego identyfikatora UserID jako klucza partycji. Każda jednostka, która przechowuje dane o użytkowniku, jest grupowana w jedną partycję, dlatego te jednostki są dostępne za pośrednictwem transakcji grupy jednostek, a jednocześnie są wysoce skalowalne.
Istnieją dodatkowe zagadnienia dotyczące wybranego klucza partycji , które odnoszą się do sposobu wstawiania, aktualizowania i usuwania jednostek. Aby uzyskać więcej informacji, zobacz Projektowanie tabel pod kątem modyfikacji danych.
Optymalizowanie zapytań dla usługi Table Service
Usługa Table Service automatycznie indeksuje jednostki przy użyciu wartości PartitionKey i RowKey w pojedynczym indeksie klastrowanym, dlatego zapytania punktowe są najbardziej wydajne. Nie ma jednak innych indeksów niż ten klastrowany na kluczu PartitionKey i RowKey.
Wiele projektów musi spełniać wymagania, aby umożliwić wyszukiwanie jednostek na podstawie wielu kryteriów. Na przykład lokalizowanie jednostek pracowników na podstawie adresu e-mail, identyfikatora pracownika lub nazwiska. Wzorce opisane w Wzorce projektowe tabel dotyczą tych typów wymagań i opisują sposoby rozwiązywania problemu, że usługa tabelowa nie zapewnia indeksów pomocniczych.
- Wzorzec indeksu pomocniczego wewnątrz partycji — przechowuj wiele kopii każdej jednostki przy użyciu różnych wartości RowKey (w tej samej partycji), aby umożliwić szybkie i wydajne wyszukiwanie oraz alternatywne kolejności sortowania.
- Wzorzec indeksu pomocniczego między partycjami — przechowuj wiele kopii każdej jednostki przy użyciu różnych wartości RowKey w oddzielnych partycjach lub w oddzielnych tabelach, aby umożliwić szybkie i wydajne wyszukiwanie i alternatywne kolejności sortowania przy użyciu różnych wartości RowKey .
- Wzorzec jednostek indeksu — obsługa jednostek indeksu w celu umożliwienia wydajnych wyszukiwań, które zwracają listy jednostek.
Sortowanie danych w usłudze Table Service
Usługa Table service zwraca jednostki posortowane w kolejności rosnącej na podstawie PartitionKey, a następnie według RowKey. Te klucze są wartościami ciągów i w celu zapewnienia poprawnego sortowania wartości liczbowych, należy przekonwertować je na stałą długość i wypełnić je zerami. Jeśli na przykład wartość identyfikatora pracownika używana jako RowKey jest wartością całkowitą, należy przekonwertować identyfikator pracownika 123 na 00000123.
Wiele aplikacji ma wymagania dotyczące używania danych posortowanych w różnych kolejnościach: na przykład sortowania pracowników według imienia lub daty zatrudnienia. Następujące wzorce dotyczą sposobu alternatywnego sortowania zamówień dla jednostek:
- Wzorzec indeksu pomocniczego wewnątrz partycji — przechowuj wiele kopii każdej jednostki przy użyciu różnych wartości RowKey (w tej samej partycji), aby umożliwić szybkie i wydajne wyszukiwanie i alternatywne zamówienia sortowania przy użyciu różnych wartości RowKey.
- Wzorzec indeksu pomocniczego między partycjami — przechowuj wiele kopii każdej jednostki przy użyciu różnych wartości RowKey w oddzielnych partycjach w oddzielnych tabelach, aby umożliwić szybkie i wydajne wyszukiwanie i alternatywne kolejności sortowania przy użyciu różnych wartości RowKey.
- Wzorzec ogona dziennika — pobierz n jednostek ostatnio dodanych do partycji przy użyciu wartości RowKey , która sortuje w odwrotnej kolejności daty i godziny.