Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pilar optimasi biaya
[Pilar optimasi biaya](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html) dari AWS Well-Architected Framework berfokus pada menghindari biaya yang tidak perlu dan membangun arsitektur dengan cara yang dioptimalkan biaya. Rekomendasi berikut dapat membantu Anda memenuhi prinsip desain pengoptimalan biaya dan praktik terbaik arsitektur untuk Amazon TimeStream untuk InfluxDB.
Pilar optimasi biaya berfokus pada bidang-bidang utama berikut:
+ Memahami persyaratan dan biaya kasus penggunaan Anda
+ Memilih sumber daya dengan memperhatikan biaya
+ Penskalaan untuk memenuhi kebutuhan bisnis tanpa pengeluaran berlebihan
+ Penyimpanan dan transfer data ukuran kanan
## Memahami persyaratan dan biaya kasus penggunaan Anda
Kami merekomendasikan untuk tidak menggunakan Timestream untuk InfluxDB dalam kasus penggunaan berikut:
+ Jika model data Anda memiliki data relasional, Timestream untuk InfluxDB bukanlah solusi yang tepat.
+ Jika Anda tidak dapat menggunakan filter waktu dalam kueri Anda, Influx akan memindai semua seri, yang tidak efisien.
## Memilih sumber daya dengan memperhatikan biaya
Biaya [instans InfluxDB](https://aws.amazon.com/timestream/pricing/) didasarkan pada tarif per jam untuk jam yang dijalankan instans Anda. Contoh merupakan, rata-rata, 85 persen dari keseluruhan biaya menjalankan database AWS, sehingga ukuran yang tepat dapat memiliki implikasi biaya yang signifikan. Cara terbaik untuk instans ukuran yang tepat adalah dengan menguji kinerja aplikasi:
+ Apakah `CPUUtilization` dan `MemoryUtilization` terus-menerus tinggi atau rendah?
+ Apa keseimbangan antara harga dan kinerja?
Skala biaya instans secara linier. Biaya per jam `db.influx.2xlarge` instance adalah dua kali lipat dari `db.influx.xlarge` instance, meskipun juga memiliki alokasi sumber daya dua kali lipat. `db.influx.16xlarge`Instans adalah 16 kali biaya per jam dari `db.influx.xlarge` instans.
Perkirakan jumlah penulisan dan pembacaan beban kerja Anda untuk kerangka waktu tertentu (detik, menit, jam, atau hari). Timestream untuk instans InfluxDB mendukung 50.000 hingga lebih dari 500.000 penulisan per detik dan 10‒100 kueri per detik (QPS) berdasarkan jenis instans. Misalnya, `db.influx.2xlarge` biasanya mendukung hingga 150.000 penulisan per detik dan sekitar 25 QPS. Dengan model data yang efisien dan query yang efisien, dapat melebihi kinerja itu. Jika kebutuhan Anda bervariasi menurut waktu hari, minggu, atau bulan, Anda dapat menjadwalkan penskalaan naik dan turun dengan melakukan hal berikut:
+ [Membuat dan menjadwalkan AWS Lambda fungsi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-run-lambda-schedule.html).
+ Gunakan penjadwal khusus dan jalankan API atau SDK untuk [meningkatkan dan menurunkan skala dengan](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-modifying-db.html) beberapa waktu buffer.
## Penskalaan untuk memenuhi kebutuhan bisnis tanpa pengeluaran berlebihan
Untuk eksperimen entry-level dengan Timestream untuk InfluxDB, Anda dapat menggunakan dan. `db.influx.medium` `db.influx.large` Instans ini cukup besar bagi Anda untuk mendapatkan pengalaman dengan Timestream untuk InfluxDB sebelum Anda berinvestasi dalam instans yang lebih besar.
`db.influx.large`Contoh `db.influx.medium` dan contoh bagus untuk lingkungan pengembangan berbiaya rendah. Namun, mereka memiliki RAM yang lebih kecil (8 GiB dan 16 GiB), lebih sedikit v (CPUs 1 vCPU dan 2 vCPUs), dan kinerja jaringan hingga hanya 10 GB. Tidak semua beban kerja cocok untuk kelas instance ini. Pantau `CPUUtilization` dan`MemoryUtilization`, dan skala naik atau turun sesuai kebutuhan. Sering kali ada rasio yang konsisten antara memori dan vCPU. Kelas instans db.influx memiliki memory-to-vCPU rasio yang mirip dengan kelas instans Amazon EC2 r7g. Kami sangat menyarankan menjalankan end-to-end kinerja atau pengujian beban sebelum pergi ke produksi.
Pemodelan data yang efisien, penulisan batch, dan kueri yang dioptimalkan membutuhkan lebih sedikit memori dan penggunaan komputasi. Ketika lebih sedikit sumber daya yang diperlukan, Anda berpotensi menggunakan instance yang lebih kecil.
## Penyimpanan dan transfer data ukuran kanan
Untuk menyimpan data, gunakan praktik terbaik berikut:
+ Simpan hanya data deret waktu di Timestream untuk InfluxDB.
+ Tetapkan retensi yang sesuai pada bucket InfluxDB sehingga data yang lebih lama dari retensi dihapus, dan pecahan dipadatkan secara otomatis secara berkala. Untuk informasi selengkapnya, lihat dokumentasi [InfluxDB](https://docs.influxdata.com/influxdb/v2/reference/internals/shards/#shard-compaction).
+ Optimalkan penggunaan disk untuk penulisan future.
+ Hapus bucket InfluxDB yang tidak diperlukan untuk beban kerja Anda. InfluxDB mendukung penghapusan. Anda dapat melakukan pembersihan terjadwal jika sesuai dengan kasus penggunaan Anda.
Untuk transfer data, sebaiknya gunakan aplikasi Anda sama Wilayah AWS dengan instans database Timestream for InfluxDB Anda untuk menghindari overhead jaringan lintas wilayah. Mungkin juga ada biaya transfer data. Untuk informasi selengkapnya tentang transfer data, lihat [halaman harga](https://aws.amazon.com/timestream/pricing/).