Apa yang dimaksud dengan pengumuman "S3 Peningkatan Kinerja Tingkat Permintaan"

Pada 17 Juli 2018 ada pengumuman AWS resmi yang menjelaskan bahwa tidak perlu lagi mengacak karakter pertama dari setiap kunci objek S3 untuk mencapai kinerja maksimum: https://aws.amazon.com/about-aws/whats-new / 2018/07 / amazon-s3-mengumumkan-peningkatan-permintaan-tingkat-kinerja /

Amazon S3 Mengumumkan Peningkatan Kinerja Tingkat Permintaan

Diposting pada: Jul 17, 2018

Amazon S3 sekarang menyediakan peningkatan kinerja untuk mendukung setidaknya 3.500 permintaan per detik untuk menambahkan data dan 5.500 permintaan per detik untuk mengambil data, yang dapat menghemat waktu pemrosesan yang signifikan tanpa biaya tambahan. Setiap awalan S3 dapat mendukung tingkat permintaan ini, membuatnya mudah untuk meningkatkan kinerja secara signifikan.

Aplikasi yang berjalan di Amazon S3 hari ini akan menikmati peningkatan kinerja ini tanpa perubahan, dan pelanggan yang membangun aplikasi baru di S3 tidak harus membuat penyesuaian aplikasi apa pun untuk mencapai kinerja ini. Dukungan Amazon S3 untuk permintaan paralel berarti Anda dapat meningkatkan kinerja S3 Anda dengan faktor cluster komputasi Anda, tanpa membuat penyesuaian apa pun pada aplikasi Anda. Skala kinerja per awalan, sehingga Anda dapat menggunakan banyak awalan yang Anda butuhkan secara paralel untuk mencapai throughput yang diperlukan. Tidak ada batasan jumlah awalan.

Peningkatan kinerja permintaan tingkat S3 ini menghilangkan panduan sebelumnya untuk mengacak awalan objek untuk mencapai kinerja yang lebih cepat. Itu berarti Anda sekarang dapat menggunakan pola penamaan logis atau berurutan dalam penamaan objek S3 tanpa implikasi kinerja. Peningkatan ini sekarang tersedia di semua Wilayah AWS. Untuk informasi lebih lanjut, kunjungi Panduan Pengembang Amazon S3.

Itu bagus, tetapi juga membingungkan. Dikatakan Setiap awalan S3 dapat mendukung tingkat permintaan ini, membuatnya mudah untuk meningkatkan kinerja secara signifikan

Tetapi karena awalan dan pembatas hanyalah argumen untuk GET Bucket (List Objects)API ketika mendaftar konten ember, bagaimana masuk akal untuk berbicara tentang kinerja pengambilan objek "per awalan". Setiap panggilan untuk GET Bucket (List Objects)dapat memilih awalan apa pun dan pembatas yang diinginkan, sehingga awalan bukan entitas yang ditentukan sebelumnya.

Misalnya, jika ember saya memiliki objek ini:

a1/b-2
a1/c-3

Maka saya dapat memilih untuk menggunakan "/" atau "-" sebagai pembatas saya setiap kali saya mencantumkan konten bucket, jadi saya mungkin menganggap awalan saya sebagai

a1/ 

atau

a1/b-
a1/c-

Tetapi karena GET ObjectAPI menggunakan seluruh kunci, konsep awalan atau pembatas tertentu tidak ada untuk pengambilan objek. Jadi bisakah saya mengharapkan 5.500 req / detik aktif a1/atau alternatifnya 5.500 req / detik a1/b-dan 5.500 a1/c-?

Jadi, bisakah seseorang menjelaskan apa yang dimaksud dengan pengumuman ketika itu menunjukkan tingkat kinerja tertentu (misalnya +5.500 permintaan per detik untuk mengambil data) untuk "setiap awalan s3"?

Apa yang sebenarnya disebut di sini sebagai awalan tampaknya penyederhanaan berlebihan yang benar-benar merujuk ke setiap partisi indeks bucket. Indeks ini leksikal, sehingga perpecahan terjadi berdasarkan karakter utama di kunci objek. Karenanya, itu disebut sebagai awalan .

S3 mengelola partisi indeks secara otomatis dan transparan, sehingga definisi tepat dari "awalan" di sini sebenarnya agak tidak tepat: itu adalah "apa pun yang diputuskan S3 diperlukan untuk mendukung beban kerja ember Anda." S3 membagi partisi indeks sebagai respons terhadap beban kerja, sehingga dua objek yang mungkin memiliki "awalan" yang sama hari ini dapat memiliki awalan yang berbeda besok, semua dilakukan di latar belakang.

Saat ini, a1 / a -... dan a1 / b -... dan a1 / c -... mungkin semuanya merupakan awalan tunggal. Tetapi membuang lalu lintas yang cukup di bucket, dan S3 dapat memutuskan partisi harus dipecah, sehingga besok, a1 / a- dan a1 / b- dapat dalam satu awalan, sementara a1 / c- mungkin dalam awalannya sendiri. (Yaitu, kunci <a1 / c- berada di satu partisi, sedangkan kunci> = a1 / c- sekarang berada di partisi yang berbeda).

Di mana dan kapan dan secara spesifik ambang apa yang memicu perilaku pemisahan tidak didokumentasikan, tetapi tampaknya hanya terkait dengan jumlah permintaan, dan bukan jumlah atau ukuran objek. Sebelumnya, partisi ini dibatasi masing-masing hingga beberapa ratus permintaan per detik, dan itu telah meningkat secara signifikan.