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 dari AWS Well-Architected Framework berfokus pada menghindari biaya yang tidak perlu. Rekomendasi berikut dapat membantu Anda memenuhi prinsip desain pengoptimalan biaya dan praktik terbaik arsitektur untuk Amazon Neptunus.

Pilar optimasi biaya berfokus pada bidang-bidang utama berikut:

Memahami pola penggunaan dan layanan yang dibutuhkan

Neptunus cocok untuk beban kerja Anda jika model data Anda memiliki struktur grafik yang dapat dilihat, dan kueri Anda perlu mengeksplorasi hubungan dan melintasi beberapa lompatan. Database grafik tidak cocok untuk pola berikut:

Pertimbangkan apakah menggunakan beberapa database yang dibuat khusus bersama-sama untuk pola akses tertentu dapat memenuhi semua kebutuhan Anda. Contoh:

Memahami biaya yang terkait dengan layanan yang berinteraksi dengan dan melengkapi Neptunus, termasuk yang berikut:

Pilih sumber daya dengan memperhatikan biaya

Harga Neptunus didasarkan pada biaya instans per jam (atau Unit Komputasi Neptunus yang digunakan untuk tanpa server), I/O data, dan penggunaan penyimpanan. Contoh merupakan, rata-rata, 85 persen dari keseluruhan biaya, sehingga ukuran yang tepat dapat memiliki implikasi biaya yang signifikan. Cara terbaik untuk mengukur instans yang tepat adalah dengan menguji kinerja aplikasi pada berbagai instance dan membandingkan faktor-faktor berikut:

Biaya instans diskalakan secara linier dengan ukuran dalam keluarga instance yang sama. Biaya per jam db.r6i.2xlarge instance adalah dua kali lipat dari db.r6i.xlarge instance dan juga memiliki alokasi sumber daya dua kali lipat. db.r6i.24xlargeInstans adalah 24 kali biaya per jam dari db.r6i.xlarge instans.

Perkirakan jumlah kueri bersamaan yang harus Anda dukung. Anda dapat memiliki antara nol dan lima belas replika baca untuk memproses kueri hanya-baca. Jika persyaratan Anda bervariasi menurut waktu hari, minggu, atau bulan, Anda dapat menggunakan beberapa instance yang lebih kecil untuk menskalakan jadwal. Setiap vCPU pada sebuah instance menyediakan dua thread untuk menangani kueri bersamaan. Tiga replika db.r6i.xlarge baca, dengan masing-masing 4 vCPU, dapat menangani 24 kueri bersamaan..

Jika volume lalu lintas Anda diukur dalam kueri per detik (QPS), Anda harus bereksperimen untuk menentukan latensi rata-rata kueri Anda. Jumlah kueri per detik yang dapat didukung oleh cluster Neptunus sama dengan. vCPU × 2 × (1 second/average query latency) Misalnya, jika Anda memiliki 4 vCPU dan latensi kueri 100 milidetik (0,1 detik),. QPS = 4 × 2 × (1s/0.1s) = 80 queries per second

Instans yang disediakan lebih murah daripada tanpa server untuk beban kerja yang berkelanjutan, stabil, dan dapat diprediksi. Tanpa server memberikan peluang untuk mengoptimalkan biaya ketika Anda memiliki beban kerja yang membutuhkan penggunaan sangat tinggi hanya beberapa jam per hari (misalnya,db.r6i.4xlarge) dan kemudian hampir tidak ada lalu lintas untuk sisa hari itu (misalnya, 1 Unit Komputasi Neptunus). Instans tanpa server yang ditingkatkan selama beberapa jam dan kemudian mundur akan lebih murah daripada menggunakan instance yang disediakan sepanjang db.r6i.4xlarge hari.

Pertimbangkan untuk meningkatkan ke Neptunus 1.4.5.0 atau yang lebih baru dan r8g menggunakan instance untuk mencapai throughput baca dan tulis yang lebih baik dengan biaya lebih rendah daripada instance generasi yang lebih tua, seperti atau. r7g r6g Untuk informasi selengkapnya, lihat 4,7 kali lebih baik menulis kinerja harga kueri dengan instans AWS Graviton4 R8g menggunakan Amazon Neptunus v1.4.5 (posting blog).AWS

Cluster Neptunus dibuat secara default dengan penyimpanan standar (jika Anda membuat menggunakan konsol, itu akan default untuk I/O-optimized storage). With I/O-optimized storage, you pay a slightly higher cost for storage and instances, but there are no I/O costs. This leads to more predictable recurring costs, but if your I/O usage is generally low, it may be more cost efficient to utilize standard storage. If you intend to load a lot of data initially, you can optimize cost by choosing I/O memilih penyimpanan yang dioptimalkan, melakukan pemuatan data awal Anda, dan kemudian beralih ke penyimpanan standar. Jenis penyimpanan hanya memengaruhi model penagihan dan tidak memiliki perbedaan teknis dalam cluster DB Neptunus atau konfigurasi instans. Anda dapat mengubah jenis penyimpanan sekali per 30 hari. Setelah 30 hari, periksa detail biaya Neptunus Anda dan gunakan halaman harga Neptunus untuk menghitung apakah biaya Anda akan lebih tinggi menggunakan -optimasi. I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O

Pilih konfigurasi instans Neptunus terbaik untuk beban kerja Anda

Jika Anda membuat Akun AWS sebelum 15 Juli 2025, Anda dapat menggunakan Tingkat AWS Gratis untuk eksperimen entry-level dengan Neptunus. 750 jam gratis db.t3.medium dan penggunaan db.t4g.medium instance sudah cukup bagi Anda untuk mendapatkan pemahaman yang baik tentang Neptunus dalam skala rendah. Cluster Anda akan tetap ada setelah periode uji coba gratis berakhir, meskipun Anda akan dikenakan biaya untuk penggunaan selanjutnya sejak saat itu.

db.t4g.mediumInstance db.t3.medium dan instance bagus untuk lingkungan pengembangan berbiaya rendah di mana Anda tidak menggunakan OpenCypher, Graph Explorer, atau berbagai integrasi AI generatif. Contoh ini memiliki RAM-to-vCPU rasio yang lebih kecil (2:1) daripada contoh R keluarga (8:1) atau contoh X keluarga (16:1). Ini mengurangi rasio mencegah penggunaan statistik mesin DFE yang memungkinkan kinerja OpenCypher, integrasi GenAI (untuk menginformasikan LLM skema grafik), dan Graph Explorer. Profil kinerja mungkin berbeda secara signifikan saat menggunakan instance T keluarga, terutama untuk beban kerja yang disebutkan sebelumnya. Contoh ini juga dapat meningkatkan kemunculan OutOfMemoryExceptions ketika kueri menavigasi di sebagian besar grafik. Untuk menentukan apakah kondisi terakhir mungkin terpengaruh, periksa BufferCacheHitRatio CloudWatch metrik.

Kami sangat menyarankan untuk tidak melakukan pengujian kinerja atau beban apa pun dengan instance T keluarga karena Anda mungkin mengalami hasil yang tidak konsisten yang tidak menunjukkan lingkungan produksi.

Instans yang disediakan memberi Anda kombinasi biaya dan kinerja terbaik ketika beban kerja Anda cukup stabil dan dapat diprediksi. Pilih ukuran instance berdasarkan konkurensi permintaan yang diperlukan dan kompleksitas kueri. Konkurensi yang lebih tinggi membutuhkan lebih banyak vCPUs. Kompleksitas kueri yang lebih tinggi membutuhkan lebih banyak RAM. Gunakan MainRequestQueuePendingRequests CloudWatch metrik untuk menentukan dampak dari yang pertama (lebih besar dari nol mewakili lebih banyak permintaan bersamaan daripada yang dapat ditangani). Gunakan BufferCacheHitRatio CloudWatch metrik untuk menentukan dampak yang terakhir. Rasio yang sering turun lebih rendah dari 99,9 persen menunjukkan bahwa tidak ada cukup RAM untuk menampung bagian kerja grafik yang sedang dievaluasi, yang menghasilkan pertukaran cache yang lebih sering. Jika keluarga R contoh memberikan konkurensi yang cukup tetapi tidak cukup RAM, pertimbangkan untuk mencoba X keluarga instance.

Kasus penggunaan ideal untuk instance tanpa server dijelaskan dalam dokumentasi Neptunus. Jika Anda tidak yakin apakah provisioned atau serverless adalah yang terbaik untuk Anda, dan biaya adalah perhatian utama Anda, uji beban kerja Anda di tanpa server untuk menentukan jumlah yang NCUs digunakan dan bandingkan biaya provisioned () dengan serverless (). N hours × hourly provisioned cost sum of NCUs × hourly cost per NCU Jika Anda tidak yakin tentang instance penyediaan berukuran setara, satu NCU setara dengan sekitar 2 GB RAM dan vCPU dan jaringan terkait. Jika instans yang Anda sediakan berasal dari r6i keluarga, rasionya adalah 1 vCPU per 8 GB RAM, atau 4 NCUs, bersama dengan jaringan terkait. Kalkulator Harga Amazon Neptunus juga menyediakan perbandingan untuk membantu Anda memutuskan konfigurasi biaya optimal Anda.

Saat menggunakan tanpa server untuk instance primer dan replika, ingatlah bahwa replika baca di tingkat promosi 0 dan 1 akan menskalakan sesuai dengan instance penulis sehingga diskalakan dengan benar jika peristiwa failover terjadi. NCUs Tetapkan batas NCU Anda untuk instans ini berdasarkan instans Anda—penulis atau pembaca—yang menerima lalu lintas terbanyak.

Di lingkungan di mana cluster tidak diperlukan 24 jam per hari, 7 hari seminggu, pertimbangkan untuk menulis skrip yang akan mematikan instance Neptunus saat tidak digunakan dan memulainya lagi sebelum digunakan. Instans Neptunus akan dimulai ulang secara otomatis setiap 7 hari untuk memastikan pembaruan pemeliharaan yang diperlukan diterapkan. Jika Anda berniat untuk meninggalkan instance untuk jangka waktu yang lama, gunakan skrip mingguan untuk mematikannya lagi.

Penyimpanan dan transfer data ukuran kanan

Kueri yang lebih efisien (misalnya, kueri yang perlu menyentuh lebih sedikit node, tepi, dan properti dalam grafik) memerlukan lebih sedikit I/O transfer dan berpotensi dapat menggunakan instance yang lebih kecil karena lebih sedikit cache buffer yang diperlukan. Gunakan profil atau jelaskan titik akhir untuk bahasa kueri Anda untuk mengoptimalkan kueri Anda, dan pertimbangkan untuk mengoptimalkan model grafik Anda untuk kinerja kueri Anda.

Neptunus menggunakan pengkodean kamus pada string besar, dan kamus itu dioptimalkan untuk kinerja, bukan efisiensi. Jika Anda memiliki string besar BLOBs, JSON, atau sering berubah untuk properti, pertimbangkan untuk menyimpannya di luar Neptunus di Amazon S3, Amazon DynamoDB, atau Amazon DocumentDB, dan simpan hanya referensi dalam node Neptunus.

Dalam beberapa kasus, memilih ukuran instans yang lebih besar bisa lebih murah. Jika I/O biaya Anda sangat tinggi karena rendahBufferCacheHitRatio, ada kemungkinan bahwa cache buffer yang lebih besar akan secara signifikan mengurangi biaya itu. Itu karena semua data akan masuk ke dalam cache alih-alih sering ditukar dari penyimpanan dan menimbulkan kecepatan transfer. I/O

Neptunus menggunakan kloning copy-on-write. Saat mengkloning untuk membagi grafik menjadi beberapa pecahan, mungkin lebih efisien untuk tidak menghapus data yang tidak diinginkan pada kloning kloning karena itu akan melibatkan pembuatan halaman data baru, yang mengakibatkan peningkatan biaya penyimpanan. Data yang tidak berubah dari sebelum peristiwa kloning akan ada dalam satu halaman data yang dibagikan di dua cluster dan akan dikenakan biaya hanya untuk salinan tunggal itu.

Jangan aktifkan indeks OSGP atau gunakan instans R5d kecuali Anda telah menguji untuk mengonfirmasi bahwa indeks tersebut membuat perbedaan besar dalam beban kerja Anda. Keduanya dirancang untuk skenario yang jarang terjadi, dan mereka dapat meningkatkan biaya Anda untuk keuntungan minimal atau tanpa keuntungan.