Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Cegah pelambatan Amazon S3
Throttling adalah proses membatasi tingkat di mana Anda menggunakan layanan, aplikasi, atau sistem. Di AWS, Anda dapat menggunakan pelambatan untuk mencegah penggunaan layanan Amazon S3 yang berlebihan dan meningkatkan ketersediaan dan daya tanggap Amazon S3 untuk semua pengguna. Namun, karena pembatasan membatasi kecepatan transfer data ke atau dari Amazon S3, penting untuk mempertimbangkan untuk mencegah interaksi Anda terhambat.
Seperti yang ditunjukkan dalam bagian [tuning kinerja, pengoptimalan](performance-tuning.md) dapat bergantung pada keputusan tingkat layanan Anda, bagaimana Anda menyusun tabel dan data, dan bagaimana Anda menulis kueri.
**Topics**
+ [Kurangi pelambatan di tingkat layanan](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md)
+ [Optimalkan tabel Anda](performance-tuning-s3-throttling-optimizing-your-tables.md)
+ [Optimalkan kueri Anda](performance-tuning-s3-throttling-optimizing-queries.md)
# Kurangi pelambatan di tingkat layanan
Untuk menghindari pelambatan Amazon S3 pada tingkat layanan, Anda dapat memantau penggunaan dan menyesuaikan [kuota layanan Anda, atau Anda menggunakan teknik tertentu seperti](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) partisi. Berikut ini adalah beberapa kondisi yang dapat menyebabkan throttling:
+ **Melebihi batas permintaan API akun Anda** - Amazon S3 memiliki batas permintaan API default yang didasarkan pada jenis dan penggunaan akun. Jika Anda melebihi jumlah maksimum permintaan per detik untuk satu awalan, permintaan Anda mungkin dibatasi untuk mencegah kelebihan layanan Amazon S3.
+ **Partisi data tidak memadai - Jika Anda tidak mempartisi** data dengan benar dan mentransfer sejumlah besar data, Amazon S3 dapat membatasi permintaan Anda. Untuk informasi selengkapnya tentang partisi, lihat [Gunakan partisi](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) bagian dalam dokumen ini.
+ **Sejumlah besar benda kecil** — Jika memungkinkan, hindari memiliki sejumlah besar file kecil. Amazon S3 memiliki batas [5500 permintaan GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) per detik per awalan yang dipartisi, dan kueri Athena Anda memiliki batas yang sama. Jika Anda memindai jutaan objek kecil dalam satu kueri, kueri Anda kemungkinan akan dibatasi oleh Amazon S3.
Untuk menghindari pemindaian berlebih, Anda dapat menggunakan AWS Glue ETL untuk memadatkan file Anda secara berkala, atau Anda mempartisi tabel dan menambahkan filter kunci partisi. Untuk informasi selengkapnya, lihat sumber daya berikut ini.
+ [Bagaimana saya bisa mengonfigurasi pekerjaan AWS Glue ETL untuk mengeluarkan file yang lebih besar?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*Pusat AWS Pengetahuan*)
+ [Membaca file input dalam kelompok yang lebih besar](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Panduan AWS Glue Pengembang*)
# Optimalkan tabel Anda
Penataan data Anda penting jika Anda mengalami masalah pelambatan. Meskipun Amazon S3 dapat menangani data dalam jumlah besar, pembatasan terkadang terjadi karena cara data terstruktur.
Bagian berikut menawarkan beberapa saran tentang cara menyusun data Anda di Amazon S3 untuk menghindari masalah pembatasan.
## Gunakan partisi
Anda dapat menggunakan partisi untuk mengurangi pembatasan dengan membatasi jumlah data yang harus diakses pada waktu tertentu. Dengan mempartisi data pada kolom tertentu, Anda dapat mendistribusikan permintaan secara merata di beberapa objek dan mengurangi jumlah permintaan untuk satu objek. Mengurangi jumlah data yang harus dipindai meningkatkan kinerja kueri dan menurunkan biaya.
Anda dapat menentukan partisi, yang bertindak sebagai kolom virtual, saat Anda membuat tabel. Untuk membuat tabel dengan partisi dalam `CREATE TABLE` pernyataan, Anda menggunakan `PARTITIONED BY (column_name data_type)` klausa untuk menentukan kunci untuk mempartisi data Anda.
Untuk membatasi partisi yang dipindai oleh kueri, Anda dapat menentukannya sebagai predikat dalam `WHERE` klausa kueri. Dengan demikian, kolom yang sering digunakan sebagai filter adalah kandidat yang baik untuk partisi. Praktik umum adalah mempartisi data berdasarkan interval waktu, yang dapat menyebabkan skema partisi multi-level.
Perhatikan bahwa partisi juga memiliki biaya. Ketika Anda meningkatkan jumlah partisi dalam tabel Anda, waktu yang diperlukan untuk mengambil dan memproses metadata partisi juga meningkat. Dengan demikian, partisi berlebihan dapat menghilangkan manfaat yang Anda peroleh dengan mempartisi dengan lebih bijaksana. Jika data Anda sangat miring ke satu nilai partisi, dan sebagian besar kueri menggunakan nilai itu, maka Anda mungkin dikenakan biaya tambahan.
Untuk informasi lebih lanjut tentang partisi di Athena, lihat [Apa itu partisi?](ctas-partitioning-and-bucketing-what-is-partitioning.md)
## Bucket data Anda
Cara lain untuk mempartisi data Anda adalah dengan memasukkan data dalam satu partisi. Dengan bucketing, Anda menentukan satu atau beberapa kolom yang berisi baris yang ingin Anda kelompokkan bersama. Kemudian, Anda menempatkan baris itu ke dalam beberapa ember. Dengan cara ini, Anda hanya menanyakan bucket yang harus dibaca, yang mengurangi jumlah baris data yang harus dipindai.
Saat Anda memilih kolom yang akan digunakan untuk bucketing, pilih kolom yang memiliki kardinalitas tinggi (yaitu, yang memiliki banyak nilai berbeda), didistribusikan secara seragam, dan sering digunakan untuk memfilter data. Contoh kolom yang baik untuk digunakan untuk bucketing adalah kunci utama, seperti kolom ID.
Untuk informasi lebih lanjut tentang bucketing di Athena, lihat [Apa itu bucketing?](ctas-partitioning-and-bucketing-what-is-bucketing.md)
## Gunakan indeks AWS Glue partisi
Anda dapat menggunakan indeks AWS Glue partisi untuk mengatur data dalam tabel berdasarkan nilai satu atau lebih partisi. AWS Glue Indeks partisi dapat mengurangi jumlah transfer data, jumlah pemrosesan data, dan waktu untuk query untuk memproses.
Indeks AWS Glue partisi adalah file metadata yang berisi informasi tentang partisi dalam tabel, termasuk kunci partisi dan nilainya. Indeks partisi disimpan dalam bucket Amazon S3 dan diperbarui secara otomatis oleh AWS Glue saat partisi baru ditambahkan ke tabel.
Ketika indeks AWS Glue partisi hadir, query mencoba untuk mengambil subset dari partisi alih-alih memuat semua partisi dalam tabel. Query hanya berjalan pada subset data yang relevan dengan query.
Saat Anda membuat tabel di AWS Glue, Anda dapat membuat indeks partisi pada kombinasi tombol partisi yang ditentukan di atas tabel. Setelah Anda membuat satu atau lebih indeks partisi di atas meja, Anda harus menambahkan properti ke tabel yang memungkinkan pemfilteran partisi. Kemudian, Anda dapat menanyakan tabel dari Athena.
Untuk informasi tentang membuat indeks partisi AWS Glue, lihat [Bekerja dengan indeks partisi AWS Glue di Panduan AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) *Pengembang*. Untuk informasi tentang menambahkan properti tabel untuk mengaktifkan pemfilteran partisi, lihat[Optimalkan kueri dengan pengindeksan dan AWS Glue pemfilteran partisi](glue-best-practices-partition-index.md).
## Gunakan kompresi data dan pemisahan file
Kompresi data dapat mempercepat kueri secara signifikan jika file berada pada ukuran optimal atau jika mereka dapat dibagi menjadi kelompok-kelompok logis. Umumnya, rasio kompresi yang lebih tinggi membutuhkan lebih banyak siklus CPU untuk mengompres dan mendekompresi data. Untuk Athena, kami menyarankan Anda menggunakan Apache Parquet atau Apache ORC, yang mengompres data secara default. Untuk informasi tentang kompresi data di Athena, lihat. [Gunakan kompresi di Athena](compression-formats.md)
Memisahkan file meningkatkan paralelisme dengan memungkinkan Athena untuk mendistribusikan tugas membaca satu file di antara banyak pembaca. Jika satu file tidak dapat dibagi, hanya satu pembaca yang dapat membaca file sementara pembaca lain menganggur. Apache Parquet dan Apache ORC juga mendukung file splittable.
## Gunakan penyimpanan data kolumnar yang dioptimalkan
Kinerja kueri Athena meningkat secara signifikan jika Anda mengonversi data Anda menjadi format kolumnar. Saat Anda menghasilkan file kolumnar, salah satu teknik pengoptimalan yang perlu dipertimbangkan adalah memesan data berdasarkan kunci partisi.
Apache Parquet dan Apache ORC biasanya digunakan penyimpanan data kolumnar open source. Untuk informasi tentang mengonversi sumber data Amazon S3 yang ada ke salah satu format ini, lihat. [Konversi ke format kolumnar](columnar-storage.md#convert-to-columnar)
### Gunakan ukuran blok Parket yang lebih besar atau ukuran garis ORC
Parket dan ORC memiliki parameter penyimpanan data yang dapat Anda atur untuk pengoptimalan. Di Parket, Anda dapat mengoptimalkan ukuran blok. Di ORC, Anda dapat mengoptimalkan ukuran garis. Semakin besar blok atau garis, semakin banyak baris yang dapat Anda simpan di masing-masing. Secara default, ukuran blok Parket adalah 128 MB, dan ukuran garis ORC adalah 64 MB.
Jika garis ORC kurang dari 8 MB (nilai default`hive.orc.max_buffer_size`), Athena membaca seluruh garis ORC. Ini adalah tradeoff yang dilakukan Athena antara selektivitas kolom dan operasi input/output per detik untuk garis-garis yang lebih kecil.
Jika Anda memiliki tabel dengan jumlah kolom yang sangat besar, ukuran blok atau garis kecil dapat menyebabkan lebih banyak data dipindai daripada yang diperlukan. Dalam kasus ini, ukuran blok yang lebih besar bisa lebih efisien.
### Gunakan ORC untuk tipe kompleks
Saat ini, ketika Anda menanyakan kolom yang disimpan di Parket yang memiliki tipe data kompleks (misalnya,`array`,`map`, atau`struct`), Athena membaca seluruh baris data alih-alih membaca secara selektif hanya kolom yang ditentukan. Ini adalah masalah yang diketahui di Athena. Sebagai solusinya, pertimbangkan untuk menggunakan ORC.
### Pilih algoritma kompresi
Parameter lain yang dapat Anda konfigurasikan adalah algoritma kompresi pada blok data. [Untuk informasi tentang algoritma kompresi yang didukung untuk Parket dan ORC di Athena, lihat Dukungan kompresi Athena.](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
Untuk informasi lebih lanjut tentang optimalisasi format penyimpanan kolumnar di Athena, lihat bagian “Optimalkan pembuatan penyimpanan data kolumnar” di posting Blog AWS Big Data [10 Tips Penyetelan Kinerja Teratas](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) untuk Amazon Athena.
## Gunakan tabel Iceberg
Apache Iceberg adalah format tabel terbuka untuk kumpulan data analitik yang sangat besar yang dirancang untuk penggunaan yang dioptimalkan di Amazon S3. Anda dapat menggunakan tabel Iceberg untuk membantu mengurangi pelambatan di Amazon S3.
Tabel gunung es menawarkan keuntungan berikut:
+ Anda dapat mempartisi tabel Iceberg pada satu atau lebih kolom. Ini mengoptimalkan akses data dan mengurangi jumlah data yang harus dipindai oleh kueri.
+ Karena mode penyimpanan objek Iceberg mengoptimalkan tabel Iceberg agar berfungsi dengan Amazon S3, mode ini dapat memproses volume data yang besar dan beban kerja kueri yang berat.
+ Tabel gunung es dalam mode penyimpanan objek dapat diskalakan, toleran terhadap kesalahan, dan tahan lama, yang dapat membantu mengurangi pelambatan.
+ Dukungan transaksi ACID berarti bahwa beberapa pengguna dapat menambahkan dan menghapus objek Amazon S3 secara atom.
[Untuk informasi lebih lanjut tentang Apache Iceberg, lihat Apache Iceberg.](https://iceberg.apache.org/) [Untuk informasi selengkapnya tentang menggunakan tabel Apache Iceberg di Athena, lihat Menggunakan tabel Gunung Es.](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html)
# Optimalkan kueri Anda
Gunakan saran di bagian ini untuk mengoptimalkan kueri SQL Anda di Athena.
## Gunakan LIMIT dengan klausa ORDER BY
`ORDER BY`Klausa mengembalikan data dalam urutan yang diurutkan. Ini membutuhkan Athena untuk mengirim semua baris data ke node pekerja tunggal dan kemudian mengurutkan baris. Jenis kueri ini dapat berjalan untuk waktu yang lama atau bahkan gagal.
Untuk efisiensi yang lebih besar dalam kueri Anda, lihat *N* nilai atas atau bawah, lalu gunakan juga `LIMIT` klausa. Ini secara signifikan mengurangi biaya pengurutan dengan mendorong penyortiran dan pembatasan ke node pekerja individu daripada ke satu pekerja.
## Optimalkan klausa JOIN
Ketika Anda menggabungkan dua tabel, Athena mendistribusikan tabel di sebelah kanan ke node pekerja, dan kemudian mengalirkan tabel di sebelah kiri untuk melakukan gabungan.
Untuk alasan ini, tentukan tabel yang lebih besar di sisi kiri gabungan dan tabel yang lebih kecil di sisi kanan gabungan. Dengan cara ini, Athena menggunakan lebih sedikit memori dan menjalankan kueri dengan latensi yang lebih rendah.
Perhatikan juga poin-poin berikut:
+ Saat Anda menggunakan beberapa `JOIN` perintah, tentukan tabel dari yang terbesar hingga terkecil.
+ Hindari gabungan silang kecuali jika diperlukan oleh kueri.
## Optimalkan klausa GROUP BY
`GROUP BY`Operator mendistribusikan baris berdasarkan `GROUP BY` kolom ke node pekerja. Kolom ini direferensikan dalam memori dan nilainya dibandingkan saat baris dicerna. Nilai-nilai dikumpulkan bersama ketika `GROUP BY` kolom cocok. Dengan mempertimbangkan cara kerja proses ini, disarankan untuk memesan kolom dari kardinalitas tertinggi ke yang terendah.
## Gunakan angka, bukan string
Karena angka membutuhkan lebih sedikit memori dan lebih cepat diproses dibandingkan dengan string, gunakan angka alih-alih string jika memungkinkan.
## Batasi jumlah kolom
Untuk mengurangi jumlah total memori yang diperlukan untuk menyimpan data Anda, batasi jumlah kolom yang ditentukan dalam `SELECT` pernyataan Anda.
## Gunakan ekspresi reguler alih-alih LIKE
Kueri yang menyertakan klausa seperti `LIKE '%string%'` pada string besar bisa sangat intensif secara komputasi. Saat Anda memfilter beberapa nilai pada kolom string, gunakan fungsi [regexp\$1like ()](https://trino.io/docs/current/functions/regexp.html#regexp_like) dan ekspresi reguler sebagai gantinya. Ini sangat berguna ketika Anda membandingkan daftar panjang nilai.
## Gunakan klausa LIMIT
Alih-alih memilih semua kolom saat Anda menjalankan kueri, gunakan `LIMIT` klausa untuk mengembalikan hanya kolom yang Anda butuhkan. Ini mengurangi ukuran kumpulan data yang diproses melalui pipeline eksekusi kueri. `LIMIT`klausa lebih membantu ketika Anda menanyakan tabel yang memiliki sejumlah besar kolom yang berbasis string. `LIMIT`klausa juga membantu ketika Anda melakukan beberapa gabungan atau agregasi pada kueri apa pun.