Penyediaan infrastruktur saat migrasi dari Neo4j ke Neptune - Amazon Neptune

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

Penyediaan infrastruktur saat migrasi dari Neo4j ke Neptune

Klaster Amazon Neptune dibuat untuk menskalakan dalam tiga dimensi: penyimpanan, kapasitas tulis, dan kapasitas baca. Bagian di bawah ini membahas opsi khusus untuk dipertimbangkan saat bermigrasi.

Penyimpanan

Penyimpanan untuk setiap klaster Neptune secara otomatis disediakan, tanpa overhead administratif pada bagian Anda. Ini mengubah ukuran secara dinamis dalam potongan 10 GB karena kebutuhan penyimpanan cluster meningkat. Akibatnya, tidak perlu memperkirakan dan menyediakan atau penyimpanan over-provision untuk menangani pertumbuhan data di future.

Menyediakan kapasitas

Neptune menyediakan instans penulis tunggal yang dapat diskalakan secara vertikal ke ukuran instans apa pun yang tersedia di halaman harga Neptune. Saat membaca dan menulis data ke instance penulis, semua transaksi sesuai dengan ACID, dengan isolasi data sebagaimana didefinisikan dalamTingkat Isolasi Transaksi di Neptune.

Memilih ukuran optimal untuk instans penulis memerlukan menjalankan tes beban untuk menentukan ukuran instans optimal untuk beban kerja Anda. Setiap contoh dalam Neptune dapat diubah ukurannya setiap saat dengan memodifikasi kelas instans DB. Anda dapat memperkirakan ukuran instans awal berdasarkan konkurensi dan latensi kueri rata-rata seperti yang dijelaskan di bawah iniMemperkirakan ukuran instans optimal saat menyediakan klaster Anda.

Menyediakan kapasitas

Neptune dibuat untuk menskalakan instance read-replica baik secara horizontal, dengan menambahkan hingga 15 di antaranya dalam klaster (atau lebih dalam database global Neptune), dan secara vertikal ke ukuran instans apa pun yang tersedia di halaman harga Neptune. Semua instance read-replica Neptune menggunakan volume penyimpanan dasar yang sama, memungkinkan replikasi transparan data dengan jeda minimal.

Selain mengaktifkan penskalaan horizontal permintaan baca dalam klaster Neptune, replika baca juga bertindak sebagai target failover untuk instance penulis untuk mengaktifkan ketersediaan tinggi. LihatPedoman operasional dasar Amazon Neptune saran tentang cara menentukan jumlah dan penempatan replika baca yang sesuai di klaster Anda.

Untuk aplikasi yang konektivitas dan beban kerja tidak dapat diprediksi, Neptune juga mendukung fitur auto-scaling yang dapat secara otomatis menyesuaikan jumlah replika Neptune berdasarkan kriteria yang Anda tentukan.

Untuk menentukan ukuran dan jumlah contoh replika baca yang optimal, perlu menjalankan pengujian beban untuk menentukan karakteristik beban kerja baca yang harus mereka dukung. Setiap contoh dalam Neptune dapat diubah ukurannya setiap saat dengan memodifikasi kelas instans DB. Anda dapat memperkirakan ukuran instans awal berdasarkan konkurensi dan latensi kueri rata-rata, seperti yang dijelaskan di bagian berikutnya.

Gunakan Neptune Tanpa Server untuk menskalakan instans pembaca dan penulis secara otomatis sesuai kebutuhan

Meskipun sering membantu untuk dapat memperkirakan kapasitas komputasi yang diperlukan oleh beban kerja yang Anda antisipasi, Anda dapat mengonfigurasi fitur Neptune Serverless untuk meningkatkan dan menurunkan kapasitas baca dan tulis secara otomatis. Ini dapat membantu Anda memenuhi persyaratan puncak sementara juga scaling kembali secara otomatis ketika permintaan menurun.

Memperkirakan ukuran instans optimal saat menyediakan klaster Anda

Estimasi ukuran instans optimal memerlukan mengetahui latensi kueri rata-rata di Neptune, saat beban kerja Anda berjalan, serta jumlah kueri bersamaan yang sedang diproses. Perkiraan kasar ukuran instans dapat dihitung sebagai latensi kueri rata-rata dikalikan dengan jumlah kueri bersamaan. Ini memberi Anda jumlah rata-rata utas bersamaan yang diperlukan untuk menangani beban kerja.

Setiap vCPU dalam instance Neptune dapat mendukung dua utas kueri bersamaan, jadi membagi thread dengan 2 memberikan jumlah vCPUs yang diperlukan, yang kemudian dapat dikorelasikan dengan ukuran instans yang sesuai pada halaman harga Neptune. Misalnya:

Average Query Latency: 30ms (0.03s) Number of concurrent queries: 1000/second Number of threads needed: 0.03 x 1000 = 30 threads Number of vCPUs needed: 30 / 2 = 15 vCPUs

Menghubungkan ini dengan jumlah vCPUs dalam sebuah instance, kita melihat bahwa kita mendapatkan perkiraan kasar bahwa ar5.4xlarge akan menjadi contoh yang direkomendasikan untuk mencoba beban kerja ini. Perkiraan ini kasar dan hanya dimaksudkan untuk memberikan panduan awal tentang pemilihan ukuran instans. Aplikasi apa pun harus melalui latihan ukuran kanan untuk menentukan jumlah dan jenis instance yang sesuai untuk beban kerja.

Persyaratan memori juga harus diperhitungkan, serta persyaratan pemrosesan. Neptune paling berkinerja saat data yang diakses oleh kueri tersedia di cache kolam buffer memori utama. Penyediaan memori yang cukup juga dapat mengurangi biaya I/O secara signifikan.

Detail tambahan dan panduan tentang ukuran instance dalam klaster Neptune dapat ditemukan diMengukur instans DB dalam sebuah klaster Neptune DB halaman.