Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pedoman operasional dasar Amazon Neptune

Berikut ini adalah panduan operasional dasar yang harus Anda ikuti saat bekerja dengan Neptune.

Praktik terbaik keamanan Amazon Neptune

Gunakan akun AWS Identity and Access Management (IAM) untuk mengontrol akses ke tindakan API Neptune. 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).

Untuk informasi lebih lanjut tentang menggunakan IAM untuk mengakses sumber daya Neptune, lihat Keamanan di Amazon Neptune. Untuk informasi umum tentang bekerja dengan IAM, lihat AWS Identity and Access Management dan Praktik Terbaik IAM 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.

Anda dapat melihat perlambatan antara instans penulis (primer) dan pembaca di klaster DB Anda menggunakanClusterReplicaLag 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 curah

Jika Anda mengalami siklus replikasi baca berulang kali dimulai ulang karena jeda replikasi selama pemuatan massal, replika Anda kemungkinan tidak dapat mengikuti penulis di klaster DB Anda.

Baik skala pembaca menjadi lebih besar dari penulis, atau menghapusnya sementara selama beban massal dan kemudian membuatnya kembali setelah selesai.

Aktifkan Indeks OSGP jika Anda memiliki banyak 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 hal ini terjadi, Anda dapat meningkatkan kinerja dengan mengaktifkan Indeks OSGP. Lihat OSGPIndeks.

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 Neptune

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 data ini, Anda dapat mengatur CloudWatch alarm Amazon untuk ambang batas metrik tertentu sehingga Anda akan diperingatkan jika ambang ini 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 untuk informasi tentang cara melihat metrik Neptune.

Berikut ini adalah metrik paling penting untuk memulai:

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 Neptune

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 dan Menyetel kueri Gremlin. Untuk informasi tentang cara menyetel kueri SPARQL, lihat SPARQLpetunjuk kueri.

Load balancing di 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 dipertahankan agar aktif 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.

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 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.

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 upload setelah data prefetch tugas terputus kesalahan

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://some-source-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.