Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pedoman operasional dasar Amazon Neptunus
Berikut ini adalah panduan operasional dasar yang harus Anda ikuti saat bekerja dengan Neptune.
+ Memahami instans DB Neptune sehingga Anda dapat mengukurnya dengan tepat untuk kinerja dan persyaratan kasus penggunaan. Lihat [Klaster dan Instans DB Amazon Neptune](feature-overview-db-clusters.md).
+ Pantau CPU dan penggunaan memori Anda. Hal ini membantu Anda tahu kapan harus bermigrasi ke kelas instans DB dengan kapasitas CPU atau memori yang lebih besar untuk mencapai kinerja kueri yang Anda butuhkan. Anda dapat mengatur Amazon CloudWatch untuk memberi tahu Anda saat pola penggunaan berubah atau saat Anda mendekati kapasitas penerapan. Dengan cara ini, Anda dapat mempertahankan performa dan ketersediaan sistem. Untuk detailnya, lihat [Pemantauan instans](feature-overview-db-clusters.md#feature-overview-monitoring-instances) dan [Pemantauan Neptune](monitoring.md).
Karena Neptune memiliki manajer memori sendiri, melihat penggunaan memori yang relatif rendah bahkan ketika penggunaan CPU tinggi itu hal yang normal. Menghadapi out-of-memory pengecualian saat menjalankan kueri adalah indikator terbaik yang Anda butuhkan untuk meningkatkan memori yang dapat dibebaskan.
+ Aktifkan pencadangan otomatis dan atur jendela pencadangan agar terjadi pada waktu yang tepat.
+ Tes failover untuk instans DB Anda untuk memahami berapa lama proses untuk kasus penggunaan Anda. Hal ini juga membantu memastikan bahwa aplikasi yang mengakses instans DB Anda dapat secara otomatis terhubung ke instans DB baru setelah failover.
+ Jika memungkinkan, jalankan klien Anda dan klaster Neptune di wilayah dan VPC yang sama, karena koneksi lintas wilayah dengan peering VPC dapat memperkenalkan penundaan dalam permintaan waktu respons. Untuk respons kueri milidetik satu digit, perlu untuk menjaga klien dan klaster Neptune di wilayah dan VPC yang sama.
+ Ketika Anda membuat instance read-replica, itu harus setidaknya sebesar instance penulis utama. Hal ini membantu menjaga kelambatan replikasi di pemeriksaan, dan menghindari replika restart. Lihat [Menghindari kelas instans yang berbeda dalam sebuah klaster](#best-practices-loader-heterogeneous-instances).
+ Sebelum mengupgrade ke versi mesin utama baru, pastikan untuk menguji aplikasi Anda sebelum Anda meng-upgrade. Anda dapat melakukan ini dengan mengkloning klaster DB Anda sehingga klon klaster menjalankan versi mesin baru, lalu menguji aplikasi Anda pada klon.
+ Untuk memfasilitasi failover, semua instans idealnya harus berukuran yang sama.
**Topics**
+ [Praktik terbaik keamanan Amazon Neptunus](best-practices-general-security.md)
+ [Menghindari kelas instans yang berbeda dalam sebuah klaster](#best-practices-loader-heterogeneous-instances)
+ [Hindari restart berulang selama pemuatan massal](#best-practices-loader-repeated-restarts)
+ [Aktifkan Indeks OSGP jika Anda memiliki sejumlah besar predikat](#best-practices-general-predicates)
+ [Menghindari transaksi yang berjalan lama jika memungkinkan](#best-practices-general-long-running-transactions)
+ [Praktik terbaik untuk menggunakan metrik Neptunus](best-practices-general-metrics.md)
+ [Praktik terbaik untuk menyetel kueri Neptunus](#best-practices-general-tuning)
+ [Load balancing di seluruh replika baca](#best-practices-general-loadbalance)
+ [Memuat lebih cepat menggunakan instance sementara yang lebih besar](#best-practices-loader-tempinstance)
+ [Mengubah ukuran instans penulis Anda dengan melakukan failover pada replika-baca](#best-practices-resize-instance)
+ [Coba lagi unggah setelah kesalahan terputus tugas prefetch data](#load-api-reference-status-interrupted)
# Praktik terbaik keamanan Amazon Neptunus
Gunakan akun AWS Identity and Access Management (IAM) untuk mengontrol akses ke tindakan Neptunus API. Kontrol tindakan yang membuat, memodifikasi, atau menghapus sumber daya Neptune (seperti instans DB, grup keamanan, grup opsi, atau grup parameter), dan tindakan yang melakukan tindakan administratif umum (seperti membuat cadangan dan memulihkan instans DB).
+ Gunakan kredenal sementara daripada persisten bila memungkinkan.
+ Menetapkan akun IAM individu untuk setiap orang yang mengelola sumber daya Amazon Relational Database Service (Amazon RDS). Jangan pernah menggunakan pengguna root AWS akun untuk mengelola sumber daya Neptunus. Buat pengguna IAM untuk semua orang, termasuk Anda sendiri.
+ Berikan setiap pengguna set izin minimum yang diperlukan untuk melakukan tugas mereka.
+ Gunakan grup IAM untuk mengelola izin secara efektif bagi beberapa pengguna.
+ Putar kredensial IAM Anda secara rutin.
Untuk informasi lebih lanjut tentang menggunakan IAM untuk mengakses sumber daya Neptune, lihat [Mengamankan basis data Amazon Neptunus Anda](security.md). Untuk informasi umum tentang bekerja dengan IAM, lihat [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html) dan [Praktik Terbaik IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) dalam *Panduan Pengguna IAM*.
## Menghindari kelas instans yang berbeda dalam sebuah klaster
Ketika klaster DB Anda berisi instans dalam kelas yang berbeda, masalah dapat terjadi dari waktu ke waktu. Masalah yang paling umum adalah bahwa instans pembaca kecil bisa masuk ke siklus restart berulang karena perlambatan replikasi. Jika simpul pembaca memiliki konfigurasi kelas instans DB yang lebih lemah dari instans DB penulis, volume perubahan bisa terlalu besar bagi pembaca untuk mengimbanginya.
**penting**
Untuk menghindari restart berulang yang disebabkan oleh perlambatan replikasi, konfigurasikan klaster DB Anda sehingga semua instans memiliki kelas instans yang sama (ukuran).
Anda dapat melihat jeda antara instance penulis (primer) dan pembaca di cluster DB Anda menggunakan `ClusterReplicaLag` metrik di Amazon CloudWatch. Metrik `VolumeWriteIOPs` juga memungkinkan Anda mendeteksi aktivitas tulis di klaster Anda yang dapat menyebabkan perlambatan replikasi.
## Hindari restart berulang selama pemuatan massal
Jika Anda mengalami siklus restart replika baca berulang karena kelambatan replikasi selama pemuatan massal, replika Anda kemungkinan tidak dapat mengikuti penulis di cluster DB Anda.
Baik skala pembaca menjadi lebih besar dari penulis, atau hapus sementara selama pemuatan massal dan kemudian buat ulang setelah selesai.
## Aktifkan Indeks OSGP jika Anda memiliki sejumlah besar predikat
Jika model data Anda berisi sejumlah besar predikat yang berbeda (lebih dari seribu dalam banyak kasus), Anda mungkin mengalami penurunan kinerja dan biaya operasional yang lebih tinggi.
Jika ini masalahnya, Anda dapat meningkatkan kinerja dengan mengaktifkan indeks [OSGP](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp). Lihat [Indeks OSGP](features-lab-mode.md#features-lab-mode-features-osgp-index).
## Menghindari transaksi yang berjalan lama jika memungkinkan
Transaksi berjalan lama pada instans pembaca atau instans penulis dengan penulisan bersamaan, dapat menyebabkan masalah tak terduga dari jenis berikut:
Transaksi berjalan lama pada instans pembaca atau instans penulis dengan penulisan bersamaan dapat mengakibatkan akumulasi besar versi yang berbeda dari data. Hal ini dapat memunculkan latensi yang lebih tinggi untuk kueri baca yang menyaring sebagian besar hasil mereka.
Dalam beberapa kasus, versi akumulasi selama berjam-jam dapat menyebabkan penulisan baru mengalami penyempitan.
Sebuah transaksi baca-tulis yang berjalan lama dengan banyak penulisan juga dapat menyebabkan masalah jika instans dimulai ulang. Jika instans dimulai ulang dari peristiwa pemeliharaan atau kerusakan, semua penulisan yang tidak diterapkan dikembalikan. Operasi pembatalan biasanya berjalan di latar belakang dan tidak memblokir instans dari aktif kembali, tetapi setiap penulisan baru yang berkonflik dengan operasi yang dikembalikan akan gagal.
Sebagai contoh, jika kueri yang sama dicoba lagi setelah sambungan terputus dalam proses sebelumnya mungkin gagal ketika instans dimulai ulang.
Waktu yang dibutuhkan untuk operasi pembatalan sebanding dengan ukuran perubahan yang terlibat.
# Praktik terbaik untuk menggunakan metrik Neptunus
Untuk mengidentifikasi masalah performa yang disebabkan sumber daya yang tidak mencukupi dan kemacetan umum lainnya, Anda dapat memantau metrik yang tersedia untuk klaster DB Neptune.
Pantau metrik performa secara rutin untuk mengumpulkan data tentang nilai rata-rata, maksimum, dan minimum untuk berbagai rentang waktu. Hal ini membantu mengidentifikasi saat performa menurun. Dengan menggunakan data ini, Anda dapat mengatur CloudWatch alarm Amazon untuk ambang metrik tertentu sehingga Anda diberi tahu jika tercapai.
Ketika Anda menyiapkan klaster DB baru dan menjalankannya dengan beban kerja tipikal, cobalah menangkap nilai rata-rata, maksimum, dan minimum dari semua metrik kinerja pada sejumlah interval yang berbeda (misalnya, satu jam, 24 jam, satu minggu, dua minggu) untuk mendapatkan gambaran tentang apa yang normal. Ini memberi Anda gambaran tentang apa yang normal. Hal ini membantu mendapatkan perbandingan untuk jam sibuk dan tidak sibuk. Kemudian, Anda dapat menggunakan informasi ini untuk mengidentifikasi saat performa turun di bawah tingkat standar, dan dapat menyesuaikan alarm.
Lihat [Memantau Neptunus Menggunakan Amazon CloudWatch](cloudwatch.md) untuk informasi tentang cara melihat metrik Neptune.
Berikut ini adalah metrik paling penting untuk memulai:
+ **BufferCacheHitRatio**— Persentase permintaan yang dilayani oleh cache buffer. Cache terlewat menambahkan latensi signifikan untuk eksekusi kueri. Jika rasio hit cache di bawah 99,9% dan laten menjadi masalah untuk aplikasi Anda, pertimbangkan untuk meningkatkan tipe instans untuk meng-cache lebih banyak data dalam memori.
+ **Pemanfaatan CPU** — Persentase kegiatan pemrosesan komputer yang digunakan. Nilai tinggi untuk konsumsi CPU mungkin sesuai, tergantung tujuan performa kueri Anda.
+ **Memori yang bisa dibebaskan** — Berapa banyak RAM yang tersedia di instans DB, dalam megabyte. Neptune memiliki manajer memori sendiri, jadi metrik ini mungkin lebih rendah dari yang Anda harapkan. Pertanda baik bahwa Anda harus mempertimbangkan untuk memutakhirkan kelas instans Anda ke kelas dengan lebih banyak RAM adalah jika kueri sering kali memberikan pengecualian. out-of-memory
Garis merah dalam metrik tab **Pemantauan** ditandai pada 75% untuk Metrik CPU dan Memori. Jika konsumsi memori instans sering melewati baris tersebut, periksa beban kerja Anda dan pertimbangkan untuk meningkatkan performa kueri.
## Praktik terbaik untuk menyetel kueri Neptunus
Salah satu cara terbaik untuk meningkatkan performa Neptune adalah dengan menyetel kueri yang paling sering digunakan dan paling intensif sumber daya untuk membuatnya lebih murah untuk dijalankan.
Untuk informasi tentang cara menyetel kueri Gremlin, lihat [Petunjuk kueri Gremlin](gremlin-query-hints.md) dan [Menyetel kueri Gremlin](gremlin-traversal-tuning.md). Untuk informasi tentang cara menyetel kueri SPARQL, lihat [Petunjuk kueri SPARQL](sparql-query-hints.md).
## Load balancing di seluruh replika baca
Perutean round-robin reader endpoint bekerja dengan mengubah host yang ditunjuk entri DNS. Klien harus membuat koneksi baru dan menyelesaikan catatan DNS untuk mendapatkan koneksi ke replika baca baru, karena WebSocket koneksi sering disimpan hidup untuk waktu yang lama.
Untuk mendapatkan replika baca yang berbeda untuk permintaan berturut-turut, pastikan klien Anda menyelesaikan entri DNS setiap kali tersambung. Ini mungkin memerlukan penutupan koneksi dan menyambung kembali ke reader endpoint.
Anda juga dapat menyeimbangkan beban permintaan di seluruh replika baca dengan menyambung ke titik akhir instans secara eksplisit.
## Memuat lebih cepat menggunakan instance sementara yang lebih besar
Performa beban Anda meningkat dengan ukuran instans yang lebih besar. Jika Anda tidak menggunakan tipe instans besar, tetapi ingin meningkatkan kecepatan beban, Anda dapat menggunakan instans yang lebih besar untuk dimuat, lalu menghapusnya.
**catatan**
Prosedur berikut berlaku untuk klaster baru. Jika Anda sudah memiliki klaster, Anda dapat menambahkan instans baru yang lebih besar lalu menaikkannya ke instans DB primer.
**Untuk memuat data menggunakan ukuran instans yang lebih besar**
1. Buat sebuah klaster dengan satu instans `r5.12xlarge`. Instans ini adalah instans DB primer.
1. Buat satu replika baca atau lebih dengan ukuran yang sama (`r5.12xlarge`).
Anda dapat membuat replika baca dalam ukuran yang lebih kecil, tetapi jika replika tersebut tidak cukup besar untuk mengimbangi penulisan yang dibuat oleh instans primer, replika mungkin sering restart. Waktu henti yang dihasilkan mengurangi kinerja secara dramatis.
1. Dalam perintah loader massal, sertakan `“parallelism” : “OVERSUBSCRIBE”` untuk memberi tahu Neptune agar menggunakan semua sumber daya CPU yang tersedia untuk memuat (lihat [Parameter Permintaan Loader Neptune](load-api-reference-load.md#load-api-reference-load-parameters)). Operasi beban kemudian akan dilanjutkan secepat I/O izin, yang umumnya membutuhkan 60-70% sumber daya CPU.
1. Muat data Anda menggunakan loader Neptune. Tugas pemuatan berjalan pada instans DB primer.
1. Setelah data selesai dimuat, pastikan untuk menskalakan semua instans di klaster ke tipe instans yang sama untuk menghindari biaya tambahan dan masalah restart berulang (lihat [Menghindari ukuran instans yang berbeda](#best-practices-loader-heterogeneous-instances)).
## Mengubah ukuran instans penulis Anda dengan melakukan failover pada replika-baca
Cara terbaik untuk mengubah ukuran instans dalam cluster DB Anda, termasuk instans penulis, adalah membuat atau memodifikasi instans replika-baca agar memiliki ukuran yang Anda inginkan, lalu sengaja melakukan failover pada replika-baca tersebut. Waktu henti yang dilihat oleh aplikasi Anda hanyalah waktu yang diperlukan untuk mengubah alamat IP penulis, yang seharusnya sekitar 3 sampai 5 detik.
API manajemen Neptune yang Anda gunakan untuk melakukan failover pada instans penulis saat ini ke instans replika-baca secara sengaja adalah [Kegagalan DBCluster](api-clusters.md#FailoverDBCluster). Jika Anda menggunakan klien Gremlin Java, Anda mungkin perlu membuat Objek klien baru setelah failover untuk mengambil alamat IP baru, seperti yang disebutkan [di sini](best-practices-gremlin-java-new-connection.md).
Pastikan untuk mengubah semua instans Anda ke ukuran yang sama agar Anda terhindar dari siklus restart berulang, seperti yang disebutkan di bawah ini.
## Coba lagi unggah setelah kesalahan terputus tugas prefetch data
Saat Anda memuat data ke Neptune menggunakan loader massal, status `LOAD_FAILED` kadang-kadang dapat menghasilkan, dengan pesan `PARSING_ERROR` dan `Data prefetch task interrupted` yang dilaporkan dalam menanggapi permintaan untuk informasi yang mendetail, seperti ini:
```
"errorLogs" : [
{
"errorCode" : "PARSING_ERROR",
"errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
"fileName" : "s3://amzn-s3-demo-bucket/some-source-file",
"recordNum" : 0
}
]
```
Jika Anda mengalami kesalahan ini, coba lagi permintaan unggah massal lagi.
Kesalahan terjadi ketika ada gangguan sementara yang biasanya tidak disebabkan oleh permintaan atau data Anda, dan biasanya dapat diselesaikan dengan menjalankan permintaan unggah massal lagi.
Jika Anda menggunakan pengaturan default, yaitu `"mode":"AUTO"`, dan `"failOnError":"TRUE"`, loader melewatkan file yang sudah berhasil dimuat dan melanjutkan pemuatan file yang belum dimuat saat terjadi gangguan.