Lista kontrolna wydajności i skalowalności dla usługi Blob Storage
Firma Microsoft opracowała szereg sprawdzonych rozwiązań dotyczących tworzenia aplikacji o wysokiej wydajności za pomocą usługi Blob 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 Blob 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 usługi Blob 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 usługi Queue Service, zobacz Cele dotyczące skalowalności i wydajności usługi Azure Storage.
Maksymalna liczba kont magazynu
Jeśli zbliżasz się do maksymalnej liczby kont magazynu dozwolonych dla określonej kombinacji subskrypcji/regionu, oceń swój scenariusz i określ, czy ma zastosowanie dowolny z następujących warunków:
- Czy używasz kont magazynu do przechowywania dysków niezarządzanych i dodawania tych dysków do maszyn wirtualnych? W tym scenariuszu firma Microsoft zaleca używanie dysków zarządzanych. Dyski zarządzane są skalowane automatycznie i bez konieczności tworzenia poszczególnych kont magazynu i zarządzania nimi. Aby uzyskać więcej informacji, zobacz Wprowadzenie do dysków zarządzanych platformy Azure
- Czy używasz jednego konta magazynu na klienta do celów izolacji danych? W tym scenariuszu firma Microsoft zaleca używanie kontenera obiektów blob dla każdego klienta zamiast całego konta magazynu. Usługa Azure Storage umożliwia teraz przypisywanie ról platformy Azure dla poszczególnych kontenerów. Aby uzyskać więcej informacji, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.
- Czy używasz wielu kont magazynu do fragmentowania w celu zwiększenia 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ść:
- Jeśli aplikacja osiągnie cel transakcji, rozważ użycie kont magazynu blokowych obiektów blob, które są zoptymalizowane pod kątem wysokich stawek transakcji i niskich i spójnych opóźnień. Aby uzyskać więcej informacji, zobacz Omówienie konta magazynu platformy Azure.
- 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żliwia 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.
Wielu klientów korzystających z pojedynczego obiektu blob jednocześnie
Jeśli masz dużą liczbę klientów, którzy uzyskują dostęp do pojedynczego obiektu blob jednocześnie, należy wziąć pod uwagę zarówno obiekty blob, jak i cele skalowalności konta magazynu. Dokładna liczba klientów, którzy mogą uzyskać dostęp do pojedynczego obiektu blob, różni się w zależności od czynników, takich jak liczba klientów żądających obiektu blob jednocześnie, rozmiar obiektu blob i warunki sieciowe.
Jeśli obiekt blob można dystrybuować za pośrednictwem sieci CDN, takiej jak obrazy lub filmy wideo obsługiwane z witryny internetowej, możesz użyć sieci CDN. Aby uzyskać więcej informacji, zobacz sekcję zatytułowaną Dystrybucja zawartości.
W innych scenariuszach, takich jak symulacje naukowe, w których dane są poufne, masz dwie opcje. Pierwszym z nich jest rozłożenie dostępu obciążenia w taki sposób, aby obiekt blob był uzyskiwany przez pewien czas, a dostęp do nich był uzyskiwany jednocześnie. Alternatywnie możesz tymczasowo skopiować obiekt blob na wiele kont magazynu, aby zwiększyć łączną liczbę operacji we/wy na sekundę na obiekt blob i na kontach magazynu. Wyniki różnią się w zależności od zachowania aplikacji, dlatego podczas projektowania należy przetestować wzorce współbieżności.
Przepustowość i operacje na obiekt blob
Pojedynczy obiekt blob obsługuje maksymalnie 500 żądań na sekundę. Jeśli masz wielu klientów, którzy muszą odczytać ten sam obiekt blob i możesz przekroczyć ten limit, rozważ użycie konta magazynu blokowych obiektów blob. Konto magazynu blokowych obiektów blob zapewnia większą szybkość żądań lub operacje we/wy na sekundę (IOPS).
Można również użyć sieci dostarczania zawartości (CDN), takiej jak Azure CDN, do dystrybucji operacji na obiekcie blob. Aby uzyskać więcej informacji na temat usługi Azure CDN, zobacz Omówienie usługi Azure CDN.
Partycjonowanie
Zrozumienie sposobu partycjonowania danych obiektu blob przez usługę Azure Storage jest przydatne w celu zwiększenia wydajności. Usługa Azure Storage może szybciej obsługiwać dane w jednej partycji niż dane obejmujące wiele partycji. Odpowiednio nazewnictwa obiektów blob można zwiększyć wydajność żądań odczytu.
Usługa Blob Storage używa schematu partycjonowania opartego na zakresie do skalowania i równoważenia obciążenia. Każdy obiekt blob ma klucz partycji składający się z pełnej nazwy obiektu blob (account+container+blob). Klucz partycji służy do partycjonowania danych obiektów blob w zakresy. Zakresy są następnie zrównoważone pod względem obciążenia w usłudze Blob Storage.
Partycjonowanie oparte na zakresie oznacza, że konwencje nazewnictwa korzystające z porządkowania leksyktycznego (na przykład mypayroll, myperformance, myemployees itp.) lub sygnatury czasowe (log20160101, log20160102, log20160102 itp.) są bardziej narażone na współlokowanie partycji na tym samym serwerze partycji, dopóki zwiększone obciążenie nie wymaga podziału na mniejsze zakresy. Współlokowanie obiektów blob na tym samym serwerze partycji zwiększa wydajność, dlatego ważną częścią poprawy wydajności jest nazewnictwo obiektów blob w sposób najbardziej efektywny.
Na przykład wszystkie obiekty blob w kontenerze mogą być obsługiwane przez pojedynczy serwer, dopóki obciążenie tych obiektów blob nie wymaga dalszego ponownego równoważenia zakresów partycji. Podobnie grupa lekko załadowanych kont z ich nazwami rozmieszczonymi w kolejności leksykalnej może być obsługiwana przez pojedynczy serwer, dopóki obciążenie jednego lub wszystkich tych kont nie wymaga ich podziału na wiele serwerów partycji.
Każda operacja równoważenia obciążenia może mieć wpływ na opóźnienie wywołań magazynu podczas operacji. Możliwość obsługi nagłego wzrostu ruchu do partycji przez usługę jest ograniczona przez skalowalność pojedynczego serwera partycji, dopóki operacja równoważenia obciążenia nie rozpocznie się i ponownie zrównoważy zakres kluczy partycji.
Aby zmniejszyć częstotliwość takich operacji, możesz postępować zgodnie z najlepszymi rozwiązaniami.
Jeśli to możliwe, użyj rozmiarów obiektów blob lub bloków większych niż 256 KiB dla kont magazynu w warstwie Standardowa i Premium. Większe rozmiary obiektów blob lub bloków automatycznie aktywują blokowe obiekty blob o wysokiej przepływności. Blokowe obiekty blob o wysokiej przepływności zapewniają pozyskiwanie o wysokiej wydajności, które nie ma wpływu na nazewnictwo partycji.
Zapoznaj się z konwencją nazewnictwa używaną dla kont, kontenerów, obiektów blob, tabel i kolejek. Rozważ prefiksowanie nazw kont, kontenerów lub obiektów blob z trzycyfrowym skrótem przy użyciu funkcji tworzenia skrótów, która najlepiej odpowiada Twoim potrzebom.
Jeśli organizujesz dane przy użyciu sygnatur czasowych lub identyfikatorów liczbowych, upewnij się, że nie używasz wzorca ruchu tylko do dołączania (lub tylko do wstępnego). Te wzorce nie są odpowiednie dla systemu partycjonowania opartego na zakresie. Te wzorce mogą prowadzić do całego ruchu przechodzącego do pojedynczej partycji i ograniczania systemu z efektywnego równoważenia obciążenia.
Jeśli na przykład masz codzienne operacje, które używają obiektu blob z sygnaturą czasową, taką jak rrrrmdd, cały ruch dla tej codziennej operacji jest kierowany do pojedynczego obiektu blob, który jest obsługiwany przez pojedynczy serwer partycji. Zastanów się, czy limity dla poszczególnych obiektów blob i limity na partycje spełniają Twoje potrzeby, i rozważ podzielenie tej operacji na wiele obiektów blob w razie potrzeby. Podobnie, jeśli przechowujesz dane szeregów czasowych w tabelach, cały ruch może być kierowany do ostatniej części przestrzeni nazw kluczy. Jeśli używasz identyfikatorów liczbowych, prefiks identyfikatora z trzycyfrowym skrótem. Jeśli używasz sygnatur czasowych, prefiks znacznika czasu z wartością sekund, na przykład ssyyyymmdd. Jeśli aplikacja rutynowo wykonuje operacje wyświetlania listy i wykonywania zapytań, wybierz funkcję tworzenia skrótów, która ogranicza liczbę zapytań. W niektórych przypadkach losowy prefiks może być wystarczający.
Aby uzyskać więcej informacji na temat schematu partycjonowania używanego w usłudze Azure Storage, zobacz Azure Storage: usługa magazynu w chmurze o wysokiej dostępności z silną spójnością.
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.
Produktywność
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 uzyskują dostęp do usługi Azure Storage, ale nie są hostowane na platformie Azure, takie jak aplikacje mobilne 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.
W przypadku szerokiej dystrybucji zawartości obiektów blob użyj sieci dostarczania zawartości, takiej jak Azure CDN. Aby uzyskać więcej informacji na temat usługi Azure CDN, zobacz Azure CDN.
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, w innej domenie. 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.
Buforowanie
Buforowanie odgrywa ważną rolę w wydajności. W poniższych sekcjach omówiono najlepsze rozwiązania dotyczące buforowania.
Odczytywanie danych
Ogólnie rzecz biorąc, odczytywanie danych raz jest preferowane do odczytywania ich dwa razy. Rozważmy przykład aplikacji internetowej, która pobrała 50 obiektów blob MiB z usługi Azure Storage, aby służyć jako zawartość dla użytkownika. W idealnym przypadku aplikacja buforuje obiekt blob lokalnie na dysku, a następnie pobiera z pamięci podręcznej wersję kolejnych żądań użytkowników.
Jednym ze sposobów uniknięcia pobierania obiektu blob, jeśli nie został on zmodyfikowany, ponieważ został on zapisany w pamięci podręcznej, jest zakwalifikowanie operacji GET z nagłówkiem warunkowym na czas modyfikacji. Jeśli czas ostatniej modyfikacji jest po upływie czasu buforowania obiektu blob, obiekt blob jest pobierany i ponownie buforowany. W przeciwnym razie buforowany obiekt blob jest pobierany w celu uzyskania optymalnej wydajności.
Możesz również zdecydować się na zaprojektowanie aplikacji, aby założyć, że obiekt blob pozostaje niezmieniony przez krótki okres po pobraniu go. W takim przypadku aplikacja nie musi sprawdzać, czy obiekt blob został zmodyfikowany w tym interwale.
Dane konfiguracji, dane odnośników i inne dane, które są często używane przez aplikację, są dobrymi kandydatami do buforowania.
Aby uzyskać więcej informacji na temat używania nagłówków warunkowych, zobacz Określanie nagłówków warunkowych dla operacji usługi Blob Service.
Przekazywanie danych w partiach
W niektórych scenariuszach można agregować dane lokalnie, a następnie okresowo przekazywać je w partii zamiast przekazywać dane natychmiast. Załóżmy na przykład, że aplikacja internetowa przechowuje plik dziennika działań. Aplikacja może przekazać szczegóły każdego działania w taki sposób, jak to się stanie z tabelą (która wymaga wielu operacji magazynowania), albo zapisać szczegóły działania w lokalnym pliku dziennika, a następnie okresowo przekazywać wszystkie szczegóły działania jako plik rozdzielany do obiektu blob. Jeśli każdy wpis dziennika ma rozmiar 1 KB, możesz przekazać tysiące wpisów w jednej transakcji. Pojedyncza transakcja obsługuje przekazywanie obiektu blob o rozmiarze do 64 miB. Deweloper aplikacji musi zaprojektować możliwość awarii urządzenia klienckiego lub przekazywania. Jeśli dane aktywności należy pobrać przez interwał czasu, a nie dla pojedynczego działania, zaleca się użycie usługi Blob Storage w usłudze Table Storage.
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łączenia (który zazwyczaj wynosi dwa w środowisku klienta lub dziesięć 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 .
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.
Napiwek
Sterownik ABFS został zaprojektowany w celu przezwyciężenia nieodłącznych niedociągnięć WASB. Firma Microsoft zaleca używanie sterownika ABFS przez sterownik WASB, ponieważ sterownik ABFS jest zoptymalizowany specjalnie pod kątem analizy danych big data.
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, które mogą być zwracane przez usługę Azure Storage w danym scenariuszu, jest pomocne w optymalizacji wydajności. Aby uzyskać listę typowych kodów błędów, zobacz Typowe kody błędów interfejsu API REST.
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 pewnego warunku przejściowego. 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 łączności można ponawiać natychmiast, ponieważ nie są 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 ponowić. 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.
Kopiowanie i przenoszenie obiektów blob
Usługa Azure Storage oferuje szereg rozwiązań do kopiowania i przenoszenia obiektów blob na koncie magazynu, między kontami magazynu i między systemami lokalnymi a chmurą. W tej sekcji opisano niektóre z tych opcji pod względem ich wpływu na wydajność. Aby uzyskać informacje o wydajnym transferowaniu danych do usługi Blob Storage lub z usługi Blob Storage, zobacz Wybieranie rozwiązania platformy Azure do transferu danych.
Interfejsy API kopiowania obiektów blob
Aby skopiować obiekty blob na kontach magazynu, użyj operacji Umieść blok z adresu URL . Ta operacja kopiuje dane synchronicznie z dowolnego źródła adresu URL do blokowego obiektu blob. Put Block from URL Użycie operacji może znacznie zmniejszyć wymaganą przepustowość podczas migrowania danych między kontami magazynu. Ponieważ operacja kopiowania odbywa się po stronie usługi, nie musisz pobierać i ponownie przekazywać danych.
Aby skopiować dane na tym samym koncie magazynu, użyj operacji Kopiowania obiektu blob . Kopiowanie danych na tym samym koncie magazynu jest zwykle wykonywane szybko.
Korzystanie z narzędzia AzCopy
Narzędzie wiersza polecenia AzCopy to prosta i wydajna opcja zbiorczego przesyłania obiektów blob do i między kontami magazynu. Narzędzie AzCopy jest zoptymalizowane pod kątem tego scenariusza i może osiągnąć wysokie szybkości transferu. Narzędzie AzCopy w wersji 10 używa Put Block From URL operacji do kopiowania danych obiektów blob na kontach magazynu. Aby uzyskać więcej informacji, zobacz Kopiowanie lub przenoszenie danych do usługi Azure Storage przy użyciu narzędzia AzCopy w wersji 10.
Korzystanie z usługi Azure Data Box
W przypadku importowania dużych ilości danych do usługi Blob Storage rozważ użycie rodziny usługi Azure Data Box do transferów offline. Urządzenia Data Box dostarczane przez firmę Microsoft są dobrym wyborem w przypadku przenoszenia dużych ilości danych na platformę Azure, gdy są one ograniczone przez czas, dostępność sieci lub koszty. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure DataBox.
Dystrybucja zawartości
Czasami aplikacja musi obsługiwać tę samą zawartość wielu użytkowników (na przykład film demonstracyjny produktu używany na stronie głównej witryny internetowej) znajdujący się w tym samym lub wielu regionach. W tym scenariuszu użyj usługi Content Delivery Network (CDN), takiej jak Azure Front Door. Usługa Azure Front Door to nowoczesna sieć CDN w chmurze firmy Microsoft, która zapewnia szybki, niezawodny i bezpieczny dostęp między użytkownikami a statyczną i dynamiczną zawartością internetową aplikacji na całym świecie. Usługa Azure Front Door dostarcza zawartość usługi Blob Storage przy użyciu globalnej sieci brzegowej firmy Microsoft z setkami globalnych i lokalnych punktów obecności (PoPs). Sieć CDN może zwykle obsługiwać znacznie wyższe limity ruchu wychodzącego niż pojedyncze konto magazynu i oferuje większe opóźnienie dostarczania zawartości do innych elementów.
Aby uzyskać więcej informacji na temat usługi Azure Front Door, zobacz Azure Front Door.
Korzystanie z metadanych
Usługa Blob Service obsługuje żądania HEAD, które mogą zawierać właściwości obiektu blob lub metadane. Jeśli na przykład aplikacja potrzebuje danych exif (format obrazu wymienialnego) ze zdjęcia, może pobrać zdjęcie i wyodrębnić je. Aby zaoszczędzić przepustowość i zwiększyć wydajność, aplikacja może przechowywać dane Exif w metadanych obiektu blob podczas przekazywania zdjęcia przez aplikację. Następnie można pobrać dane Exif w metadanych przy użyciu tylko żądania HEAD. Pobieranie tylko metadanych, a nie pełna zawartość obiektu blob pozwala zaoszczędzić znaczną przepustowość i skrócić czas przetwarzania wymagany do wyodrębnienia danych exif. Należy pamiętać, że 8 kiB metadanych może być przechowywanych na obiekt blob.
Aktualizacje metadanych konta i kontenera
Metadane konta i kontenera są propagowane w usłudze magazynu w regionie, w którym znajduje się konto. Pełne propagowanie tych metadanych może potrwać do 60 sekund w zależności od operacji. Na przykład:
- Jeśli szybko tworzysz, usuwasz i ponownie tworzysz konta o tej samej nazwie konta w tym samym regionie, upewnij się, że oczekujesz 60 sekund na pełne propagowanie stanu konta lub żądania mogą zakończyć się niepowodzeniem.
- Po ustanowieniu przechowywanych zasad dostępu w kontenerze zastosowanie zasad może potrwać do 30 sekund.
Dostrajanie wydajności na potrzeby transferów danych
Gdy aplikacja przesyła dane przy użyciu biblioteki klienta usługi Azure Storage, istnieje kilka czynników, które mogą mieć wpływ na szybkość, użycie pamięci, a nawet powodzenie lub niepowodzenie żądania. Aby zmaksymalizować wydajność i niezawodność transferów danych, ważne jest, aby aktywnie konfigurować opcje transferu biblioteki klienta w oparciu o środowisko, w których działa aplikacja. Aby dowiedzieć się więcej, zobacz Dostosowywanie wydajności dla przekazywania i pobierania.
Szybkie przekazywanie obiektów blob
Aby szybko przekazać obiekty blob, najpierw określ, czy przekazujesz jeden obiekt blob, czy wiele. Skorzystaj z poniższych wskazówek, aby określić poprawną metodę, która ma być używana w zależności od scenariusza. Jeśli używasz biblioteki klienta usługi Azure Storage do transferów danych, zobacz Dostosowywanie wydajności dla transferów danych, aby uzyskać więcej wskazówek.
Szybkie przekazywanie jednego dużego obiektu blob
Aby szybko przekazać pojedynczy duży obiekt blob, aplikacja kliencka może równolegle przekazywać swoje bloki lub strony, mając na uwadze cele skalowalności poszczególnych obiektów blob i konta magazynu jako całości. Biblioteki klienckie usługi Azure Storage obsługują równoległe przekazywanie. Biblioteki klienta dla innych obsługiwanych języków udostępniają podobne opcje.
Szybkie przekazywanie wielu obiektów blob
Aby szybko przekazać wiele obiektów blob, przekaż obiekty blob równolegle. Przekazywanie równoległe jest szybsze niż przekazywanie pojedynczych obiektów blob w czasie z równoległymi przekazywaniem bloków, ponieważ rozprzestrzenia przekazywanie między wiele partycji usługi magazynu. Narzędzie AzCopy domyślnie wykonuje przekazywanie równolegle i jest zalecane w tym scenariuszu. Aby uzyskać więcej informacji, zobacz Wprowadzenie do narzędzia AzCopy.
Wybieranie prawidłowego typu obiektu blob
Usługa Azure Storage obsługuje blokowe obiekty blob, uzupełnialne obiekty blob i stronicowe obiekty blob. W przypadku danego scenariusza użycia wybór typu obiektu blob wpływa na wydajność i skalowalność rozwiązania.
Blokowe obiekty blob są odpowiednie, gdy chcesz wydajnie przekazywać duże ilości danych. Na przykład aplikacja kliencka, która przekazuje zdjęcia lub wideo do usługi Blob Storage, będzie dotyczyć blokowych obiektów blob.
Uzupełnialne obiekty blob są podobne do blokowych obiektów blob, które składają się z bloków. Podczas modyfikowania uzupełnialnych obiektów blob bloki są dodawane tylko na końcu obiektu blob. Uzupełnialne obiekty blob są przydatne w scenariuszach, takich jak rejestrowanie, gdy aplikacja musi dodać dane do istniejącego obiektu blob.
Stronicowe obiekty blob są odpowiednie, jeśli aplikacja musi wykonywać losowe zapisy na danych. Na przykład dyski maszyny wirtualnej platformy Azure są przechowywane jako stronicowe obiekty blob. Aby uzyskać więcej informacji, zobacz Opis blokowych obiektów blob, uzupełnialnych obiektów blob i stronicowych obiektów blob.