Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Bersiap untuk bermigrasi dari Neo4j ke Neptunus
Migrasi dari database grafik Neo4j ke layanan database grafik Neptunus dapat didekati dengan salah satu dari dua cara utama: re-platforming atau refactoring/re-architecting. Pendekatan re-platforming melibatkan modifikasi model data dan arsitektur aplikasi yang ada untuk memanfaatkan kemampuan Neptunus dengan sebaik-baiknya, sedangkan pendekatan refactoring berfokus pada menemukan komponen yang setara di Neptunus untuk membangun implementasi yang sebanding. Dalam praktiknya, kombinasi dari strategi ini sering digunakan, karena proses migrasi melibatkan penyeimbangan arsitektur target Neptunus dengan kendala dan persyaratan dari implementasi Neo4j yang ada. Terlepas dari pendekatannya, kuncinya adalah bekerja mundur dari kasus penggunaan aplikasi untuk merancang model data, kueri, dan arsitektur keseluruhan yang paling sesuai dengan kebutuhan Anda.
## Pendekatan untuk bermigrasi
Saat memigrasikan aplikasi Neo4j ke Neptunus, kami merekomendasikan salah satu dari dua strategi: re-platforming, atau refactoring/re-architecting. Untuk informasi selengkapnya tentang strategi migrasi, lihat [6 Strategi untuk Migrasi Aplikasi ke Cloud](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/), posting blog oleh Stephen Orban.
*Pendekatan re-platforming*, kadang-kadang disebut *lift-tinker-and-shift*, melibatkan langkah-langkah berikut:
+ Identifikasi kasus penggunaan yang dimaksudkan untuk dipenuhi oleh aplikasi Anda.
+ Ubah model data grafik dan arsitektur aplikasi yang ada untuk mengatasi kebutuhan beban kerja ini dengan sebaik-baiknya menggunakan kemampuan Neptunus.
+ Tentukan cara memigrasikan data, kueri, dan bagian lain dari aplikasi sumber ke dalam model dan arsitektur target.
Pendekatan yang bekerja mundur ini memungkinkan Anda memigrasikan aplikasi Anda ke jenis solusi Neptunus yang dapat Anda rancang jika ini adalah proyek baru.
Sebaliknya, *pendekatan refactoring* melibatkan:
+ Mengidentifikasi komponen implementasi yang ada, termasuk infrastruktur, data, kueri, dan kemampuan aplikasi.
+ Menemukan ekuivalen di Neptunus yang dapat digunakan untuk membangun implementasi yang sebanding.
Pendekatan working-forward ini berusaha untuk menukar satu implementasi dengan implementasi lainnya.
Dalam praktiknya, Anda cenderung mengadopsi campuran dari dua pendekatan ini. Anda mungkin mulai dengan kasus penggunaan, merancang arsitektur Neptunus target, tetapi kemudian beralih ke implementasi Neo4j yang ada untuk mengidentifikasi batasan dan invarian yang harus Anda pertahankan. Misalnya, Anda mungkin harus terus berintegrasi dengan sistem eksternal lainnya, atau terus menawarkan khusus APIs kepada konsumen aplikasi grafik Anda. Dengan informasi ini, Anda dapat menentukan data apa yang sudah ada untuk pindah ke model target Anda, dan apa yang harus bersumber di tempat lain.
Di titik lain, Anda mungkin mulai dengan menganalisis bagian tertentu dari implementasi Neo4j Anda sebagai sumber informasi terbaik tentang pekerjaan yang dimaksudkan untuk dilakukan oleh aplikasi Anda. Arkeologi semacam itu dalam aplikasi yang ada dapat membantu menentukan kasus penggunaan yang kemudian dapat Anda rancang untuk menggunakan kemampuan Neptunus.
Baik Anda sedang membangun aplikasi baru menggunakan Neptunus atau memigrasikan aplikasi yang sudah ada dari Neo4j, sebaiknya Anda bekerja mundur dari kasus penggunaan untuk merancang model data, serangkaian kueri, dan arsitektur aplikasi yang memenuhi kebutuhan bisnis Anda.
# 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, ETL data, kueri aplikasi, penyimpanan data, dan operasi manajemen semuanya terjadi dalam kumpulan sumber daya komputasi yang sama, seperti instans EC2.
Neptunus, sebaliknya, adalah database grafik terfokus OLTP 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 tinggi, ketersediaan dan skalabilitas. 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](https://neo4j.com/docs/operations-manual/current/clustering/introduction/) Neo4j untuk memberikan daya tahan data, ketersediaan tinggi, dan skalabilitas. Arsitektur pengelompokan Neo4j menggunakan instance core-server dan read-replica:
+ 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](feature-overview-db-clusters.md) 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](neptune-serverless.md) 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](manage-console-autoscaling.md), untuk menyesuaikan ukuran instans pembaca secara otomatis berdasarkan beban kerja.
Menggunakan [fitur database global](neptune-global-database.md) Neptunus, Anda dapat mencerminkan cluster di hingga 5 wilayah lain.
Neptunus [juga toleran terhadap kesalahan menurut desain](backup-restore-overview-fault-tolerance.md):
+ 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 menskalakan operasi baca, [tambahkan instance replika baca atau aktifkan fungsionalitas](feature-overview-db-clusters.md#feature-overview-read-replicas) Neptunus Tanpa Server.](neptune-serverless.md)
+ 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](manage-console-add-replicas.md). Ini adalah praktik terbaik untuk memastikan bahwa target failover memiliki kelas instance yang mampu menangani beban kerja tulis aplikasi Anda jika dipromosikan ke primer.
# Perbedaan penyimpanan data antara Neptunus dan Neo4j
Neptunus menggunakan model [data grafik](feature-overview-data-model.md) berdasarkan model quad asli. Saat memigrasikan data Anda ke Neptunus, ada beberapa perbedaan dalam arsitektur model data dan lapisan penyimpanan yang harus Anda ketahui untuk memanfaatkan penyimpanan bersama terdistribusi dan terukur yang disediakan Neptunus secara optimal:
+ Neptunus tidak menggunakan skema atau batasan yang didefinisikan secara eksplisit. Ini memungkinkan Anda menambahkan node, tepi, dan properti secara dinamis tanpa harus menentukan skema sebelumnya. [Neptunus tidak membatasi nilai dan jenis data yang disimpan, kecuali seperti yang dicatat dalam batas Neptunus.](limits.md#limits-properties) Sebagai bagian dari arsitektur penyimpanan Neptunus, data juga [secara otomatis diindeks dengan](feature-overview-storage-indexing.md) cara yang menangani banyak pola akses yang paling umum. Arsitektur penyimpanan ini menghilangkan overhead operasional pembuatan dan pengelolaan skema database dan optimasi indeks.
+ Neptunus menyediakan arsitektur penyimpanan terdistribusi dan bersama yang unik yang secara otomatis menskalakan dalam potongan 10 GB seiring bertambahnya kebutuhan penyimpanan database Anda, hingga 128 tebibytes (TiB). Lapisan penyimpanan ini andal, tahan lama, dan toleran terhadap kesalahan, dengan data disalin 6 kali, dua kali di masing-masing 3 Availability Zone. Ini menyediakan semua cluster Neptunus dengan lapisan penyimpanan data yang sangat tersedia dan toleran kesalahan secara default. Arsitektur penyimpanan Neptunus mengurangi biaya dan menghilangkan kebutuhan untuk penyediaan atau penyediaan penyimpanan yang berlebihan untuk menangani pertumbuhan data masa depan.
[[Sebelum memigrasikan data Anda ke Neptunus, ada baiknya Anda membiasakan diri dengan model data grafik properti Neptunus dan semantik transaksi.](transactions.md)](feature-overview-storage-indexing.md#feature-overview-storage-indexing-gremlin)
# Perbedaan operasional antara Neptunus dan Neo4j
Neptunus adalah layanan yang dikelola sepenuhnya yang mengotomatiskan banyak tugas operasional normal yang harus Anda lakukan saat menggunakan database on-premise atau self-managed seperti Neo4j Enterprise atau Community Edition:
+ **[Pencadangan otomatis](backup-restore.md#backup-restore-overview-backups)** — Neptunus mencadangkan volume cluster Anda secara otomatis dan mempertahankan cadangan untuk periode retensi yang Anda tentukan (dari 1 hingga 35 hari). Pencadangan ini terus menerus dan bertahap, sehingga Anda dapat dengan cepat mengembalikan ke titik mana pun dalam periode retensi. Tidak ada dampak performa atau gangguan layanan basis data yang terjadi saat data cadangan ditulis.
+ **[Snapshot Manual](backup-restore.md)** — Neptunus memungkinkan Anda membuat snapshot volume penyimpanan cluster DB Anda untuk mencadangkan seluruh cluster DB. Snapshot semacam ini kemudian dapat digunakan untuk memulihkan database, membuat salinannya, dan membagikannya di seluruh akun.
+ **[Kloning](manage-console-cloning.md)** — Neptunus mendukung fitur kloning yang memungkinkan Anda membuat klon database yang hemat biaya dengan cepat. Klon menggunakan copy-on-write protokol untuk hanya membutuhkan ruang tambahan minimal setelah dibuat. Kloning basis data adalah cara yang efektif untuk mencoba fitur atau peningkatan Neptunus baru tanpa gangguan pada cluster asal.
+ **[Pemantauan](monitoring.md)** — Neptunus menyediakan berbagai metode untuk memantau kinerja dan penggunaan cluster Anda, termasuk:
+ Status instans
+ Integrasi dengan Amazon CloudWatch dan AWS CloudTrail
+ Kemampuan log audit
+ Notifikasi peristiwa
+ Penandaan
+ **[Keamanan](security.md)** — Neptunus menyediakan lingkungan yang aman secara default. Sebuah cluster berada dalam VPC pribadi yang menyediakan isolasi jaringan dari sumber daya lain. Semua lalu lintas dienkripsi melalui SSL, dan semua data dienkripsi saat istirahat menggunakan. AWS KMS
[Selain itu, Neptunus terintegrasi AWS Identity and Access Management dengan (IAM) untuk memberikan otentikasi.](iam-auth.md) [Dengan menentukan [kunci kondisi IAM](iam-condition-keys.md), Anda dapat menggunakan kebijakan IAM untuk memberikan kontrol akses halus atas tindakan data.](iam-data-access-policies.md)
## Perbedaan perkakas dan integrasi antara Neptunus dan Neo4j
Neptunus memiliki arsitektur yang berbeda untuk integrasi dan alat dari Neo4j, yang dapat memengaruhi arsitektur aplikasi Anda. Neptunus menggunakan sumber daya komputasi cluster untuk memproses kueri, tetapi memanfaatkan layanan best-in-class AWS lain untuk fungsionalitas seperti pencarian teks lengkap (menggunakan OpenSearch), ETL (menggunakan Glue), dan sebagainya. Untuk daftar lengkap integrasi ini, lihat[Integrasi Neptunus](integrations.md).