Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Perbedaan arsitektur antara Neptunus dan Neo4j
Ketika pelanggan pertama kali mempertimbangkan untuk memigrasikan aplikasi dari Neo4j ke Neptunus, seringkali tergoda untuk melakukan perbandingan berdasarkan ukuran instans. like-to-like Namun, arsitektur Neo4j dan Neptunus memiliki perbedaan mendasar. Neo4j didasarkan pada all-in-one pendekatan di mana pemuatan data, dataETL, kueri aplikasi, penyimpanan data, dan operasi manajemen semuanya terjadi dalam kumpulan sumber daya komputasi yang sama, seperti instance. EC2
Neptunus, sebaliknya, adalah OLTP database grafik terfokus di mana arsitektur memisahkan tanggung jawab dan di mana sumber daya dipisahkan sehingga mereka dapat skala secara dinamis dan independen.
Saat bermigrasi dari Neo4j ke Neptunus, tentukan persyaratan ketahanan, ketersediaan, dan skalabilitas data aplikasi Anda. Arsitektur cluster Neptunus menyederhanakan desain aplikasi yang membutuhkan daya tahan, ketersediaan, dan skalabilitas tinggi. Dengan pemahaman tentang arsitektur cluster Neptunus, Anda kemudian dapat merancang topologi cluster Neptunus untuk memenuhi persyaratan ini.
Arsitektur cluster Neo4j
Banyak aplikasi produksi menggunakan pengelompokan kausal
Server inti menyediakan daya tahan data dan toleransi kesalahan dengan mereplikasi data menggunakan protokol Raft.
Replika baca menggunakan pengiriman log transaksi untuk mereplikasi data secara asinkron untuk beban kerja throughput baca yang tinggi.
Setiap instance dalam cluster, apakah server inti atau replika baca, berisi salinan lengkap data grafik.
Arsitektur cluster Neptunus
Cluster Neptunus terdiri dari contoh penulis utama dan hingga 15 contoh replika baca. Semua instance di cluster berbagi layanan penyimpanan terdistribusi dasar yang sama yang terpisah dari instance.
Instance penulis utama mengoordinasikan semua operasi penulisan ke database dan dapat diskalakan secara vertikal untuk memberikan dukungan fleksibel untuk beban kerja penulisan yang berbeda. Ini juga mendukung operasi baca.
-
Instans replika baca mendukung operasi baca dari volume penyimpanan yang mendasarinya, dan memungkinkan Anda menskalakan secara horizontal untuk mendukung beban kerja baca tinggi. Mereka juga menyediakan ketersediaan tinggi dengan berfungsi sebagai target failover untuk instance utama.
catatan
Untuk beban kerja tulis yang berat, yang terbaik adalah menskalakan instance replika baca ke ukuran yang sama dengan instance penulis, untuk memastikan bahwa pembaca dapat tetap konsisten dengan perubahan data.
Volume penyimpanan yang mendasari menskalakan kapasitas penyimpanan secara otomatis saat data dalam database Anda meningkat, hingga 128 tebibytes (TiB) penyimpanan.
Ukuran instans bersifat dinamis dan independen. Setiap instance dapat diubah ukurannya saat cluster berjalan, dan replika baca dapat ditambahkan atau dihapus saat cluster sedang berjalan.
Fitur Neptunus Tanpa Server dapat meningkatkan kapasitas komputasi Anda naik dan turun secara otomatis saat permintaan naik dan turun. Hal ini tidak hanya dapat mengurangi overhead administratif Anda, ini juga memungkinkan Anda mengonfigurasi database untuk menangani lonjakan besar dalam permintaan tanpa menurunkan kinerja atau mengharuskan Anda untuk penyediaan berlebihan.
Anda dapat menghentikan cluster Neptunus hingga 7 hari.
Neptunus juga mendukung auto-scaling, untuk menyesuaikan ukuran instans pembaca secara otomatis berdasarkan beban kerja.
Menggunakan fitur database global Neptunus, Anda dapat mencerminkan cluster di hingga 5 wilayah lain.
Neptunus juga toleran terhadap kesalahan menurut desain:
Volume cluster yang menyediakan penyimpanan data ke semua instance di cluster mencakup beberapa Availability Zones (AZs) dalam satu. Wilayah AWS Setiap AZ berisi salinan lengkap data cluster.
Jika instance utama menjadi tidak tersedia, Neptunus secara otomatis gagal ke replika baca yang ada dengan nol kehilangan data, biasanya dalam waktu kurang dari 30 detik. Jika tidak ada replika baca yang ada di cluster, Neptunus secara otomatis menyediakan contoh utama baru — sekali lagi, dengan nol kehilangan data.
Apa artinya semua ini adalah bahwa ketika bermigrasi dari cluster kausal Neo4j ke Neptunus, Anda tidak perlu merancang topologi cluster secara eksplisit untuk daya tahan data yang tinggi dan ketersediaan tinggi. Ini membuat Anda mengukur cluster Anda untuk beban kerja baca dan tulis yang diharapkan, dan persyaratan ketersediaan yang meningkat yang mungkin Anda miliki, hanya dalam beberapa cara:
Untuk meningkatkan ketersediaan, distribusikan instance utama dan baca replika di klaster Anda melalui beberapa Availability Zones (AZs).
Untuk mengurangi waktu failover, sediakan setidaknya satu instance replika baca yang dapat berfungsi sebagai target failover untuk primer. Anda dapat menentukan urutan di mana instance replika baca dipromosikan ke primer setelah kegagalan dengan menetapkan prioritas setiap replika. Ini adalah praktik terbaik untuk memastikan bahwa target failover memiliki kelas instance yang mampu menangani beban kerja tulis aplikasi Anda jika dipromosikan ke primer.
