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

Praktik terbaik operasional untuk ISVs

Banyak pedoman di bagian ini adalah praktik terbaik untuk semua pelanggan, tetapi mereka telah menambahkan signifikansi untuk ISVs.

Perbarui cluster Neptunus Anda dengan versi terbaru

Dalam catatan rilis Amazon Neptunus, Anda dapat melihat bahwa setiap versi membawa sejumlah perbaikan bug, peningkatan kinerja, dan fitur baru. Simpan cluster Neptunus Anda pada versi terbaru sebanyak mungkin.

Jika Anda menemukan bug yang sebelumnya belum ditemukan di beban kerja Anda dan klaster Anda ada di versi terbaru, teknisi Neptunus dapat membuat tambalan pribadi untuk klaster Anda (jika diperlukan dan Anda menginginkannya). Patch dapat menjembatani hingga rilis berikutnya ketika perbaikan itu akan tersedia secara umum. Untuk membantu memperbarui cluster Anda ke versi terbaru, gunakan solusi Neptunus Biru/Hijau.

Gunakan delta alih-alih hapus dan ganti untuk konsumsi data

Anda dapat menggunakan beberapa teknik untuk menelan, atau menulis, data ke Neptunus. Banyak pelanggan mencoba menyederhanakan konsumsi data mereka dengan menghapus dan memasukkan kembali grafik mereka setiap kali perubahan diterima di umpan. Mereka mungkin menambahkan last-modified properti ke setiap node dan secara berkala memindai node yang belum dimodifikasi sejak beberapa tanggal tertentu dan menghapusnya. Meskipun teknik ini menyederhanakan proses konsumsi data, mereka memiliki implikasi kesehatan dan skalabilitas jangka panjang untuk cluster Neptunus Anda.

Pertama, Neptunus menggunakan pengkodean string kamus. Kecuali Anda secara eksplisit menentukan node dan tepi, Neptunus menghasilkan GUID yang direpresentasikan sebagai string untuk ID dan menyimpan string itu dalam kamus. IDs Jika Anda terus-menerus menghapus dan menambahkan objek, yang dihasilkan secara otomatis IDs akan menyebabkan kembung di kamus.

Kedua, skala Neptunus hingga menelan sekitar 120 K objek per detik secara maksimal. Jika Anda terus menghapus dan menambahkan objek, Anda mengkonsumsi banyak bandwidth pada objek yang pada dasarnya tidak berubah. Ini membatasi jumlah penyewa yang dapat Anda host di cluster, membutuhkan instance penulis yang lebih besar di cluster, dan membutuhkan lebih banyak operasi. I/O Semua faktor ini meningkatkan biaya Anda.

Kami sangat menyarankan Anda mengembangkan cara untuk menghitung delta sebenarnya dari apa yang telah berubah alih-alih menggunakan metode hapus dan tambahkan. Namun, beberapa sumber data tidak kondusif untuk ini (misalnya, panggilan API yang mengembalikan status saat ini, atau peristiwa yang tidak melacak persis apa yang berubah). Jika sumber data mentah Anda tidak kondusif untuk mengidentifikasi perubahan, gunakan proses ekstrak, transformasi, dan muat (ETL) Anda untuk menghitung delta. Misalnya, Anda dapat mempertahankan snapshot dari setiap pengambilan data sebelumnya dalam format Parket, gunakan AWS Glue untuk menghitung perbedaan antara snapshot tersebut, dan hanya mendorong perbedaan ke Neptunus.

Model bagaimana biaya Neptunus akan berkembang dengan penyewa Anda

Baik Anda menggunakan model silo, kolam renang, atau hibrida, biaya cloud Anda akan disesuaikan dengan ukuran penyewa Anda. Penyewa yang membutuhkan lebih banyak koneksi bersamaan membutuhkan instance yang lebih besar atau lebih banyak replika baca daripada yang memiliki koneksi bersamaan yang lebih sedikit. Hal yang sama berlaku untuk penyewa yang membutuhkan konsumsi data lebih cepat.

Tiga komponen biaya cluster Neptunus adalah ukuran instans (dan jumlah), ukuran data (GB-bulan), I/O dan operasi (per juta). Meskipun biaya-biaya ini umumnya spesifik untuk beban kerja, mereka menskalakan dengan ukuran dan volume data, mereka dapat diukur dengan menggunakan AWS alat. Lacak dan pahami skala ekonomi terhadap indikator utama ukuran penyewa Anda, termasuk bagaimana ukurannya bervariasi dari waktu ke waktu. Jika I/O biaya yang tidak dapat diprediksi memengaruhi margin Anda, pertimbangkan untuk memilih penyimpanan Neptunus I/O-Optimized untuk biaya yang lebih dapat diprediksi.

Skala cluster Anda untuk permintaan pelanggan

Tidak ada formula yang dicoba atau benar untuk mengukur ukuran instans Neptunus Anda dengan benar. Dokumentasi Neptunus memberikan panduan, tetapi ada terlalu banyak variabel untuk merekomendasikan pemetaan langsung. Variabel-variabel ini termasuk tetapi tidak terbatas pada yang berikut:

Rencanakan pengujian untuk menentukan ukuran optimal untuk beban kerja dan profil penyewa Anda. Secara umum, kami merekomendasikan penggunaan instans yang disediakan untuk efisiensi biaya dan prediktabilitas. Jika sasaran pengalaman pelanggan Anda memprioritaskan penskalaan optimal daripada biaya, pertimbangkan untuk menggunakan instans Neptunus Tanpa Server untuk memastikan pengalaman yang lebih konsisten terlepas dari fluktuasi beban kerja.

Jika beban kerja baca penyewa Anda memiliki variabilitas yang signifikan di puncak dan palungnya, gabungkan instance Neptunus Tanpa Server dengan auto-scaling Neptunus.  Biasanya dibutuhkan waktu 10-15 menit untuk replika baca baru untuk online setelah diinisialisasi. Ini berarti bahwa auto-scaling saja dapat menangani perubahan lalu lintas yang berkepanjangan, tetapi itu tidak cukup untuk mengubah lonjakan aktivitas dengan cepat. Dengan menggabungkan Neptunus Tanpa Server dan auto-scaling Neptunus, Anda dapat menskalakan instance naik atau turun dan menskalakan jumlah replika baca masuk dan keluar.

Jika penyewa Anda memiliki profil beban kerja atau perjanjian tingkat layanan (SLAs) yang berbeda secara signifikan, pertimbangkan untuk menggunakan titik akhir khusus dan replika baca khusus untuk mengarahkan lalu lintas ke instans yang dioptimalkan untuk lalu lintas tersebut. Optimasi dapat mencakup ukuran instance yang berbeda, pola kueri tertentu, atau pra-pemanasan cache buffer.