Co oznacza nowa informacja „S3 Improved Request Rate Performance”?

17 lipca 2018 r. Pojawiło się oficjalne ogłoszenie AWS wyjaśniające, że nie ma już potrzeby losowania pierwszych znaków każdego klucza obiektu S3 w celu osiągnięcia maksymalnej wydajności: https://aws.amazon.com/about-aws/whats-new / 2018/07 / amazon-s3-annovers-wzrosły-żądanie-szybkość-wydajność /

Amazon S3 ogłasza wzrost wydajności wskaźnika żądań

Wysłany: 17 lipca 2018 r

Amazon S3 zapewnia teraz zwiększoną wydajność w zakresie obsługi co najmniej 3500 żądań na sekundę w celu dodania danych i 5500 żądań na sekundę w celu pobrania danych, co może zaoszczędzić znaczny czas przetwarzania bez dodatkowych opłat. Każdy prefiks S3 może obsługiwać te prędkości żądań, co znacznie zwiększa wydajność.

Aplikacje działające dzisiaj na Amazon S3 będą cieszyć się poprawą wydajności bez żadnych zmian, a klienci budujący nowe aplikacje na S3 nie muszą dokonywać żadnych modyfikacji aplikacji, aby osiągnąć tę wydajność. Obsługa Amazon S3 dla równoległych żądań oznacza, że ​​możesz skalować wydajność S3 ze względu na klaster obliczeniowy, bez dokonywania jakichkolwiek dostosowań w swojej aplikacji. Skale wydajności dla każdego prefiksu, dzięki czemu można użyć tyle prefiksów, ile potrzebujesz równolegle, aby osiągnąć wymaganą przepustowość. Nie ma ograniczeń co do liczby prefiksów.

Ten wzrost wydajności wskaźnika żądań S3 usuwa wszelkie wcześniejsze wytyczne w celu losowego przydzielania prefiksów obiektów w celu osiągnięcia szybszej wydajności. Oznacza to, że możesz teraz używać logicznych lub sekwencyjnych wzorców nazewnictwa w nazewnictwie obiektów S3 bez wpływu na wydajność. To ulepszenie jest teraz dostępne we wszystkich regionach AWS. Aby uzyskać więcej informacji, odwiedź Amazon S3 Developer Guide.

To świetnie, ale jest też mylące. Mówi, że każdy prefiks S3 może obsługiwać te stawki żądań, co znacznie zwiększa wydajność

Ponieważ jednak prefiksy i ograniczniki są tylko argumentami GET Bucket (List Objects)interfejsu API podczas wyświetlania zawartości segmentów, w jaki sposób można mówić o wydajności pobierania obiektów „na prefiks”. Każde wywołanie GET Bucket (List Objects)może wybrać dowolny prefiks i ogranicznik, jakie chce, więc prefiksy nie są predefiniowanym bytem.

Na przykład, jeśli moje wiadro ma te obiekty:

a1/b-2
a1/c-3

Następnie mogę użyć „/” lub „-” jako mojego ogranicznika za każdym razem, gdy wymieniam zawartość segmentu, więc mogę rozważyć moje prefiksy jako

a1/ 

lub

a1/b-
a1/c-

Ponieważ jednak GET Objectinterfejs API używa całego klucza, pojęcie konkretnego prefiksu lub separatora nie istnieje w przypadku pobierania obiektów. Więc czy mogę spodziewać się 5,500 req / sek włączony a1/lub alternatywnie 5,500 req / sek włączony a1/b-i 5,500 włączony a1/c-?

Więc czy ktoś może wyjaśnić, co rozumie się przez ogłoszenie, które sugeruje określony poziom wydajności (np. +5,500 żądań na sekundę w celu pobrania danych) dla „każdego prefiksu s3”?

To, co faktycznie nazywa się tutaj przedrostkiem, wydaje się nadmiernym uproszczeniem, które naprawdę odnosi się do każdej partycji indeksu segmentu. Indeks jest leksykalny, więc podziały występują na podstawie wiodących znaków w kluczu obiektu. Dlatego jest nazywany prefiksem .

S3 zarządza partycjami indeksowymi automatycznie i przejrzyście, więc dokładna definicja „przedrostka” tutaj jest w rzeczywistości nieco nieprecyzyjna: „wszystko, co zdecyduje S3, jest potrzebne do obsługi obciążenia wiadra”. S3 dzieli partycje indeksu w odpowiedzi na obciążenie, więc dwa obiekty, które dziś mogą mieć ten sam „prefiks”, jutro mogą mieć różne prefiksy, wszystkie wykonane w tle.

W tej chwili wszystkie a1 / a -... i a1 / b -... i a1 / c -... mogą być pojedynczymi prefiksami. Ale rzucaj wystarczającą ilością ruchu do segmentu, a S3 może zdecydować, że partycja powinna zostać podzielona, ​​tak aby jutro a1 / a- i a1 / b- mogły mieć jeden prefiks, podczas gdy a1 / c- może mieć własny prefiks. (To znaczy, klucze <a1 / c- są na jednej partycji, podczas gdy klucze> = a1 / c- są teraz na innej partycji).

Gdzie i kiedy, a konkretnie jaki próg wyzwala zachowanie podziału, nie jest udokumentowane, ale wydaje się, że jest związane tylko z liczbą żądań, a nie z liczbą lub rozmiarem obiektów. Wcześniej partycje te były ograniczone do kilkuset żądań na sekundę, co znacznie wzrosło.