View a markdown version of this page

PERF04-BP04 Memilih penyimpanan data berdasarkan pola akses - AWS Well-Architected Framework
Panduan implementasiSumber daya

PERF04-BP04 Memilih penyimpanan data berdasarkan pola akses

Gunakan pola akses beban kerja dan persyaratan aplikasi untuk menentukan layanan dan teknologi data optimal yang akan digunakan.

Hasil yang diinginkan: Penyimpanan data telah dipilih berdasarkan pola akses data yang teridentifikasi dan didokumentasikan. Ini dapat mencakup kueri baca, tulis, dan hapus yang paling umum, kebutuhan penghitungan dan agregasi penting, kompleksitas data, interdependensi data, dan konsistensi yang diperlukan.

Antipola umum:

  • Anda hanya memilih satu mesin basis data untuk menyederhanakan manajemen operasi.

  • Anda berasumsi bahwa pola akses data tidak akan berubah.

  • Anda mengimplementasikan transaksi, rollback, dan logika konsistensi yang rumit di aplikasi.

  • Basis data dikonfigurasikan untuk mendukung potensi tingginya lonjakan lalu lintas, sehingga banyak sumber daya yang sering tidak digunakan.

  • Menggunakan basis data bersama untuk keperluan analitik dan transaksional.

Manfaat menjalankan praktik terbaik ini: Memilih dan mengoptimalkan penyimpanan data berdasarkan pola akses akan membantu mengurangi kompleksitas pengembangan dan mengoptimalkan peluang kinerja Anda. Memahami kapan harus menggunakan replika baca, tabel global, partisi data, dan caching akan membantu Anda mengurangi biaya operasional dan menskalakan sesuai kebutuhan beban kerja Anda.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Sedang

Panduan implementasi

Identifikasi dan evaluasi pola akses data Anda untuk memilih konfigurasi penyimpanan yang benar. Setiap solusi basis data memiliki opsi untuk mengonfigurasi dan mengoptimalkan solusi penyimpanan Anda. Gunakan metrik dan log yang dikumpulkan serta coba berbagai opsi untuk menemukan konfigurasi yang optimal. Gunakan tabel berikut untuk meninjau opsi penyimpanan per layanan basis data.

AWS Services Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Scaling Storage Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. Storage automatically scales. Tables are unconstrained in terms of size. Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. Storage is in-memory, tied to instance type or count. Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. Scales table storage up and down automatically as your application writes, updates, and deletes data. Storage automatically scales. Tables are unconstrained in terms of size.

Langkah implementasi:

  1. Pahami persyaratan kepatuhan terhadap transaksi, atomisitas, konsistensi, isolasi, dan durabilitas (ACID), serta bacaan yang konsisten. Tidak semua basis data mendukung hal ini dan sebagian besar basis data NoSQL menyediakan model eventual consistency.

  2. Pertimbangkan persyaratan pola lalu lintas, latensi, dan akses untuk aplikasi yang didistribusikan secara global agar dapat mengidentifikasi solusi penyimpanan yang optimal.

  3. Analisis pola kueri, pola akses acak, dan kueri satu kali. Anda juga harus mempertimbangkan untuk menerapkan fungsionalitas kueri yang sangat khusus untuk pemrosesan bahasa alami dan teks, deret waktu, dan grafik.

  4. Identifikasi dan dokumentasikan antisipasi pertumbuhan data dan lalu lintas.

    1. Amazon RDS dan Aurora mendukung penskalaan penyimpanan secara otomatis hingga batas yang didokumentasikan. Selain itu, pertimbangkan untuk mengalihkan data lama ke Amazon S3 untuk pengarsipan, menggabungkan data historis untuk analitik atau penskalaan secara horizontal menggunakan serpihan.

    2. DynamoDB dan Amazon S3 akan menskalakan volume penyimpanan secara otomatis hingga nyaris tak terbatas.

    3. Ukuran basis data dan instans Amazon RDS yang berjalan di EC2 dapat disesuaikan secara manual dan nantinya volume EBS baru dapat ditambahkan ke instans EC2 untuk penyimpanan tambahan. 

    4. Jenis instans dapat diubah sesuai perubahan aktivitas. Misalnya, Anda dapat menggunakan instans yang lebih kecil saat pengujian, kemudian menskalakan saat mulai menerima lalu lintas produksi ke layanan. Aurora V2 nirserver diskalakan secara otomatis sesuai perubahan beban. 

  5. Buat dasar persyaratan menurut kinerja normal dan puncak (transaksi per detik/TPS dan kueri per detik/QPS) serta konsistensi (ACID dan eventual consistency).

  6. Dokumentasikan aspek deployment solusi dan persyaratan akses basis data (replikasi global, Multi-AZ, replikasi baca, dan beberapa simpul tulis).

Tingkat upaya untuk rencana implementasi: Rendah. Jika belum memiliki log dan metrik untuk solusi manajemen data, Anda harus melengkapinya sebelum mengidentifikasi dan mendokumentasikan pola akses data. Setelah pola akses data dipahami, memilih dan mengonfigurasi penyimpanan data memerlukan tingkat upaya yang rendah.

Sumber daya

Dokumen terkait:

Video terkait:

Contoh terkait: