Lista kontrolna wydajności i skalowalności dla usługi Table Storage

Firma Microsoft opracowała wiele sprawdzonych rozwiązań dotyczących tworzenia aplikacji o wysokiej wydajności za pomocą usługi Table Storage. Ta lista kontrolna identyfikuje kluczowe rozwiązania, które deweloperzy mogą stosować, aby zoptymalizować wydajność. Należy pamiętać o tych praktykach podczas projektowania aplikacji i całego procesu.

Usługa Azure Storage ma cele dotyczące skalowalności i wydajności dla pojemności, szybkości transakcji i przepustowości. Aby uzyskać więcej informacji na temat celów skalowalności usługi Azure Storage, zobacz Cele skalowalności i wydajności dla standardowych kont magazynu oraz Cele skalowalności i wydajności dla usługi Table Storage.

Lista kontrolna

Ten artykuł organizuje sprawdzone rozwiązania dotyczące wydajności na liście kontrolnej, którą można śledzić podczas tworzenia aplikacji przechowywania tabeli.

Cele skalowalności

Jeśli aplikacja zbliża się lub przekracza jakiekolwiek cele skalowalności, może wystąpić zwiększone opóźnienia transakcji lub ograniczanie przepustowości. Gdy usługa Azure Storage ogranicza aplikację, usługa zaczyna zwracać kody błędów 503 (serwer zajęty) lub 500 (limit czasu operacji). Unikanie tych błędów, pozostając w granicach celów skalowalności, jest ważną częścią zwiększania wydajności aplikacji.

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.

Maksymalna liczba kont magazynu

Jeśli zbliżasz się do maksymalnej liczby kont magazynu dozwolonych dla określonej kombinacji subskrypcji/regionu, czy używasz wielu kont magazynu do fragmentowania w celu zwiększenia liczby operacji ruchu przychodzącego, ruchu wychodzącego, operacji we/wy na sekundę (IOPS) lub pojemności? W tym scenariuszu firma Microsoft zaleca skorzystanie ze zwiększonych limitów dla kont magazynowych, aby zredukować liczbę wymaganych kont dla obciążenia roboczego, jeśli to możliwe. Skontaktuj się z Azure Support, aby poprosić o zwiększenie limitów dla Twojego konta magazynowego.

Cele dotyczące pojemności i transakcji

Jeśli aplikacja zbliża się do limitów skalowalności dla pojedynczego konta magazynowania, rozważ przyjęcie jednego z następujących podejść:

• Rozważ obciążenie, które powoduje, że aplikacja zbliża się lub przekracza cel skalowalności. Czy można zaprojektować ją inaczej, aby używać mniejszej przepustowości lub pojemności, czy mniejszej liczby transakcji?
• Jeśli aplikacja musi przekroczyć jeden z celów skalowalności, utwórz wiele kont magazynu i podziel dane aplikacji na te wiele kont magazynu. Jeśli używasz tego wzorca, pamiętaj, aby zaprojektować aplikację w taki sposób, aby w przyszłości można było dodać więcej kont magazynowania na potrzeby równoważenia obciążenia. Same konta przechowywania nie generują żadnych kosztów, poza tymi związanymi z użyciem w zakresie przechowywanych danych, dokonanych transakcji albo przesyłania danych.
• Jeśli aplikacja zbliża się do celów przepustowości, rozważ kompresowanie danych po stronie klienta, aby zmniejszyć przepustowość wymaganą do wysłania danych do usługi Azure Storage. Kompresowanie danych może zmniejszyć przepustowość i zwiększyć wydajność sieci, ale może również mieć negatywny wpływ na wydajność. Oceń wpływ wydajności dodatkowych wymagań dotyczących przetwarzania na kompresję i dekompresję danych po stronie klienta. Należy pamiętać, że przechowywanie skompresowanych danych może utrudnić rozwiązywanie problemów, ponieważ wyświetlenie danych przy użyciu standardowych narzędzi może być trudniejsze.
• Jeśli aplikacja zbliża się do celów skalowalności, upewnij się, że używasz wykładniczego wycofywania dla ponownych prób. Najlepiej jest spróbować uniknąć osiągnięcia celów skalowalności przez zaimplementowanie zaleceń opisanych w tym artykule. Jednak użycie wycofywania wykładniczego w przypadku ponownych prób uniemożliwi aplikacji szybkie ponawianie próby, co może pogorszyć ograniczanie przepustowości. Aby uzyskać więcej informacji, zobacz sekcję zatytułowaną Błędy Timeout i Serwer zajęty.

Cele dla operacji na danych

Obciążenie usługi Azure Storage równoważy się wraz ze wzrostem ruchu do konta magazynu, ale jeśli występują nagłe skoki ruchu, możesz nie uzyskać tej ilości przepustowości natychmiast. Spodziewaj się ograniczeń przepustowości i/lub przekroczeń limitu czasu podczas intensywnego okresu, ponieważ usługa Azure Storage automatycznie równoważy obciążenie tabeli. Powolne zwiększanie przynosi lepsze rezultaty, ponieważ system ma czas na właściwe równoważenie obciążenia.

Jednostki na sekundę (konto magazynowe)

Limit skalowalności na potrzeby uzyskiwania dostępu do tabel wynosi do 20 000 jednostek (1 KB każdy) na sekundę dla konta. Ogólnie rzecz biorąc, każda jednostka, która jest wstawiana, aktualizowana, usuwana lub skanowana, liczy się w stosunku do tego celu. Dlatego wstawka wsadowa zawierająca 100 jednostek będzie liczyć 100 jednostek. Zapytanie, które skanuje 1000 jednostek i zwraca 5, będzie liczyło 1000 jednostek.

Encje na sekundę (partycja)

W ramach jednej partycji cel skalowalności na potrzeby uzyskiwania dostępu do tabel to 2000 jednostek (1 KB każdy) na sekundę przy użyciu tego samego zliczania, co opisano w poprzedniej sekcji.

Networkowanie

Ograniczenia sieci fizycznej aplikacji mogą mieć znaczący wpływ na wydajność. W poniższych sekcjach opisano niektóre ograniczenia, które mogą napotkać użytkownicy.

Możliwości sieciowe klienta

Przepustowość i jakość łącza sieciowego odgrywają ważne role w wydajności aplikacji, zgodnie z opisem w poniższych sekcjach.

Przepustowość

W przypadku przepustowości problem często dotyczy możliwości klienta. Większe instancje platformy Azure mają interfejsy sieciowe o większej przepustowości, dlatego należy rozważyć użycie większej instancji lub większej liczby maszyn wirtualnych, jeśli potrzebujesz wyższych limitów sieci dla pojedynczej maszyny. Jeśli uzyskujesz dostęp do usługi Azure Storage z poziomu aplikacji lokalnej, ta sama reguła ma zastosowanie: poznaj możliwości sieciowe urządzenia klienckiego i łączność sieciową z lokalizacją usługi Azure Storage, a następnie ulepsz je zgodnie z potrzebami lub zaprojektuj aplikację tak, aby działała w ramach swoich możliwości.

Jakość łącza

Podobnie jak w przypadku dowolnego użycia sieci, należy pamiętać, że warunki sieciowe powodujące błędy i utrata pakietów spowalnia efektywną przepływność. Użycie narzędzia WireShark lub NetMon może pomóc w diagnozowaniu tego problemu.

Lokalizacja

W dowolnym środowisku rozproszonym umieszczenie klienta w pobliżu serwera zapewnia najlepszą wydajność. Aby uzyskać dostęp do usługi Azure Storage z najniższym opóźnieniem, najlepszą lokalizacją dla klienta jest w tym samym regionie świadczenia usługi Azure. Jeśli na przykład masz aplikację internetową platformy Azure korzystającą z usługi Azure Storage, znajdź je w jednym regionie, takim jak Zachodnie stany USA lub Azja Południowo-Wschodnia. Współlokowanie zasobów zmniejsza opóźnienie i koszt, ponieważ użycie przepustowości w jednym regionie jest bezpłatne.

Jeśli aplikacje klienckie będą uzyskiwać dostęp do usługi Azure Storage, ale nie są hostowane na platformie Azure, takie jak aplikacje urządzeń przenośnych lub lokalne usługi przedsiębiorstwa, lokalizowanie konta magazynu w regionie zbliżonym do tych klientów może zmniejszyć opóźnienie. Jeśli klienci są szeroko rozproszeni (na przykład niektórzy w Ameryce Północnej i niektórzy w Europie), rozważ użycie jednego konta magazynowego na region. Takie podejście jest łatwiejsze do zaimplementowania, jeśli dane przechowywane przez aplikację są dedykowane poszczególnym użytkownikom i nie wymagają replikowania danych między kontami przechowywania.

SAS i CORS

Załóżmy, że musisz autoryzować kod, taki jak JavaScript uruchomiony w przeglądarce internetowej użytkownika lub w aplikacji na telefon komórkowy, aby uzyskać dostęp do danych w usłudze Azure Storage. Jednym z podejść jest utworzenie aplikacji usługi, która działa jako serwer proxy. Urządzenie użytkownika uwierzytelnia się w usłudze, co z kolei autoryzuje dostęp do zasobów usługi Azure Storage. W ten sposób można uniknąć ujawniania kluczy konta magazynowego na niezabezpieczonych urządzeniach. Jednak takie podejście powoduje znaczne obciążenie aplikacji usługi, ponieważ wszystkie dane przesyłane między urządzeniem użytkownika a usługą Azure Storage muszą przechodzić przez aplikację usługi.

Możesz uniknąć używania aplikacji usługi jako serwera proxy dla usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS). Używając SAS, możesz umożliwić urządzeniu użytkownika bezpośrednie wykonywanie żądań do Azure Storage, korzystając z ograniczonego tokenu dostępu. Na przykład, jeśli użytkownik chce przesłać zdjęcie do Twojej aplikacji, aplikacja usługi może wygenerować SAS i wysłać go na urządzenie użytkownika. Token SAS może udzielić uprawnień do zapisu w zasobie usługi Azure Storage przez określony czas, po czym token SAS wygaśnie. Aby uzyskać więcej informacji na temat sygnatur dostępu współdzielonego, zobacz Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS).

Zazwyczaj przeglądarka internetowa nie zezwala na używanie języka JavaScript na stronie hostowanej przez witrynę internetową w jednej domenie w celu wykonywania pewnych operacji, takich jak operacje zapisu, do innej domeny. Znane jako zasady tego samego źródła, te zasady uniemożliwiają złośliwemu skryptowi na jednej stronie uzyskanie dostępu do danych na innej stronie internetowej. Jednak zasady tego samego źródła mogą być ograniczeniem podczas tworzenia rozwiązania w chmurze. Współużytkowanie zasobów między źródłami (CORS) to funkcja przeglądarki, która umożliwia domenie docelowej komunikowanie się z przeglądarką, która ufa żądaniom pochodzącym z domeny źródłowej.

Załóżmy na przykład, że aplikacja internetowa działająca na platformie Azure wysyła żądanie dotyczące zasobu do konta usługi Azure Storage. Aplikacja internetowa jest domeną źródłową, a konto przechowywania jest domeną docelową. Możesz skonfigurować mechanizm CORS dla dowolnej usługi Azure Storage, aby przekazać przeglądarce internetowej, że żądania z domeny źródłowej są akceptowane przez Azure Storage. Aby uzyskać więcej informacji na temat mechanizmu CORS, zobacz Obsługa współużytkowania zasobów między źródłami (CORS) dla usługi Azure Storage.

Zarówno SAS, jak i mechanizm CORS mogą pomóc uniknąć niepotrzebnego obciążenia aplikacji internetowej.

Transakcje wsadowe

Usługa Table obsługuje transakcje wsadowe dla jednostek, które znajdują się w tej samej tabeli i należą do tej samej grupy partycji. Aby uzyskać więcej informacji, zobacz Wykonywanie transakcji grupy jednostek.

Konfiguracja platformy .NET

W przypadku projektów korzystających z programu .NET Framework w tej sekcji wymieniono niektóre szybkie ustawienia konfiguracji, których można użyć do wprowadzania znaczących ulepszeń wydajności. Jeśli używasz języka innego niż .NET, sprawdź, czy podobne pojęcia mają zastosowanie w wybranym języku.

Zwiększanie domyślnego limitu połączeń

W przypadku projektów korzystających z programu .NET Framework można użyć następującego kodu, aby zwiększyć domyślny limit połączeń (zazwyczaj 2 w środowisku klienta lub 10 w środowisku serwera) do 100. Zazwyczaj należy ustawić wartość na około liczbę wątków używanych przez aplikację. Ustaw limit połączenia przed otwarciem jakichkolwiek połączeń.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)  

Aby dowiedzieć się więcej na temat limitów puli połączeń w programie .NET Framework, zobacz Limity puli połączeń programu .NET Framework i nowy zestaw Azure SDK dla platformy .NET.

Aby zapoznać się z innymi językami programowania, zobacz dokumentację, aby określić sposób ustawiania limitu połączeń.

Zwiększ minimalną liczbę wątków

Jeśli używasz wywołań synchronicznych wraz z zadaniami asynchronicznymi, możesz zwiększyć liczbę wątków w puli wątków:

ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)  

Aby uzyskać więcej informacji, zobacz metodę ThreadPool.SetMinThreads .

Nieograniczona równoległość

Chociaż równoległość może być doskonała dla wydajności, należy zachować ostrożność przy użyciu nieograniczonej równoległości, co oznacza brak limitu na liczbę wątków lub żądań równoległych. Pamiętaj, aby ograniczyć równoległe żądania dotyczące przekazywania lub pobierania danych oraz dostępu do wielu partycji na tym samym koncie magazynu lub wielu elementów w tej samej partycji. Jeśli równoległość jest nieograniczona, aplikacja może przekroczyć możliwości urządzenia klienckiego lub cele skalowalności konta storage, co powoduje dłuższe opóźnienia i ograniczanie przepustowości.

Biblioteki i narzędzia klienckie

Aby uzyskać najlepszą wydajność, zawsze używaj najnowszych bibliotek klienckich i narzędzi udostępnianych przez firmę Microsoft. Biblioteki klienta usługi Azure Storage są dostępne dla różnych języków. Usługa Azure Storage obsługuje również program PowerShell i interfejs wiersza polecenia platformy Azure. Firma Microsoft aktywnie opracowuje te biblioteki i narzędzia klienckie z myślą o wydajności, utrzymuje je na bieżąco z najnowszymi wersjami usług i zapewnia, że obsługują one wiele sprawdzonych praktyk wydajności wewnętrznie.

Obsługa błędów usługi

Usługa Azure Storage zwraca błąd, gdy usługa nie może przetworzyć żądania. Zrozumienie błędów zwracanych przez usługę Azure Storage w danym scenariuszu jest pomocne w optymalizacji wydajności.

Przekroczenie limitu czasu i błędy przeciążenia serwera

Usługa Azure Storage może ograniczyć przepustowość aplikacji, jeśli zbliża się do limitów skalowalności. W niektórych przypadkach usługa Azure Storage może nie być w stanie obsłużyć żądania z powodu niektórych przejściowych warunków. W obu przypadkach usługa może zwrócić błąd 503 (serwer zajęty) lub 500 (przekroczenie limitu czasu). Te błędy mogą również wystąpić, jeśli usługa ponownie równoważy partycje danych, aby zapewnić większą przepływność. Aplikacja kliencka powinna zwykle ponowić próbę wykonania operacji, która powoduje jeden z tych błędów. Jeśli jednak usługa Azure Storage ogranicza aplikację, ponieważ przekracza cele skalowalności, a nawet jeśli usługa nie mogła obsłużyć żądania z jakiegoś innego powodu, agresywne ponawianie prób może pogorszyć problem. Zaleca się używanie polityki ponawiania z wykładniczym opóźnieniem, a biblioteki klienckie mają domyślnie to zachowanie. Na przykład aplikacja może ponowić próbę po 2 sekundach, a następnie 4 sekundy, a następnie 10 sekund, a następnie 30 sekund, a następnie całkowicie zrezygnować. W ten sposób aplikacja znacznie zmniejsza obciążenie usługi, a nie zaostrza zachowanie, które może prowadzić do ograniczenia przepustowości.

Błędy łączności można ponawiać natychmiast, ponieważ nie są wynikiem ograniczania przepustowości i powinny być przejściowe.

Błędy niepodlegające ponawianiu prób

Biblioteki klienckie obsługują ponawianie prób z świadomością, które błędy można ponowić i których nie można. Jeśli jednak bezpośrednio wywołujesz interfejs API REST usługi Azure Storage, występują pewne błędy, których nie należy ponawiać. Na przykład błąd 400 (nieprawidłowe żądanie) wskazuje, że aplikacja kliencka wysłała żądanie, którego nie można przetworzyć, ponieważ nie była w oczekiwanym formularzu. Ponowne wysyłanie tego żądania powoduje wykonanie tej samej odpowiedzi za każdym razem, więc nie ma sensu ponawiania próby. Jeśli bezpośrednio wywołujesz interfejs API REST usługi Azure Storage, pamiętaj o potencjalnych błędach i o tym, czy należy je ponowić.

Aby uzyskać więcej informacji na temat kodów błędów usługi Azure Storage, zobacz Kody stanu i błędów.

Konfiguracja

W tej sekcji wymieniono kilka szybkich ustawień konfiguracji, których można użyć w celu wprowadzenia znaczących ulepszeń wydajności w usłudze Table Service:

Korzystanie z formatu JSON

Począwszy od wersji 2013-08-15 usługi przechowywania, usługa tabeli obsługuje używanie formatu JSON zamiast formatu AtomPub opartego na XML do przesyłania danych tabeli. Użycie formatu JSON może zmniejszyć rozmiary ładunków nawet o 75% i znacznie poprawić wydajność aplikacji.

Aby uzyskać więcej informacji, zobacz wpis Microsoft Azure Tables: Introducing JSON and Payload Format for Table Service Operations ( Tabele platformy Microsoft Azure: wprowadzenie do formatu JSON i format ładunku dla operacji usługi Table Service).

Wyłącz algorytm Nagle'a

Algorytm Nagle jest szeroko implementowany w sieciach TCP/IP jako środek zwiększający wydajność sieci. Jednak nie jest to optymalne we wszystkich okolicznościach (takich jak środowiska wysoce interakcyjne). Algorytm Nagle ma negatywny wpływ na wydajność żądań do usługi Azure Table Service i należy go wyłączyć, jeśli to możliwe.

Schemat

Sposób reprezentowania i wykonywania zapytań dotyczących danych jest największym pojedynczym czynnikiem wpływającym na wydajność usługi Table Service. Chociaż każda aplikacja jest inna, w tej sekcji opisano niektóre ogólne sprawdzone rozwiązania, które odnoszą się do:

• Projekt tabeli
• Wydajne zapytania
• Wydajne aktualizacje danych

Tabele i partycje

Tabele są podzielone na partycje. Każdy element przechowywany w partycji ma ten sam klucz partycji i unikatowy klucz wiersza, który identyfikuje go w ramach tej partycji. Partycje zapewniają korzyści, ale także wprowadzają limity skalowalności.

• Korzyści: Jednostki w tej samej partycji można zaktualizować w jednej, niepodzielnej transakcji wsadowej, która zawiera do 100 oddzielnych operacji przechowywania (limit całkowitego rozmiaru to 4 MB). Zakładając, że ta sama liczba obiektów jest pobierana, można również wykonywać zapytania dotyczące danych w ramach jednej partycji bardziej efektywnie niż danych obejmujących wiele partycji (przeczytaj dalej wskazówki dotyczące zapytań danych tabel).
• Limit skalowalności: dostęp do elementów przechowywanych w jednej partycji nie może być zrównoważony pod względem obciążenia, ponieważ partycje obsługują atomowe transakcje wsadowe. Z tego powodu docelowa skalowalność dla pojedynczej partycji tabeli jest niższa niż w przypadku usługi Table Service jako całości.

Ze względu na te cechy tabel i partycji należy przyjąć następujące zasady projektowania:

• Znajdź dane, które aplikacja kliencka często aktualizuje lub wykonuje zapytania w tej samej jednostce logicznej pracy w tej samej partycji. Na przykład znajdź dane w tej samej partycji, jeśli aplikacja agreguje zapisy lub wykonujesz niepodzielne operacje wsadowe. Ponadto dane w jednej partycji mogą być wydajniej odpytywane w jednym zapytaniu niż dane w partycjach.
• Zlokalizuj dane, które aplikacja kliencka nie wstawia, aktualizuje ani wykonuje zapytań w tej samej jednostce logicznej pracy (czyli w ramach pojedynczej kwerendy lub aktualizacji wsadowej) w oddzielnych partycjach. Należy pamiętać, że nie ma limitu liczby kluczy partycji w jednej tabeli, więc posiadanie milionów kluczy partycji nie jest problemem i nie będzie miało wpływu na wydajność. Jeśli na przykład aplikacja jest popularną witryną internetową z logowaniem użytkownika, użycie identyfikatora użytkownika jako klucza partycji może być dobrym wyborem.

Gorące partycje

Gorąca partycja to taka, która otrzymuje nieproporcjonalnie duży procent ruchu do danego konta i nie może być zrównoważona pod względem obciążenia, ponieważ jest to pojedyncza partycja. Ogólnie rzecz biorąc, gorące partycje są tworzone na jeden z dwóch sposobów:

Tylko dołączanie i tylko dodawanie na początku wzorców

Wzorzec "Tylko dołączanie" jest taki, w którym cały (lub prawie cały) ruch przypisany do danego klucza partycji zwiększa się i zmniejsza w zależności od aktualnego czasu. Załóżmy na przykład, że aplikacja używa bieżącej daty jako klucza partycji dla danych dziennika. Projekt ten powoduje, że wszystkie dane do wstawienia trafiają do ostatniej partycji tabeli, a system nie może prawidłowo rozmieszczać obciążenia. Jeśli ilość ruchu do tej partycji przekracza docelową skalowalność na poziomie partycji, powoduje to ograniczenie przepustowości. Lepiej jest upewnić się, że ruch jest wysyłany do wielu partycji, aby umożliwić równoważenie obciążenia żądań w całej tabeli.

Dane o dużym natężeniu ruchu

Jeśli schemat partycjonowania powoduje, że pojedyncza partycja zawiera tylko dane, które są znacznie bardziej używane niż inne partycje, możesz zauważyć ograniczenia wydajności, ponieważ ta partycja zbliża się do limitu skalowalności dla pojedynczej partycji. Lepiej jest upewnić się, że schemat partycjonowania nie powoduje, że którakolwiek z partycji zbliża się do celów skalowalności.

Wykonywanie zapytania

W tej sekcji opisano sprawdzone rozwiązania dotyczące wykonywania zapytań dotyczących usługi Table Service.

Zakres zapytania

Istnieje kilka sposobów określania zakresu jednostek do wykonywania zapytań. Poniższa lista zawiera opis każdej opcji dla zakresu zapytań.

• Zapytania dotyczące punktów: zapytanie punktu pobiera dokładnie jedną jednostkę, określając zarówno klucz partycji, jak i klucz wiersza jednostki do pobrania. Te zapytania są wydajne i należy ich używać wszędzie tam, gdzie to możliwe.
• Zapytania partycji: Zapytanie partycji to takie, które pobiera zestaw danych dzielących wspólny klucz partycji. Zazwyczaj zapytanie określa zakres wartości klucza wiersza lub zakres wartości dla niektórych właściwości jednostki oprócz klucza partycji. Te zapytania są mniej wydajne niż zapytania punktowe i powinny być używane oszczędnie.
• Zapytania dotyczące tabel: Zapytanie tabeli to zapytanie, które pobiera zestaw jednostek, które nie współużytkuje wspólnego klucza partycji. Te zapytania nie są wydajne i należy je unikać, jeśli to możliwe.

Ogólnie rzecz biorąc, unikaj skanowania (zapytania większe niż pojedyncza jednostka), ale jeśli musisz skanować, spróbuj zorganizować dane, aby skanowanie pobierało potrzebne dane bez skanowania lub zwracania znaczących ilości jednostek, których nie potrzebujesz.

Gęstość zapytań

Innym kluczowym czynnikiem wydajności zapytań jest liczba jednostek zwracanych w porównaniu z liczbą skanowanych jednostek w celu znalezienia zwróconego zestawu. Jeśli Twoja aplikacja wykonuje zapytanie tabeli z filtrem dla wartości właściwości, którą dzieli tylko 1% danych, to zapytanie skanuje 100 jednostek dla każdej jednostki, którą zwraca. Omówione wcześniej cele skalowalności tabeli odnoszą się do liczby skanowanych jednostek, a nie liczby zwracanych jednostek: niska gęstość zapytań może łatwo spowodować ograniczenie przepustowości aplikacji przez usługę Table Service, ponieważ musi skanować tak wiele jednostek, aby pobrać żądaną jednostkę. Aby uzyskać więcej informacji na temat unikania ograniczania przepustowości, zobacz sekcję zatytułowaną Denormalizacja.

Ograniczanie ilości zwracanych danych

Gdy wiesz, że zapytanie zwraca jednostki, których nie potrzebujesz w aplikacji klienckiej, rozważ użycie filtru w celu zmniejszenia rozmiaru zwróconego zestawu. Chociaż jednostki, które nie zostały zwrócone do klienta, nadal są liczone w kierunku limitów skalowalności, wydajność aplikacji poprawia się z powodu zmniejszonego rozmiaru ładunku sieci i zmniejszonej liczby jednostek, które musi przetworzyć aplikacja kliencka. Należy pamiętać, że cele skalowalności odnoszą się do liczby skanowanych jednostek, więc zapytanie, które filtruje wiele jednostek, może nadal powodować ograniczanie przepustowości, nawet jeśli zwraca się kilka jednostek. Aby uzyskać więcej informacji na temat wydajnego wykonywania zapytań, zobacz sekcję zatytułowaną Gęstość zapytań.

Jeśli aplikacja kliencka potrzebuje tylko ograniczonego zestawu właściwości z jednostek w tabeli, możesz użyć projekcji, aby ograniczyć rozmiar zwracanego zestawu danych. Podobnie jak w przypadku filtrowania, projekcja pomaga zmniejszyć obciążenie sieci i przetwarzanie klientów.

Denormalizacja

W przeciwieństwie do pracy z relacyjnymi bazami danych sprawdzone rozwiązania dotyczące wydajnego wykonywania zapytań dotyczących danych tabeli prowadzą do denormalizacji danych. Oznacza to, że duplikowanie tych samych danych w wielu jednostkach (po jednym dla każdego klucza, którego można użyć do znalezienia danych), aby zminimalizować liczbę jednostek, które zapytanie musi skanować w celu znalezienia danych, których potrzebuje klient, zamiast skanowania dużej liczby jednostek w celu znalezienia danych potrzebnych aplikacji. Na przykład w witrynie internetowej handlu elektronicznego możesz znaleźć zamówienie zarówno po identyfikatorze klienta (pokaż mi zamówienia tego klienta), jak i po dacie (pokaż mi zamówienia z danego dnia). W usłudze Table Storage najlepiej jest przechowywać jednostkę (lub odwołanie do niej) dwa razy — raz z nazwą tabeli, PK i RK w celu ułatwienia znajdowania według identyfikatora klienta, raz w celu ułatwienia znalezienia według daty.

Wstawianie, aktualizowanie i usuwanie

W tej sekcji opisano sprawdzone rozwiązania dotyczące modyfikowania jednostek przechowywanych w usłudze Table Service.

Pakietowanie

W Azure Storage transakcje wsadowe nazywane są transakcjami grup jednostek. Wszystkie operacje w ramach transakcji grupy jednostek muszą znajdować się na jednej partycji w jednej tabeli. Jeśli to możliwe, użyj transakcji grupy jednostek, aby wykonać operacje wstawiania, aktualizacji i usuwania w partiach. Użycie transakcji grupy jednostek zmniejsza liczbę komunikacji z aplikacji klienckiej do serwera, zmniejsza liczbę rozliczanych transakcji (transakcje grupy jednostek są liczone jako pojedyncza transakcja na potrzeby rozliczeń i mogą zawierać maksymalnie 100 operacji magazynowych) i umożliwia niepodzielne aktualizacje (wszystkie operacje kończą się powodzeniem lub niepowodzeniem w ramach transakcji grupy jednostek). Środowiska z dużymi opóźnieniami, takie jak urządzenia przenośne, znacznie korzystają z korzystania z transakcji grupy jednostek.

Upsert

Używaj operacji Upsert na tabelach wszędzie tam, gdzie to możliwe. Istnieją dwa typy operacji Upsert, które mogą być wydajniejsze niż tradycyjne operacje wstawiania i aktualizacji :

• InsertOrMerge: użyj tej operacji, jeśli chcesz przekazać podzbiór właściwości jednostki, ale nie masz pewności, czy jednostka już istnieje. Jeśli jednostka istnieje, to wywołanie aktualizuje właściwości uwzględnione w operacji Upsert i pozostawia wszystkie istniejące właściwości, ponieważ są, jeśli jednostka nie istnieje, wstawia nową jednostkę. Jest to podobne do używania projekcji w zapytaniu, w którym wystarczy przekazać tylko zmieniające się właściwości.
• InsertOrReplace: użyj tej operacji, jeśli chcesz przekazać zupełnie nową jednostkę, ale nie masz pewności, czy już istnieje. Użyj tej operacji, gdy wiesz, że nowo załadowana jednostka jest całkowicie poprawna, ponieważ zastępuje starą jednostkę w pełni. Na przykład chcesz zaktualizować jednostkę, która przechowuje bieżącą lokalizację użytkownika niezależnie od tego, czy aplikacja wcześniej przechowywała dane lokalizacji dla użytkownika; nowa jednostka lokalizacji została ukończona i nie potrzebujesz żadnych informacji z żadnej poprzedniej jednostki.

Przechowywanie serii danych w jednej jednostce

Czasami aplikacja przechowuje serię danych, które często muszą pobierać jednocześnie: na przykład aplikacja może śledzić użycie procesora CPU w czasie, aby wykreślić wykres kroczący danych z ostatnich 24 godzin. Jednym z podejść jest posiadanie jednej tabeli na godzinę, z każdą tabelą reprezentującą określoną godzinę i przechowującą wykorzystanie procesora dla tej godziny. Aby wykreślić te dane, aplikacja musi pobrać jednostki zawierające dane z ostatnich 24 godzin.

Alternatywnie aplikacja może przechowywać użycie procesora CPU dla każdej godziny jako oddzielną właściwość pojedynczej jednostki: aby zaktualizować każdą godzinę, aplikacja może użyć pojedynczego wywołania InsertOrMerge Upsert , aby zaktualizować wartość dla ostatniej godziny. Aby wykreślić dane, aplikacja musi pobrać tylko jedną encję zamiast 24, co zapewnia wydajność zapytania. Aby uzyskać więcej informacji na temat wydajności zapytań, zobacz sekcję zatytułowaną Zakres zapytania.

Przechowywanie danych strukturalnych w obiektach blob

Jeśli wykonujesz wstawianie wsadowe, a następnie pobierasz zakresy jednostek razem, rozważ użycie obiektów blob zamiast tabel. Dobrym przykładem jest plik dziennika. Możesz przetwarzać wsadowo kilka minut dzienników i wstawić je, a następnie pobierać kilka minut dzienników naraz. W takim przypadku wydajność jest lepsza, jeśli używasz obiektów blob zamiast tabel, ponieważ można znacznie zmniejszyć liczbę obiektów zapisywanych do lub odczytywanych, a także ewentualnie liczbę żądań, które są wymagane.

Następne kroki

• Cele dotyczące skalowalności i wydajności dla usługi Table Storage
• Cele skalowalności i wydajności dla standardowych kont magazynowych
• kody stanu i błędów