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.

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 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 OSGP Indeks 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 OSGPindeks. Lihat OSGPIndeksnya.

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

Load balancing di seluruh replika baca

Routing round-robin endpoint pembaca bekerja dengan mengubah host yang ditunjuk oleh entri. DNS Klien harus membuat koneksi baru dan menyelesaikan DNS catatan 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 DNS entri setiap kali terhubung. 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.

APIManajemen Neptunus yang Anda gunakan untuk gagal atas instance penulis saat ini ke instance read-replica dengan 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 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://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.