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 kont magazynu w warstwie Standardowa 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 wykonać podczas tworzenia aplikacji usługi Table Storage.
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 korzystanie ze zwiększonych limitów dla kont magazynu w celu zmniejszenia liczby kont magazynu wymaganych do obciążenia, jeśli to możliwe. Skontaktuj się z pomocą techniczną platformy Azure, aby zażądać zwiększonych limitów dla konta magazynu.
Cele pojemności i transakcji
Jeśli aplikacja zbliża się do celów skalowalności dla pojedynczego konta magazynu, rozważ zastosowanie 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ę, aby w przyszłości dodać więcej kont magazynu na potrzeby równoważenia obciążenia. Same konta magazynu nie mają żadnych kosztów innych niż użycie pod względem przechowywanych danych, transakcji lub przesyłanych 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ą Limit czasu i Błędy zajętości serwera.
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 ruch ma nagłe wzrosty, może nie być w stanie natychmiast uzyskać tej ilości przepływności. Spodziewaj się, że ograniczanie przepustowości i/lub przekroczenia limitu czasu podczas serii, ponieważ usługa Azure Storage automatycznie równoważy obciążenie tabeli. Zwiększenie się powoli zapewnia lepsze wyniki, ponieważ system ma czas na odpowiednie równoważenie obciążenia.
Jednostki na sekundę (konto magazynu)
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.
Jednostki 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.
Sieć
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ść sieci klienta
Przepustowość i jakość łącza sieciowego odgrywają ważne role w wydajności aplikacji, zgodnie z opisem w poniższych sekcjach.
Przepływność
W przypadku przepustowości problem często dotyczy możliwości klienta. Większe wystąpienia platformy Azure mają karty sieciowe o większej pojemności, dlatego należy rozważyć użycie większego wystąpienia lub większej liczby maszyn wirtualnych, jeśli potrzebujesz wyższych limitów sieci z 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 dystrybuowani (na przykład niektórzy w Ameryka Północna i niektórzy w Europie), rozważ użycie jednego konta magazynu na region. Takie podejście jest łatwiejsze do zaimplementowania, jeśli dane przechowywane przez aplikację są specyficzne dla poszczególnych użytkowników i nie wymagają replikowania danych między kontami magazynu.
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ąć uwidaczniania kluczy konta magazynu 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). Przy użyciu sygnatury dostępu współdzielonego możesz umożliwić urządzeniu użytkownika wykonywanie żądań bezpośrednio w usłudze Azure Storage przy użyciu ograniczonego tokenu dostępu. Jeśli na przykład użytkownik chce przekazać zdjęcie do aplikacji, aplikacja usługi może wygenerować sygnaturę dostępu współdzielonego i wysłać ją na urządzenie użytkownika. Token SYGNATURy dostępu współdzielonego może udzielić uprawnień do zapisu w zasobie usługi Azure Storage przez określony interwał czasu, po upływie którego 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 magazynu jest domeną docelową. Mechanizm CORS można skonfigurować dla dowolnej usługi Azure Storage, aby komunikować się z przeglądarką internetową, która żądań z domeny źródłowej jest zaufana przez usługę 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.
Sygnatura dostępu współdzielonego i mechanizm CORS mogą pomóc uniknąć niepotrzebnego ładowania aplikacji internetowej.
Transakcje wsadowe
Usługa Table Service 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ń
Uwaga
Ta sekcja dotyczy projektów korzystających z programu .NET Framework, ponieważ buforowanie połączeń jest kontrolowane przez klasę ServicePointManager. Platforma .NET Core wprowadziła znaczącą zmianę w zarządzaniu pulą połączeń, w której buforowanie połączeń odbywa się na poziomie httpClient, a rozmiar puli nie jest domyślnie ograniczony. Oznacza to, że połączenia HTTP są automatycznie skalowane w celu zaspokojenia obciążenia. Korzystanie z najnowszej wersji platformy .NET jest zalecane, jeśli to możliwe, aby skorzystać z ulepszeń wydajności.
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 .NET Framework Połączenie ion Pool Limits and the new Azure SDK for .NET (Limity puli Połączenie ion platformy .NET) 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 .
Równoległość bez ruchu przychodzącego
Chociaż równoległość może być doskonała dla wydajności, należy zachować ostrożność przy użyciu niezwiązanego równoległości, co oznacza, że nie ma limitu wymuszanego dla liczby wątków lub żądań równoległych. Pamiętaj, aby ograniczyć równoległe żądania przekazywania lub pobierania danych, aby uzyskać dostęp do wielu partycji na tym samym koncie magazynu lub uzyskać dostęp do wielu elementów w tej samej partycji. Jeśli równoległość jest niezwiązana, aplikacja może przekroczyć możliwości urządzenia klienckiego lub cele skalowalności konta magazynu, 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 zajętości 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 zasad ponawiania wykładniczego, a biblioteki klienckie są domyślne dla tego zachowania. 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 Połączenie wydajności można natychmiast ponowić, ponieważ nie są one wynikiem ograniczania przepustowości i powinny być przejściowe.
Błędy nienależące do ponawiania 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.
Konfigurowanie
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 usługi magazynu w wersji 2013-08-15, usługa Table Service 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 ładunku o aż 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 nagle
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żda jednostka przechowywana w partycji ma ten sam klucz partycji i ma unikatowy klucz wiersza do identyfikacji w ramach tej partycji. Partycje zapewniają korzyści, ale także wprowadzenie limitów skalowalności.
- Korzyści: Jednostki w tej samej partycji można zaktualizować w jednej, niepodzielnej transakcji wsadowej zawierającej maksymalnie 100 oddzielnych operacji magazynowania (limit całkowitego rozmiaru 4 MB). Przy założeniu, że ta sama liczba jednostek do pobrania, można również wykonywać zapytania dotyczące danych w ramach jednej partycji wydajniej niż dane obejmujące partycje (choć zapoznaj się z dalszymi zaleceniami dotyczącymi wykonywania zapytań dotyczących danych tabeli).
- Limit skalowalności: dostęp do jednostek przechowywanych w jednej partycji nie może być zrównoważony, ponieważ partycje obsługują niepodzielne 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 partycja, która otrzymuje nieproporcjonalny procent ruchu do konta i nie może być zrównoważona 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 prepend tylko wzorce
Wzorzec "Tylko dołączanie" jest taki, w którym cały (lub prawie cały) ruch do danego klucza partycji zwiększa się i zmniejsza zgodnie z bieżącym czasem. Załóżmy na przykład, że aplikacja używa bieżącej daty jako klucza partycji dla danych dziennika. Ten projekt powoduje, że wszystkie wstawki przechodzą do ostatniej partycji w tabeli, a system nie może prawidłowo równoważyć 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że być również widoczne ograniczenie, ponieważ partycja zbliża się do celu skalowalności dla pojedynczej partycji. Lepiej jest upewnić się, że schemat partycji nie zwraca żadnej pojedynczej partycji zbliżającej 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 zapytanie, które pobiera zestaw danych, które współudzielą 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 aplikacja wykonuje zapytanie tabeli z filtrem dla wartości właściwości, która zawiera tylko 1% udziałów danych, zapytanie skanuje 100 jednostek dla każdej zwracanej jednostki. 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 według identyfikatora klienta (nadać mi zamówienia tego klienta) i według daty (nadaj mi zamówienia w dniu). W usłudze Table Storage najlepiej jest przechowywać jednostkę (lub odwołanie do niej) dwa razy — raz z nazwą tabeli, kluczem PK i kluczem RK w celu ułatwienia znajdowania według identyfikatora klienta, raz w celu ułatwienia znalezienia go do daty.
Wstawianie, aktualizowanie i usuwanie
W tej sekcji opisano sprawdzone rozwiązania dotyczące modyfikowania jednostek przechowywanych w usłudze Table Service.
Dzielenie na partie
Transakcje wsadowe są nazywane transakcjami grup jednostek w usłudze Azure Storage. 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ę rund 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 magazynowania) i włącza aktualizacje niepodzielne (wszystkie operacje kończą się powodzeniem lub wszystkim 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 tabeli 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 wiadomo, że nowo przekazana jednostka jest całkowicie poprawna, ponieważ całkowicie zastępuje starą jednostkę. 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 jednostki tabeli na godzinę, z każdą jednostką reprezentującą określoną godzinę i przechowując użycie procesora CPU przez daną godzinę. 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ą jednostkę zamiast 24, tworząc wydajną kwerendę. 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 wsadować kilka minut dzienników i wstawić je, a następnie pobrać 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.