Wydajność partycji pojedynczej partycji platformy Azure

Question

W artykule the documentation podano, że partycje magazynu tablic Azure mają minimalną szybkość 500 operacji na sekundę.

Jeśli moje dane są podzielone na partycje poprawnie, czy równoległe operacje na każdej z tych partycji nie wpływałyby na siebie nawzajem?

Na przykład, gdybym musiał wykonać kosztowne pełne skanowanie tabeli na partycji A (maksymalnie 500 jednostek/sekundę), czy wpłynęłoby to na wydajność każdej operacji występującej na partycji B?

Konta pamięci mają limit 5000 operacji na sekundę. Czy to oznacza, że ​​mogę maksymalnie wydłubać 10 partycji, zanim zaczną wpływać na wyniki innych?

Answer 1

Zgodnie z ogólną zasadą, jeśli to możliwe, należy unikać skanowania tabeli. Są to bardzo kosztowne operacje (szczególnie, jeśli masz dużo partycji). nie tyle ze względu na stres związany z tabelą, ale mają bardzo duże opóźnienie skupienia (wyjaśnione poniżej). To powiedziawszy, czasami po prostu nie da się tego uniknąć.

Zaktualizowaliśmy architekturę pamięci i zwiększyliśmy kilka limitów docelowych.

http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx

Każde konto przechowywania jest teraz 20k IOPS/sek. Każda partycja ma teraz 2k/s.

Interakcje partycji są nieco subtelne i zależą od sposobu ich użycia (i zmiany w czasie).

Składowanie Azure składa się z dwóch etapów - jeden zestaw obsługiwanych zakresów serwerów, drugi ustawia rzeczywistą pamięć (tj. 3 kopie). Gdy tabela jest zimna, wszystkie partycje mogą być obsługiwane przez jeden serwer. Ponieważ partycje są poddawane ciągłemu stresowi, system zacznie automatycznie rozkładać obciążenie (tj. Fragment) na dodatkowe serwery. Odłamki są tworzone na granicach podziału.

W przypadku niskiego/średniego stresu nie można trafić do progu, aby kiedykolwiek odrzucić lub tylko minimalną liczbę razy. Również wzór dostępu będzie miał pewien wpływ (jeśli tylko dodajesz, odłamki nie pomogą). Losowy dostęp we wszystkich wzorcach będzie zdecydowanie najlepszy. Po przywróceniu równowagi systemu otrzymasz odpowiedź 503 na kilka sekund, a następnie operacje powrócą do normy.

Jeśli wykonasz skanowanie tabeli, wykonasz kilka rund w obie strony do stołu.Kiedy zapytanie dotrze do końca partycji, odpowiedź zostanie zwrócona wraz z znalezionymi danymi (lub brak danych, jeśli kryteria nie zostały spełnione) i tokenem kontynuacji. Zapytanie jest następnie ponownie przesyłane (i zwracane w tokenie) raz po raz, aż dojdziesz do dolnej części tabeli. To jest pobierane przez SDK, ale jeśli wykonasz bezpośrednie wywołania REST, zobaczysz to.

Z perspektywy wydajności tabeli skanowanie będzie miało wpływ tylko na partycję, na której aktualnie trwa skanowanie.

Aby przyspieszyć szerokie zapytanie, które trafia na wiele partycji, można podzielić go na wiele równoległych (np. Jeden wątek na partycję), a następnie połączyć w kliencie. Naprawdę zależy to od tego, ile danych otrzymujesz, jak duży jest stół itp.

Answer 2

Twoje obserwacje są poprawne, wydajność każdej partycji jest niezależna. ALE ... Wydajność przechowywania tabel jest również (głównie?) Zależna od szerokości pasma maszyny wirtualnej. Jeśli spojrzysz na numer Azure pricing, pojawi się kolumna "Wydajność we/wy", a dodatkowe małe i małe urządzenia mają wejścia/wyjścia "Niski" i "Umiarkowany". Jeśli więc komputer może uzyskać dane tylko z szybkością 10 MB/s, wydajność przechowywania tabel jest w dużej mierze nieistotna - biorąc również pod uwagę, że zwirtualizowane pamięci (jako część systemu operacyjnego) również wykorzystają tę przepustowość.

Limit konta doładowania 5000/s oznacza, że ​​po rozpoczęciu uderzania w ten poziom można uzyskać limity czasu na niektóre operacje. Upewnij się, że jesteś architektem dla dowolnej liczby kont pamięci masowej, tak jakby to zrobić z góry, łatwo obejść ten pułap wydajności.

Jeśli sądzisz, że może być przechowywany stół pod obciążeniem. Upewnij się, że kodujesz odpowiednią diagnostyką, aby znaleźć miejsca, w których występują problemy, i wykonaj przejściową obsługę błędów, aby umożliwić ponowne próby.