Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Migrasi dari Neo4j ke Amazon Neptune
Neo4j dan Amazon Neptunus keduanya adalah database grafik, dirancang untuk beban kerja grafik transaksional online yang mendukung model data grafik properti berlabel. Kesamaan ini membuat Neptunus menjadi pilihan umum bagi pelanggan yang ingin memigrasikan aplikasi Neo4j mereka saat ini. Namun, migrasi ini tidak hanya lift dan shift, karena ada perbedaan dalam bahasa dan dukungan fitur, karakteristik operasional, arsitektur server, dan kemampuan penyimpanan antara dua database.
Halaman ini membingkai proses migrasi dan memunculkan hal-hal yang perlu dipertimbangkan sebelum memigrasikan aplikasi grafik Neo4j ke Neptunus. Pertimbangan ini berlaku secara umum untuk aplikasi grafik Neo4j apa pun, baik yang didukung oleh basis data Komunitas, Perusahaan, atau Aura. Meskipun setiap solusi unik dan mungkin memerlukan prosedur tambahan, semua migrasi mengikuti pola umum yang sama.
Setiap langkah yang dijelaskan dalam bagian berikut mencakup pertimbangan dan rekomendasi untuk menyederhanakan proses migrasi. Selain itu, ada [alat sumber terbuka, dan posting blog](migration-resources.md) yang menggambarkan proses, dan [bagian kompatibilitas fitur](migration-compatibility.md) dengan opsi arsitektur yang direkomendasikan.
**Topics**
+ [Informasi umum tentang migrasi dari Neo4j ke Neptunus](migrating-from-neo4j-general.md)
+ [Bersiap untuk bermigrasi dari Neo4j ke Neptunus](preparing-to-migrate-from-neo4j.md)
+ [Penyediaan infrastruktur saat bermigrasi dari Neo4j ke Neptunus](migration-provisioning-infrastructure.md)
+ [Migrasi data dari Neo4j ke Neptunus](migration-data-migration.md)
+ [Migrasi aplikasi dari Neo4j ke Neptunus](migration-app-migration.md)
+ [Kompatibilitas Neptunus dengan Neo4j](migration-compatibility.md)
+ [Menulis ulang kueri Cypher untuk dijalankan di OpenCypher di Neptunus](migration-opencypher-rewrites.md)
+ [Sumber daya untuk bermigrasi dari Neo4j ke Neptunus](migration-resources.md)
# Informasi umum tentang migrasi dari Neo4j ke Neptunus
Dengan [dukungan Neptunus untuk bahasa kueri OpenCypher](feature-opencypher-compliance.md), Anda dapat memindahkan sebagian besar beban kerja Neo4j yang menggunakan protokol Bolt atau HTTPS ke Neptunus. Namun, OpenCypher adalah spesifikasi open-source yang berisi sebagian besar tetapi tidak semua fungsi yang didukung oleh database lain seperti Neo4j.
Meskipun kompatibel dalam banyak hal, Neptunus bukanlah pengganti drop-in untuk Neo4j. Neptunus adalah layanan database grafik yang dikelola sepenuhnya dengan fitur perusahaan seperti ketersediaan tinggi dan daya tahan tinggi yang secara arsitektur berbeda dari Neo4j. Neptunus berbasis instans, dengan satu instance penulis utama dan hingga 15 contoh replika baca yang memungkinkan Anda menskalakan kapasitas baca secara horizontal. Menggunakan [Neptunus](neptune-serverless.md) Tanpa Server, Anda dapat secara otomatis menskalakan kapasitas komputasi Anda ke atas dan ke bawah tergantung pada volume kueri. Ini tidak tergantung pada penyimpanan Neptunus, yang diskalakan secara otomatis saat Anda menambahkan data.
Neptunus mendukung spesifikasi standar [OpenCypher open-source](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf), versi 9. Di AWS, kami percaya bahwa open source baik untuk semua orang dan kami berkomitmen untuk membawa nilai open source kepada pelanggan kami, dan untuk membawa keunggulan operasional AWS ke komunitas open source.
Namun, banyak aplikasi yang berjalan di Neo4j juga menggunakan fitur berpemilik yang tidak bersumber terbuka dan Neptunus tidak mendukung. Misalnya, Neptunus tidak mendukung prosedur APOC, beberapa klausa dan fungsi khusus Cypher, dan,, atau tipe data. `Char` `Date` `Duration` Neptunus melakukan transmisi otomatis tipe data yang hilang [ke](bulk-load-tutorial-format-opencypher.md#bulk-load-tutorial-format-opencypher-data-types) tipe data yang didukung.
Selain OpenCypher, Neptunus juga mendukung bahasa kueri [Apache TinkerPop Gremlin](https://tinkerpop.apache.org/docs/current/reference/#traversal) untuk grafik properti (serta SPARQL untuk data RDF). Gremlin dapat beroperasi dengan OpenCypher pada grafik properti yang sama, dan dalam banyak kasus Anda dapat menggunakan Gremlin untuk menyediakan fungsionalitas yang tidak disediakan OpenCypher. Di bawah ini adalah perbandingan singkat dari kedua bahasa tersebut:
| | OpenCypher | Gremlin |
| --- | --- | --- |
| Gaya | Deklaratif | Imperatif |
| Sintaksis | Pencocokan pola Match p=(a)-[:route]->(d)
WHERE a.code='ANC'
RETURN p
| Berbasis traversal g.V().has('code', 'ANC').
out('route').path().
by(elementMap()) |
| Kemudahan penggunaan | Terinspirasi SQL, dapat dibaca oleh non-programmer | Kurva belajar yang lebih curam, mirip dengan bahasa pemrograman seperti Java |
| Fleksibilitas | Rendah | Tinggi |
| Dukungan kueri | Kueri berbasis string | Kueri berbasis string atau kode in-line yang didukung oleh pustaka klien |
| Klien | HTTPS dan Bolt | HTTPS dan Websockets |
Secara umum, tidak perlu mengubah model data Anda untuk bermigrasi dari Neo4j ke Neptunus, karena Neo4j dan Neptunus mendukung data grafik properti berlabel (LPG). Namun, Neptunus memiliki beberapa perbedaan arsitektur dan model data yang dapat Anda manfaatkan untuk mengoptimalkan kinerja. Contoh:
+ IDs Neptunus diperlakukan sebagai warga negara kelas satu.
+ Neptunus [AWS Identity and Access Management menggunakan kebijakan (IAM)](iam-auth.md) untuk mengamankan akses ke data grafik Anda dengan cara yang fleksibel dan terperinci.
+ [Neptunus menyediakan beberapa cara [untuk menggunakan notebook Jupyter untuk](graph-notebooks.md) menjalankan kueri dan memvisualisasikan hasilnya.](notebooks-visualization.md) Neptunus juga bekerja [dengan](visualization-tools.md) alat visualisasi pihak ketiga.
+ > Meskipun Neptunus tidak memiliki pengganti drop-in untuk perpustakaan Neo4j Graph Data Science (GDS), Neptunus mendukung analisis grafik saat ini melalui berbagai solusi. Misalnya, beberapa [contoh notebook](https://github.com/aws/graph-notebook/tree/main/src/graph_notebook/notebooks/01-Neptune-Database/03-Sample-Applications/06-Data-Science-Samples) menunjukkan cara memanfaatkan [integrasi Neptunus dengan SDK AWS Pandas](https://github.com/amazon-archives/fully-automated-neo4j-to-neptune) dalam lingkungan Python untuk menjalankan analitik pada data grafik.
Silakan hubungi untuk AWS mendukung atau melibatkan tim AWS akun Anda jika Anda memiliki pertanyaan. Kami menggunakan umpan balik Anda untuk memprioritaskan fitur baru yang akan memenuhi kebutuhan Anda.
# 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).
# Penyediaan infrastruktur saat bermigrasi dari Neo4j ke Neptunus
Cluster Amazon Neptunus dibangun untuk skala dalam tiga dimensi: penyimpanan, kapasitas tulis, dan kapasitas baca. Bagian di bawah ini membahas opsi khusus untuk dipertimbangkan saat bermigrasi.
## Penyimpanan penyediaan
Penyimpanan untuk setiap cluster Neptunus secara otomatis disediakan, tanpa biaya administrasi apa pun di pihak Anda. Ini mengubah ukuran secara dinamis dalam potongan 10 GB karena kebutuhan penyimpanan cluster meningkat. Akibatnya, tidak perlu memperkirakan dan menyediakan atau penyimpanan yang berlebihan untuk menangani pertumbuhan data di masa depan.
## Penyediaan kapasitas tulis
[Neptunus menyediakan contoh penulis tunggal yang dapat diskalakan secara vertikal ke ukuran instans apa pun yang tersedia di halaman harga Neptunus.](https://aws.amazon.com/neptune/pricing/) Saat membaca dan menulis data ke instance penulis, semua transaksi sesuai dengan ACID, dengan isolasi data sebagaimana didefinisikan dalam[Tingkat Isolasi Transaksi di Neptune](transactions-neptune.md).
Memilih ukuran optimal untuk instance writer memerlukan menjalankan pengujian beban untuk menentukan ukuran instans optimal untuk beban kerja Anda. Setiap instance dalam Neptunus dapat diubah ukurannya kapan saja [dengan memodifikasi](manage-console-instances-modify.md) kelas instans DB. Anda dapat memperkirakan ukuran instans awal berdasarkan konkurensi dan latensi kueri rata-rata seperti yang dijelaskan di bawah ini. [Memperkirakan ukuran instans optimal saat menyediakan klaster Anda](#migration-provisioning-instance-sizing)
## Penyediaan kapasitas baca
[Neptunus dibangun untuk menskalakan instance replika baca baik secara horizontal, dengan menambahkan hingga 15 di antaranya dalam sebuah cluster (atau lebih dalam database [global Neptunus), dan secara vertikal ke ukuran instans apa pun yang tersedia di halaman harga Neptunus](neptune-global-database.md).](https://aws.amazon.com/neptune/pricing/) Semua instance replika baca Neptunus menggunakan volume penyimpanan dasar yang sama, memungkinkan replikasi data transparan dengan jeda minimal.
Selain mengaktifkan penskalaan horizontal permintaan baca dalam cluster Neptunus, replika baca juga bertindak sebagai target failover untuk instance penulis untuk memungkinkan ketersediaan tinggi. Lihat [Pedoman operasional dasar Amazon Neptunus](best-practices-general-basic.md) saran tentang cara menentukan jumlah dan penempatan replika baca yang sesuai di klaster Anda.
Untuk aplikasi di mana konektivitas dan beban kerja tidak dapat diprediksi, Neptunus juga mendukung [fitur auto-scaling yang dapat secara otomatis menyesuaikan jumlah replika](manage-console-autoscaling.md) Neptunus berdasarkan kriteria yang Anda tentukan.
Untuk menentukan ukuran dan jumlah instans replika baca yang optimal, diperlukan pengujian beban yang dijalankan untuk menentukan karakteristik beban kerja baca yang harus mereka dukung. Setiap instance dalam Neptunus dapat diubah ukurannya kapan saja [dengan memodifikasi](manage-console-instances-modify.md) kelas instans DB. Anda dapat memperkirakan ukuran instans awal berdasarkan konkurensi dan latensi kueri rata-rata, seperti yang dijelaskan di bagian [berikutnya](#migration-provisioning-instance-sizing).
## Gunakan Neptunus Tanpa Server untuk menskalakan instance pembaca dan penulis secara otomatis sesuai kebutuhan
Meskipun seringkali bermanfaat untuk dapat memperkirakan kapasitas komputasi yang diperlukan oleh beban kerja yang Anda antisipasi, Anda dapat mengonfigurasi fitur Neptunus [Tanpa Server untuk menskalakan kapasitas baca dan tulis](neptune-serverless.md) ke atas dan ke bawah secara otomatis. Ini dapat membantu Anda memenuhi persyaratan puncak sambil juga menskalakan kembali secara otomatis saat permintaan menurun.
## Memperkirakan ukuran instans optimal saat menyediakan klaster Anda
Estimasi ukuran instans optimal memerlukan mengetahui latensi kueri rata-rata di Neptunus, 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 Neptunus dapat mendukung dua utas kueri bersamaan, jadi membagi utas dengan 2 memberikan jumlah v yang CPUs diperlukan, yang kemudian dapat dikorelasikan dengan ukuran instance yang sesuai pada halaman harga Neptunus.](https://aws.amazon.com/neptune/pricing/) Contoh:
```
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 v CPUs dalam sebuah instance, kita melihat bahwa kita mendapatkan perkiraan kasar bahwa a `r5.4xlarge` akan menjadi contoh yang direkomendasikan untuk dicoba untuk beban kerja ini. Perkiraan ini kasar dan hanya dimaksudkan untuk memberikan panduan awal tentang pemilihan ukuran instance. Aplikasi apa pun harus melalui latihan ukuran yang tepat untuk menentukan jumlah dan jenis instance yang sesuai untuk beban kerja.
Persyaratan memori juga harus diperhitungkan, serta persyaratan pemrosesan. Neptunus paling berkinerja ketika data yang diakses oleh kueri tersedia di cache kumpulan buffer memori utama. Menyediakan memori yang cukup juga dapat mengurangi I/O biaya secara signifikan.
Detail tambahan dan panduan tentang ukuran instance di cluster Neptunus dapat ditemukan di halaman. [Mengukur instans DB dalam sebuah klaster Neptune DB](feature-overview-db-clusters.md#feature-overview-sizing-instances)
# Migrasi data dari Neo4j ke Neptunus
Saat melakukan migrasi dari Neo4j ke Amazon Neptunus, memigrasikan data adalah langkah besar dalam prosesnya. Ada beberapa pendekatan untuk memigrasi data. Pendekatan yang benar ditentukan oleh kebutuhan aplikasi, ukuran data, dan jenis migrasi yang diinginkan. Namun, banyak dari migrasi ini semuanya memerlukan penilaian pertimbangan yang sama, yang beberapa disorot di bawah ini.
**catatan**
Lihat [Migrasi database grafik Neo4j ke Neptunus dengan utilitas yang sepenuhnya otomatis](https://aws.amazon.com/blogs/database/migrating-a-neo4j-graph-database-to-amazon-neptune-with-a-fully-automated-utility/) di [Blog AWS Database](https://aws.amazon.com/blogs/?awsf.blog-master-category=category%23database) untuk step-by-step panduan lengkap tentang salah satu contoh cara melakukan migrasi data offline.
## Menilai migrasi data dari Neo4j ke Neptunus
Langkah pertama saat menilai migrasi data apa pun adalah menentukan bagaimana Anda akan memigrasikan data. Opsi bergantung pada arsitektur aplikasi yang dimigrasikan, ukuran data, dan kebutuhan ketersediaan selama migrasi. Secara umum, migrasi cenderung jatuh ke dalam salah satu dari dua kategori: online atau offline.
Migrasi offline cenderung menjadi yang paling sederhana untuk dilakukan, karena aplikasi tidak menerima lalu lintas baca atau tulis selama migrasi. Setelah aplikasi berhenti menerima lalu lintas, data dapat diekspor, dioptimalkan, diimpor, dan aplikasi diuji sebelum aplikasi diaktifkan kembali.
Migrasi online lebih kompleks, karena aplikasi masih perlu menerima lalu lintas baca dan tulis saat data sedang dimigrasikan. Kebutuhan yang tepat dari setiap migrasi online mungkin berbeda, tetapi arsitektur umum umumnya akan serupa dengan yang berikut:
+ Umpan perubahan yang sedang berlangsung pada database perlu diaktifkan di Neo4j dengan mengonfigurasi [Neo4j Streams sebagai](https://neo4j.com/labs/kafka/4.0/producer/) sumber ke cluster Kafka.
+ Setelah ini selesai, ekspor sistem yang sedang berjalan dapat diambil, mengikuti instruksi[Mengekspor data dari Neo4j saat bermigrasi ke Neptunus](#migration-data-exporting), dan waktu yang dicatat untuk korelasi selanjutnya dengan topik Kafka.
+ Data yang diekspor kemudian diimpor ke Neptunus, mengikuti instruksi di. [Mengimpor data dari Neo4j saat bermigrasi ke Neptunus](#migration-data-importing)
+ Data yang diubah dari aliran Kafka kemudian dapat disalin ke cluster Neptunus menggunakan arsitektur yang mirip dengan yang dijelaskan dalam Menulis ke [Amazon Neptunus dari Amazon](https://github.com/aws-samples/amazon-neptune-samples/tree/master/gremlin/stream-2-neptune) Kinesis Data Streams. Perhatikan bahwa replikasi perubahan dapat dijalankan secara paralel untuk memvalidasi arsitektur dan kinerja aplikasi baru.
+ Setelah migrasi data divalidasi, lalu lintas aplikasi dapat dialihkan ke cluster Neptunus dan instance Neo4j dapat dinonaktifkan.
## Pengoptimalan model data untuk migrasi dari Neo4j ke Neptunus
Baik Neptunus dan Neo4j mendukung grafik properti berlabel (LPG). Namun, Neptunus memiliki beberapa perbedaan arsitektur dan model data yang dapat Anda manfaatkan untuk mengoptimalkan kinerja:
### Mengoptimalkan node dan edge IDs
Neo4j secara otomatis menghasilkan panjang numerik. IDs Menggunakan Cypher Anda dapat merujuk ke node dengan ID, tetapi ini umumnya tidak disarankan untuk mencari node oleh properti yang diindeks.
Neptunus memungkinkan Anda [untuk memasok berbasis IDs string Anda sendiri untuk](access-graph-gremlin-differences.md#feature-gremlin-differences-user-supplied-ids) simpul dan tepi. Jika Anda tidak memasok milik Anda sendiri IDs, Neptunus secara otomatis menghasilkan representasi UUIDs string untuk tepi dan simpul baru.
Jika Anda memigrasikan data dari Neo4j ke Neptunus dengan mengekspor dari Neo4j dan kemudian mengimpor massal ke Neptunus, Anda dapat mempertahankan Neo4j's. IDs Nilai numerik yang dihasilkan oleh Neo4j dapat bertindak sebagai disediakan pengguna saat IDs mengimpor ke Neptunus, di mana mereka direpresentasikan sebagai string daripada nilai numerik.
Namun, ada keadaan di mana Anda mungkin ingin mempromosikan properti simpul untuk menjadi ID simpul. Sama seperti mencari node menggunakan properti yang diindeks adalah cara tercepat untuk menemukan simpul di Neo4j, mencari simpul dengan ID adalah cara tercepat untuk menemukan simpul di Neptunus. Oleh karena itu, jika Anda dapat mengidentifikasi properti simpul yang sesuai yang berisi nilai unik, Anda harus mempertimbangkan untuk mengganti simpul \$1id dengan nilai properti yang dinominasikan dalam file CSV pemuatan massal Anda. Jika Anda melakukan ini, Anda juga harus menulis ulang nilai \$1from dan \$1to edge yang sesuai dalam file CSV Anda.
### Batasan skema saat memigrasikan data dari Neo4j ke Neptunus
Di dalam Neptunus, satu-satunya kendala skema yang tersedia adalah keunikan ID simpul atau tepi. Aplikasi yang perlu memanfaatkan kendala keunikan didorong untuk melihat pendekatan ini untuk mencapai kendala keunikan melalui menentukan node atau ID tepi. Jika aplikasi menggunakan beberapa kolom sebagai kendala keunikan, ID dapat diatur ke kombinasi dari nilai-nilai ini. Misalnya, `id=123, code='SEA'` dapat direpresentasikan sebagai`ID='123_SEA'`) untuk mencapai kendala keunikan yang kompleks.
### Optimalisasi arah tepi saat memigrasikan data dari Neo4j ke Neptunus
[Ketika node, tepi, atau properti ditambahkan ke Neptunus, mereka [secara otomatis diindeks dalam tiga cara berbeda, dengan indeks](feature-overview-storage-indexing.md) keempat opsional.](features-lab-mode.md#features-lab-mode-features-osgp-index) Karena bagaimana Neptunus membangun [dan menggunakan indeks, kueri yang](feature-overview-storage-indexing.md) mengikuti tepi keluar lebih efisien daripada yang menggunakan tepi masuk. Dalam hal [model penyimpanan data grafik](feature-overview-data-model.md) Neptunus, ini adalah pencarian berbasis subjek yang menggunakan indeks SPOG.
Jika, dalam memigrasikan model data dan kueri Anda ke Neptunus, Anda menemukan bahwa kueri terpenting Anda bergantung pada melintasi tepi yang masuk di mana ada tingkat penggemar yang tinggi, Anda mungkin ingin mempertimbangkan untuk mengubah model Anda sehingga lintasan ini mengikuti tepi keluar sebagai gantinya, terutama ketika Anda tidak dapat menentukan label tepi mana yang akan dilintasi. Untuk melakukannya, balikkan arah tepi yang relevan dan perbarui label tepi untuk mencerminkan semantik perubahan arah ini. Misalnya, Anda dapat mengubah:
```
person_A — parent_of — person_B
to:
person_B — child_of — person_A
```
Untuk membuat perubahan ini dalam [file CSV tepi beban massal](bulk-load-tutorial-format.md), cukup tukar judul `~from` dan `~to` kolom, dan perbarui nilai kolom. `~label`
Sebagai alternatif untuk membalikkan arah tepi, Anda dapat mengaktifkan indeks [Neptunus keempat, indeks OSGP, yang](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp) membuat melintasi tepi masuk, atau pencarian berbasis objek, jauh lebih efisien. Namun, mengaktifkan indeks keempat ini akan menurunkan tingkat penyisipan dan membutuhkan lebih banyak penyimpanan.
### Optimasi pemfilteran saat memigrasikan data dari Neo4j ke Neptunus
Neptunus dioptimalkan untuk bekerja paling baik ketika properti disaring ke properti paling selektif yang tersedia. Ketika beberapa filter digunakan, kumpulan item yang cocok ditemukan untuk masing-masing dan kemudian tumpang tindih semua set yang cocok dihitung. Jika memungkinkan, menggabungkan beberapa properti ke dalam satu properti meminimalkan jumlah pencarian indeks dan mengurangi latensi kueri.
Misalnya, kueri ini menggunakan dua pencarian indeks dan gabungan:
```
MATCH (n) WHERE n.first_name='John' AND n.last_name='Doe' RETURN n
```
Kueri ini mengambil informasi yang sama menggunakan pencarian indeks tunggal:
```
MATCH (n) WHERE n.name='John Doe' RETURN n
```
###
Neptunus [mendukung tipe data yang berbeda](bulk-load-tutorial-format-opencypher.md#bulk-load-tutorial-format-opencypher-data-types) dari Neo4j.
**Pemetaan tipe data Neo4j ke dalam tipe data yang didukung Neptunus**
+ **Logis**: `Boolean`
Petakan ini di `Bool` Neptunus ke atau. `Boolean`
+ **Numerik**: `Number`
Petakan ini di Neptunus ke yang tersempit dari jenis OpenCypher Neptunus berikut yang dapat mendukung semua nilai properti numerik yang dimaksud:
```
Byte
Short
Integer
Long
Float
Double
```
+ **Teks**: `String`
Petakan ini di `String` Neptunus ke.
+ **Titik waktu**:
```
Date
Time
LocalTime
DateTime
LocalDateTime
```
Petakan ini di `Date` Neptunus sebagai UTC, menggunakan salah satu format ISO-8601 berikut yang didukung Neptunus:
```
yyyy-MM-dd
yyyy-MM-ddTHH:mm
yyyy-MM-ddTHH:mm:ss
yyyy-MM-ddTHH:mm:ssZ
```
+ **Durasi waktu**: `Duration`
Petakan ini di Neptunus ke nilai numerik untuk aritmatika tanggal, jika perlu.
+ **Spasial**: `Point`
Petakan ini di Neptunus ke dalam nilai numerik komponen, yang masing-masing kemudian menjadi properti terpisah, atau ekspresikan sebagai nilai String untuk ditafsirkan oleh aplikasi klien. Perhatikan bahwa integrasi [penelusuran teks lengkap](full-text-search.md) Neptunus OpenSearch memungkinkan Anda mengindeks properti geolokasi.
### Migrasi properti multivaluasi dari Neo4j ke Neptunus
Neo4j memungkinkan [daftar homogen tipe sederhana](https://neo4j.com/docs/cypher-manual/current/values-and-types/) untuk disimpan sebagai properti dari kedua node dan tepi. Daftar ini dapat berisi nilai duplikat.
Neptunus, bagaimanapun, [hanya mengizinkan kardinalitas set atau tunggal](access-graph-gremlin-differences.md#feature-gremlin-differences-vertex-property-cardinality) untuk properti simpul, dan kardinalitas tunggal untuk properti tepi dalam data grafik properti. Akibatnya, tidak ada migrasi langsung properti daftar simpul Neo4j yang berisi nilai duplikat ke properti simpul Neptunus, atau properti daftar hubungan Neo4j ke properti tepi Neptunus.
Beberapa strategi yang mungkin untuk memigrasikan properti node multivaluasi Neo4j dengan nilai duplikat ke Neptunus adalah sebagai berikut:
+ Buang nilai duplikat dan konversikan properti node Neo4j bernilai multivaluasi ke properti simpul Neptunus kardinalitas yang ditetapkan. Perhatikan bahwa himpunan Neptunus mungkin tidak mencerminkan urutan item dalam properti multivaluasi Neo4j asli.
+ Ubah properti node Neo4j multivaluasi menjadi representasi string dari daftar berformat JSON di properti string simpul Neptunus.
+ Ekstrak masing-masing nilai properti multivalued ke dalam simpul terpisah dengan properti nilai, dan hubungkan simpul tersebut ke simpul induk menggunakan tepi berlabel dengan nama properti.
Demikian pula, strategi yang mungkin untuk memigrasikan properti hubungan multivaluasi Neo4j ke Neptunus adalah sebagai berikut:
+ Ubah properti hubungan Neo4j multivaluasi menjadi representasi string dari daftar berformat JSON dan simpan sebagai properti string tepi Neptunus.
+ Memfaktorkan ulang hubungan Neo4j menjadi tepi Neptunus yang masuk dan keluar yang melekat pada simpul perantara. Ekstrak masing-masing nilai properti hubungan multivalued ke dalam simpul terpisah dengan properti nilai dan simpul tersebut ke simpul perantara ini menggunakan tepi berlabel dengan nama properti.
Perhatikan bahwa representasi string dari daftar berformat JSON tidak jelas terhadap bahasa kueri OpenCypher, meskipun OpenCypher menyertakan predikat yang memungkinkan pencarian sederhana di dalam nilai string. `CONTAINS`
## Mengekspor data dari Neo4j saat bermigrasi ke Neptunus
[Saat mengekspor data dari Neo4j, gunakan prosedur APOC untuk mengekspor ke [CSV](https://neo4j.com/labs/apoc/4.1/export/csv/) atau ke GraphMl.](https://neo4j.com/labs/apoc/4.1/export/graphml/) Meskipun dimungkinkan untuk mengekspor ke format lain, ada [alat sumber terbuka](https://github.com/awslabs/amazon-neptune-tools/tree/master/neo4j-to-neptune) untuk mengonversi data CSV yang diekspor dari Neo4j ke format beban massal Neptunus, dan juga [alat sumber](https://github.com/awslabs/amazon-neptune-tools/tree/master/graphml2csv) terbuka untuk mengonversi data GraphMl yang diekspor dari Neo4j ke format beban massal Neptunus.
Anda juga dapat mengekspor data langsung ke Amazon S3 menggunakan berbagai prosedur APOC. Mengekspor ke bucket Amazon S3 dinonaktifkan secara default, tetapi dapat diaktifkan menggunakan prosedur yang disorot [dalam Mengekspor ke Amazon S3 dalam dokumentasi NEO4j APOC](https://neo4j.com/labs/apoc/4.3/export/csv/#export-csv-s3-export).
## Mengimpor data dari Neo4j saat bermigrasi ke Neptunus
[Anda dapat mengimpor data ke Neptunus baik dengan menggunakan pemuat [massal Neptunus](bulk-load.md) atau dengan menggunakan logika aplikasi dalam bahasa kueri yang didukung seperti OpenCypher.](access-graph-opencypher.md)
[Pemuat massal Neptunus adalah pendekatan yang lebih disukai untuk mengimpor data dalam jumlah besar karena memberikan kinerja impor yang dioptimalkan jika Anda mengikuti praktik terbaik.](bulk-load-optimize.md) Pemuat massal mendukung [dua format CSV yang berbeda](bulk-load-tutorial-format.md), di mana data yang diekspor dari Neo4j dapat dikonversi menggunakan utilitas sumber terbuka yang disebutkan di atas di bagian ini. [Mengekspor data](#migration-data-exporting)
Anda juga dapat menggunakan OpenCypher untuk mengimpor data dengan logika khusus untuk mengurai, mengubah, dan mengimpor. [Anda dapat mengirimkan kueri OpenCypher baik melalui [titik akhir HTTPS](access-graph-opencypher-queries.md) (yang direkomendasikan) atau dengan menggunakan driver baut.](access-graph-opencypher-bolt.md)
# Migrasi aplikasi dari Neo4j ke Neptunus
Setelah Anda memigrasikan data Anda dari Neo4j ke Neptunus, langkah selanjutnya adalah memigrasikan aplikasi itu sendiri. Seperti halnya data, ada beberapa pendekatan untuk memigrasikan aplikasi Anda berdasarkan alat yang Anda gunakan, persyaratan, perbedaan arsitektur, dan sebagainya. Hal-hal yang biasanya perlu Anda pertimbangkan dalam proses ini diuraikan di bawah ini.
## Migrasi koneksi saat berpindah dari Neo4j ke Neptunus
Jika saat ini Anda tidak menggunakan driver Bolt, atau ingin menggunakan alternatif, Anda dapat terhubung ke [titik akhir HTTPS](access-graph-opencypher-queries.md) yang menyediakan akses penuh ke data yang dikembalikan.
Jika Anda memiliki aplikasi yang menggunakan [protokol Bolt](access-graph-opencypher-bolt.md), Anda dapat memigrasikan koneksi ini ke Neptunus dan membiarkan aplikasi Anda terhubung menggunakan driver yang sama seperti yang Anda lakukan di Neo4j. Untuk terhubung ke Neptunus, Anda mungkin perlu membuat satu atau beberapa perubahan berikut pada aplikasi Anda:
+ URL dan port perlu diperbarui untuk menggunakan titik akhir cluster dan port cluster (defaultnya adalah 8182).
+ Neptunus membutuhkan semua koneksi untuk menggunakan SSL, jadi Anda perlu menentukan untuk setiap koneksi yang dienkripsi.
+ [Neptunus mengelola otentikasi melalui penetapan kebijakan dan peran IAM.](iam-auth.md) Kebijakan dan peran IAM memberikan tingkat manajemen pengguna yang sangat fleksibel dalam aplikasi, jadi penting untuk membaca dan memahami informasi dalam [ikhtisar IAM](iam-auth.md) sebelum mengonfigurasi cluster Anda.
+ Koneksi baut berperilaku berbeda di Neptunus daripada di Neo4j dalam beberapa cara, seperti yang dijelaskan dalam. [Perilaku koneksi baut di Neptunus](access-graph-opencypher-bolt.md#access-graph-opencypher-bolt-connections)
+ Anda dapat menemukan informasi dan saran lebih lanjut di[Praktik Terbaik Neptunus Menggunakan OpenCypher dan Bolt](best-practices-opencypher.md).
Ada contoh kode untuk bahasa yang umum digunakan seperti Java, Python, .NET, dan NodeJS, dan untuk skenario koneksi seperti menggunakan otentikasi IAM, di. [Menggunakan protokol Bolt untuk membuat kueri OpenCypher ke Neptunus](access-graph-opencypher-bolt.md)
## Merutekan kueri ke instance cluster saat berpindah dari Neo4j ke Neptunus
Aplikasi klien Neo4j menggunakan [driver routing](https://neo4j.com/docs/driver-manual/1.7/client-applications/#routing_drivers_bolt_routing) dan menentukan [mode akses](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-access-mode) untuk merutekan permintaan baca dan tulis ke server yang sesuai dalam cluster kausal.
Saat memigrasikan aplikasi klien ke Neptunus, [gunakan titik akhir Neptunus untuk merutekan kueri](feature-overview-endpoints.md) secara efisien ke instance yang sesuai di cluster Anda:
+ Semua koneksi ke Neptunus harus `bolt://` menggunakan `bolt+routing://` bukan `neo4j://` atau di URL.
+ Titik akhir cluster terhubung ke instance utama saat ini di cluster Anda. Gunakan titik akhir cluster untuk merutekan permintaan penulisan ke primer.
+ Titik akhir pembaca [mendistribusikan koneksi di seluruh instance](best-practices-general-basic.md#best-practices-general-loadbalance) read-replica di cluster Anda. Jika Anda memiliki kluster instans tunggal tanpa instance read-replica, titik akhir pembaca terhubung ke instance utama, yang mendukung operasi penulisan. Jika klaster memang berisi satu atau lebih instance replika baca, mengirim permintaan tulis ke titik akhir pembaca akan menghasilkan pengecualian.
+ Setiap instance di cluster Anda juga dapat memiliki titik akhir instance-nya sendiri. Gunakan titik akhir instance jika aplikasi klien Anda perlu mengirim permintaan ke instance tertentu di cluster.
Untuk informasi selengkapnya, lihat [Pertimbangan titik akhir Neptune](feature-overview-endpoints.md#feature-overview-endpoint-considerations).
## Konsistensi data di Neptunus
[Saat menggunakan cluster kausal Neo4j, replika baca pada akhirnya konsisten dengan server inti, tetapi aplikasi klien dapat memastikan konsistensi kausal dengan menggunakan rantai kausal.](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-causal-chaining) Chaining kausal memerlukan melewati bookmark antar transaksi, yang memungkinkan aplikasi klien untuk menulis ke server inti dan kemudian membaca tulisannya sendiri dari replika baca.
Di Neptunus, contoh replika baca akhirnya konsisten dengan penulis, dengan jeda replika yang biasanya kurang dari 100 milidetik. Namun, sampai perubahan telah direplikasi, pembaruan ke tepi dan simpul yang ada dan penambahan tepi dan simpul baru tidak terlihat pada contoh replika. Oleh karena itu, jika aplikasi Anda membutuhkan konsistensi langsung di Neptunus dengan membaca setiap penulisan, gunakan titik akhir cluster untuk operasi. read-after-write Ini adalah satu-satunya waktu untuk menggunakan titik akhir cluster untuk operasi baca. Dalam semua keadaan lain, gunakan titik akhir pembaca untuk membaca.
## Memigrasi kueri dari Neo4j ke Neptunus
Meskipun [dukungan Neptune untuk OpenCypher](https://aws.amazon.com/blogs/database/announcing-the-general-availability-of-opencypher-support-for-amazon-neptune/) secara dramatis mengurangi jumlah pekerjaan yang diperlukan untuk memigrasikan kueri dari Neo4j, masih ada beberapa perbedaan untuk dinilai saat bermigrasi:
+ Seperti dibahas di [Pengoptimalan model data](migration-data-migration.md#migration-data-model-optimization) atas, mungkin ada modifikasi pada model data Anda yang perlu Anda buat untuk membuat model data grafik yang dioptimalkan untuk Neptunus, yang pada gilirannya akan memerlukan perubahan pada kueri dan pengujian Anda.
+ Neo4j menawarkan berbagai ekstensi bahasa khusus Cypher yang tidak termasuk dalam spesifikasi OpenCypher yang diterapkan oleh Neptunus. Bergantung pada kasus penggunaan dan fitur yang digunakan, mungkin ada solusi dalam bahasa OpenCypher, atau menggunakan bahasa Gremlin, atau melalui mekanisme lain seperti yang dijelaskan dalam. [Menulis ulang kueri Cypher untuk dijalankan di OpenCypher di Neptunus](migration-opencypher-rewrites.md)
+ Aplikasi sering menggunakan komponen middleware lain untuk berinteraksi dengan database, bukan driver Bolt itu sendiri. Silakan periksa [Kompatibilitas Neptunus dengan Neo4j](migration-compatibility.md) untuk melihat apakah alat atau middleware yang Anda gunakan didukung.
+ Dalam kasus failover, driver Bolt mungkin terus terhubung ke instance penulis atau pembaca sebelumnya karena titik akhir cluster yang disediakan untuk koneksi telah diselesaikan ke alamat IP. Penanganan kesalahan yang tepat dalam aplikasi Anda harus menangani ini, seperti yang dijelaskan dalam[Buat koneksi baru setelah failover](best-practices-opencypher.md#best-practices-opencypher-renew-connection).
+ Ketika transaksi dibatalkan karena konflik yang tidak dapat diselesaikan atau batas waktu tunggu kunci-tunggu, Neptunus merespons dengan file. `ConcurrentModificationException` Untuk informasi selengkapnya, lihat [Kode Kesalahan Mesin](errors-engine-codes.md). Sebagai praktik terbaik, klien harus selalu menangkap dan menangani pengecualian ini.
A `ConcurrentModificationException` terjadi kadang-kadang ketika beberapa thread atau beberapa aplikasi menulis ke sistem secara bersamaan. Karena [tingkat isolasi transaksi](transactions-neptune.md#transactions-neptune-mutation), konflik ini terkadang tidak dapat dihindari.
+ Neptunus mendukung menjalankan kueri Gremlin dan OpenCypher pada data yang sama. Ini berarti bahwa dalam beberapa skenario Anda mungkin perlu mempertimbangkan untuk menggunakan Gremlin, dengan kemampuan kueri yang lebih kuat, untuk melakukan beberapa fungsionalitas kueri Anda.
Seperti dibahas di [Penyediaan infrastruktur](migration-provisioning-infrastructure.md) atas, setiap aplikasi harus melalui latihan ukuran yang tepat untuk memastikan bahwa jumlah instance, ukuran instance, dan topologi cluster semuanya dioptimalkan untuk beban kerja spesifik aplikasi.
Pertimbangan yang dibahas di sini untuk memigrasikan aplikasi Anda adalah yang paling umum, tetapi ini bukan daftar lengkap. Setiap aplikasi unik. Silakan hubungi untuk AWS mendukung atau melibatkan tim akun Anda jika Anda memiliki pertanyaan lebih lanjut.
## Migrasi fitur dan alat yang khusus untuk Neo4j
Neo4j memiliki berbagai fitur khusus dan add-on dengan funsionalitas yang dapat diandalkan aplikasi Anda. Saat mengevaluasi kebutuhan untuk memigrasikan fungsi ini, sering kali membantu untuk menyelidiki apakah ada pendekatan yang lebih baik di dalam AWS untuk mencapai tujuan yang sama. [Mempertimbangkan [perbedaan arsitektur antara Neo4j dan Neptunus](migration-architectural-differences.md), Anda sering dapat menemukan alternatif efektif yang memanfaatkan layanan atau integrasi lain. AWS](integrations.md)
Lihat [Kompatibilitas Neptunus dengan Neo4j](migration-compatibility.md) daftar fitur khusus Neo4J dan solusi yang disarankan.
# Kompatibilitas Neptunus dengan Neo4j
Neo4j memiliki pendekatan all-in-one arsitektur, di mana pemuatan data, ETL data, kueri aplikasi, penyimpanan data, dan operasi manajemen semuanya terjadi dalam kumpulan sumber daya komputasi yang sama, seperti instance. EC2 Amazon Neptunus adalah database grafik spesifikasi terbuka yang berfokus pada OLTP di mana arsitektur memisahkan operasi dan memisahkan sumber daya sehingga dapat diskalakan secara dinamis.
Ada berbagai fitur dan perkakas di Neo4j, termasuk perkakas pihak ketiga, yang bukan bagian dari spesifikasi OpenCypher, tidak kompatibel dengan OpenCypher, atau tidak kompatibel dengan implementasi OpenCypher Neptune. Di bawah ini tercantum beberapa yang paling umum dari ini.
## Fitur khusus Neo4J tidak ada di Neptunus
+ **`LOAD CSV`**Neptunus memiliki pendekatan arsitektur yang berbeda untuk memuat data dari Neo4j. [Untuk memungkinkan penskalaan dan pengoptimalan biaya yang lebih baik, Neptunus menerapkan pemisahan kekhawatiran seputar sumber daya, dan merekomendasikan penggunaan salah AWS satu integrasi [layanan](integrations.md)AWS Glue seperti untuk melakukan proses ETL yang diperlukan untuk menyiapkan data dalam [format](bulk-load-tutorial-format.md) yang didukung oleh pemuat massal Neptunus.](bulk-load.md)
Pilihan lain adalah melakukan hal yang sama menggunakan kode aplikasi yang berjalan pada sumber daya AWS komputasi seperti EC2 instans Amazon, fungsi Lambda, Amazon Elastic Container Service, AWS Batch pekerjaan, dan sebagainya. [Kode dapat menggunakan [titik akhir HTTPS Neptunus atau titik akhir Bolt](access-graph-opencypher-queries.md).](access-graph-opencypher-bolt.md)
+ [Kontrol **akses berbutir halus -** Neptunus mendukung kontrol akses granular atas tindakan akses data menggunakan kunci kondisi IAM.](iam-data-access-policies.md) Kontrol akses berbutir halus tambahan dapat diimplementasikan pada lapisan aplikasi.
+ **Neo4j Fabric** - Neptunus mendukung federasi kueri di seluruh database untuk beban kerja RDF menggunakan kata kunci SPARQL. [`SERVICE`](sparql-service.md) Karena saat ini tidak ada standar atau spesifikasi terbuka untuk federasi kueri untuk beban kerja grafik properti, fungsionalitas itu perlu diimplementasikan pada lapisan aplikasi.
+ **Kontrol akses berbasis peran (RBAC) -** [Neptunus mengelola otentikasi melalui penetapan kebijakan dan peran IAM.](iam-auth.md) Kebijakan dan peran IAM memberikan tingkat manajemen pengguna yang sangat fleksibel dalam suatu aplikasi, jadi ada baiknya membaca dan memahami informasi dalam [ikhtisar IAM](iam-auth.md) sebelum mengonfigurasi cluster Anda.
+ **Bookmark** — Cluster Neptunus terdiri dari satu contoh penulis dan hingga 15 contoh replika baca. Data yang ditulis ke contoh penulis sesuai dengan ACID dan memberikan jaminan konsistensi yang kuat pada pembacaan berikutnya. Replicas baca menggunakan volume penyimpanan yang sama dengan instance penulis dan pada akhirnya konsisten, biasanya dalam waktu kurang dari 100 ms dari waktu data ditulis. Jika kasus penggunaan Anda memiliki kebutuhan mendesak untuk menjamin konsistensi baca penulisan baru, pembacaan ini harus diarahkan ke titik akhir cluster alih-alih titik akhir pembaca.
+ Prosedur **APOC — Karena prosedur** APOC tidak termasuk dalam spesifikasi OpenCypher, Neptunus tidak memberikan dukungan langsung untuk prosedur eksternal. Sebaliknya, Neptunus [mengandalkan integrasi dengan layanan AWS lain untuk mencapai fungsionalitas pengguna akhir yang serupa dengan](integrations.md) cara yang terukur, aman, dan kuat. Terkadang prosedur APOC dapat ditulis ulang dalam OpenCypher atau Gremlin, dan beberapa tidak relevan dengan aplikasi Neptunus.
Secara umum, prosedur APOC termasuk dalam kategori di bawah ini:
+ **[Impor](https://neo4j.com/labs/apoc/4.2/import/)** — Neptunus mendukung pengimporan data menggunakan berbagai format menggunakan bahasa kueri, pemuat massal [Neptunus](bulk-load.md), atau sebagai target. [AWS Database Migration Service](dms-neptune.md) Operasi ETL pada data dapat dilakukan dengan menggunakan AWS Glue dan paket [https://github.com/awslabs/amazon-neptune-tools/tree/master/neptune-python-utils](https://github.com/awslabs/amazon-neptune-tools/tree/master/neptune-python-utils)open-source.
+ **[Ekspor](https://neo4j.com/labs/apoc/4.2/export/)** - Neptunus mendukung ekspor data menggunakan [`neptune-export`](neptune-data-export.md)utilitas, yang mendukung berbagai format dan metode ekspor umum.
+ **[Integrasi Database](https://neo4j.com/labs/apoc/4.2/database-integration/)** — Neptunus mendukung integrasi dengan database lain menggunakan alat ETL seperti atau alat migrasi AWS Glue seperti. [AWS Database Migration Service](dms-neptune.md)
+ **[Pembaruan Grafik](https://neo4j.com/labs/apoc/4.2/graph-updates/)** - Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **[Struktur Data](https://neo4j.com/labs/apoc/4.2/data-structures/)** — Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **[Temporal (Date Time)](https://neo4j.com/labs/apoc/4.2/temporal/)** - Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **[Matematika](https://neo4j.com/labs/apoc/4.2/mathematical/)** — Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **[Advanced Graph Querying](https://neo4j.com/labs/apoc/4.2/graph-querying/)** — Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **[Membandingkan Grafik](https://neo4j.com/labs/apoc/4.2/comparing-graphs/)** — Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **[Eksekusi Cypher](https://neo4j.com/labs/apoc/4.2/cypher-execution/)** — Neptunus mendukung serangkaian fitur yang kaya untuk memperbarui data grafik properti melalui dukungannya untuk bahasa kueri OpenCypher dan Gremlin. Lihat [Cypher menulis ulang](migration-opencypher-rewrites.md) contoh penulisan ulang prosedur yang umum digunakan.
+ **Prosedur khusus** - Neptunus tidak mendukung prosedur khusus yang dibuat oleh pengguna. Fungsionalitas ini harus diimplementasikan pada lapisan aplikasi.
+ **Geospasial** — Meskipun Neptunus tidak memberikan dukungan asli untuk fitur geospasial, fungsionalitas serupa dapat dicapai melalui integrasi dengan layanan AWS lain, seperti yang ditunjukkan dalam posting blog ini: Gabungkan Amazon [Neptunus dan OpenSearch Amazon Service untuk kueri geospasial oleh Ross Gabay dan Abhilash Vinod](https://aws.amazon.com/blogs/database/combine-amazon-neptune-and-amazon-opensearch-service-for-geospatial-queries/) (1 Februari 2022).
+ **Ilmu Data Grafik** — Neptunus mendukung analisis grafik hari ini melalui Neptunus Analytics, [mesin](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html) yang dioptimalkan untuk memori yang mendukung perpustakaan algoritme analitik grafik.
Neptunus juga menyediakan integrasi dengan AWS SDK [Pandas](https://github.com/amazon-archives/fully-automated-neo4j-to-neptune) dan [beberapa contoh](https://github.com/aws/graph-notebook/tree/main/src/graph_notebook/notebooks/05-Data-Science) notebook yang menunjukkan bagaimana memanfaatkan integrasi ini dalam lingkungan Python untuk menjalankan analitik pada data grafik.
+ **Batasan Skema — Dalam Neptunus, satu-satunya kendala** skema yang tersedia adalah keunikan ID node atau tepi. Tidak ada fitur untuk menentukan batasan skema tambahan, atau keunikan tambahan atau batasan nilai pada elemen dalam grafik. Nilai ID di Neptunus adalah string dan dapat diatur menggunakan Gremlin, seperti ini:
```
g.addV('person').property(id, '1') )
```
Aplikasi yang perlu memanfaatkan ID sebagai kendala keunikan didorong untuk mencoba pendekatan ini untuk mencapai kendala keunikan. Jika aplikasi menggunakan beberapa kolom sebagai kendala keunikan, ID dapat diatur ke kombinasi dari nilai-nilai ini. Misalnya `id=123, code='SEA'` dapat direpresentasikan `ID='123_SEA'` untuk mencapai kendala keunikan yang kompleks.
+ **Multi-tenancy** — Neptunus hanya mendukung satu grafik per cluster. Untuk membangun sistem multi-tenant menggunakan Neptunus, gunakan beberapa cluster atau partisi penyewa secara logis dalam satu grafik dan gunakan logika sisi aplikasi untuk menegakkan pemisahan. Misalnya, tambahkan properti `tenantId` dan sertakan di setiap kueri, seperti ini:
```
MATCH p=(n {tenantId:1})-[]->({tenantId:1}) RETURN p LIMIT 5)
```
[Neptunus](neptune-serverless.md) Tanpa Server membuatnya relatif mudah untuk menerapkan multi-tenancy menggunakan beberapa cluster DB, yang masing-masing diskalakan secara independen dan otomatis sesuai kebutuhan.
## Dukungan Neptunus untuk alat Neo4j
Neptunus menyediakan alternatif berikut untuk alat Neo4j:
+ **[Neo4j Browser](https://neo4j.com/docs/operations-manual/current/installation/neo4j-browser/)** — Neptunus menyediakan [notebook grafik](graph-notebooks.md) open-source yang menyediakan IDE yang berfokus pada pengembang untuk menjalankan kueri dan memvisualisasikan hasilnya.
+ **[Neo4j Bloom](https://neo4j.com/product/bloom/)** — Neptunus mendukung visualisasi grafik kaya menggunakan [solusi visualisasi pihak ketiga seperti Graph-explorer, Tom Sawyer, Cambridge](visualization-tools.md) Intelligence, Graphistry, metaphacts, dan G.V ().
+ **[GraphQL](https://graphql.org/)** — Neptunus saat ini mendukung GraphQL melalui integrasi kustom. AWS AppSync Lihat [aplikasi Membangun grafik dengan posting blog Amazon Neptunus AWS dan Amplify, dan](https://aws.amazon.com/blogs/database/build-a-graph-application-with-amazon-neptune-and-aws-amplify/) contoh [proyek, Membangun aplikasi pelacak Kalori Tanpa Server](https://github.com/aws-samples/aws-appsync-calorie-tracker-workshop) dengan dan Amazon Neptunus. AWS AppSync
+ **[NeoSemantics](https://neo4j.com/labs/neosemantics/4.0/)**— Neptunus secara native mendukung model data RDF, sehingga pelanggan yang ingin menjalankan beban kerja RDF disarankan untuk menggunakan dukungan model RDF Neptunus.
+ **[Arrows.app](https://arrows.app/)** — Cypher yang dibuat saat mengekspor model menggunakan perintah ekspor kompatibel dengan Neptunus.
+ **[Linkurious Ogma](https://doc.linkurious.com/ogma/latest/)** [- Integrasi sampel dengan Linkurious Ogma tersedia di sini.](https://github.com/aws-samples/amazon-neptune-samples/tree/master/gremlin/ogma-neptune)
+ **[Data Musim Semi Neo4j](https://spring.io/projects/spring-data-neo4j)** — Ini saat ini tidak kompatibel dengan Neptunus.
+ **[Neo4j Spark Connector - Konektor](https://neo4j.com/docs/spark/current/)** percikan Neo4j dapat digunakan dalam Spark Job untuk terhubung ke Neptunus menggunakan OpenCypher. Berikut adalah beberapa contoh kode dan konfigurasi aplikasi:
**Contoh kode:**
```
SparkSession spark = SparkSession
.builder()
.config("encryption.enabled", "true")
.appName("Simple Application").config("spark.master", "local").getOrCreate();
Dataset df = spark.read().format("org.neo4j.spark.DataSource")
.option("url", "bolt://(your cluster endpoint):8182")
.option("encryption.enabled", "true")
.option("query", "MATCH (n:airport) RETURN n")
.load();
System.out.println("TOTAL RECORD COUNT: " + df.count());
spark.stop();
```
**Konfigurasi aplikasi:**
```
org.neo4j
neo4j-connector-apache-spark_2.12-4.1.0
4.0.1_for_spark_3
```
### Fitur dan alat Neo4j tidak tercantum di sini
Jika Anda menggunakan alat atau fitur yang tidak tercantum di sini, kami tidak yakin kompatibilitasnya dengan Neptunus atau layanan lain di dalamnya. AWS Silakan hubungi untuk AWS mendukung atau melibatkan tim akun Anda jika Anda memiliki pertanyaan lebih lanjut.
# Menulis ulang kueri Cypher untuk dijalankan di OpenCypher di Neptunus
[Bahasa OpenCypher adalah bahasa query deklaratif untuk grafik properti yang awalnya dikembangkan oleh Neo4j, kemudian open-source pada tahun 2015, dan berkontribusi pada proyek OpenCypher di bawah lisensi open-source Apache 2.](https://www.opencypher.org/) Di AWS, kami percaya bahwa open source baik untuk semua orang dan kami berkomitmen untuk membawa nilai open source kepada pelanggan kami, dan keunggulan operasional AWS untuk komunitas open source.
OpenCypher sintaks didokumentasikan dalam [Referensi Bahasa Kueri Cypher, Versi 9](https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf).
Karena OpenCypher berisi subset sintaks dan fitur bahasa kueri Cypher, beberapa skenario migrasi memerlukan penulisan ulang kueri dalam formulir yang sesuai dengan OpenCypher atau memeriksa metode alternatif untuk mencapai fungsionalitas yang diinginkan.
Bagian ini berisi rekomendasi untuk menangani perbedaan umum, tetapi sama sekali tidak lengkap. Anda harus menguji aplikasi apa pun menggunakan penulisan ulang ini secara menyeluruh untuk memastikan bahwa hasilnya sesuai dengan yang Anda harapkan.
## Menulis ulang`None`,`All`, dan fungsi `Any` predikat
Fungsi-fungsi ini bukan bagian dari spesifikasi OpenCypher. Hasil yang sebanding dapat dicapai di OpenCypher menggunakan List Comprehension.
Misalnya, temukan semua jalur yang berpindah dari node `Start` ke node`End`, tetapi tidak ada perjalanan yang diizinkan melewati node dengan properti kelas`D`:
```
# Neo4J Cypher code
match p=(a:Start)-[:HOP*1..]->(z:End)
where none(node IN nodes(p) where node.class ='D')
return p
# Neptune openCypher code
match p=(a:Start)-[:HOP*1..]->(z:End)
where size([node IN nodes(p) where node.class = 'D']) = 0
return p
```
Pemahaman daftar dapat mencapai hasil ini sebagai berikut:
```
all => size(list_comprehension(list)) = size(list)
any => size(list_comprehension(list)) >= 1
none => size(list_comprehension(list)) = 0
```
## Menulis ulang fungsi Cypher di OpenCypher `reduce()`
`reduce()`Fungsi ini bukan bagian dari spesifikasi OpenCypher. Hal ini sering digunakan untuk membuat agregasi data dari elemen dalam daftar. Dalam banyak kasus, Anda dapat menggunakan kombinasi Pemahaman Daftar dan `UNWIND` klausa untuk mencapai hasil yang serupa.
Misalnya, kueri Cypher berikut menemukan semua bandara di jalur yang memiliki satu hingga tiga pemberhentian antara Anchorage (ANC) dan Austin (AUS), dan mengembalikan jarak total setiap jalur:
```
MATCH p=(a:airport {code: 'ANC'})-[r:route*1..3]->(z:airport {code: 'AUS'})
RETURN p, reduce(totalDist=0, r in relationships(p) | totalDist + r.dist) AS totalDist
ORDER BY totalDist LIMIT 5
```
Anda dapat menulis kueri yang sama di OpenCypher untuk Neptunus sebagai berikut:
```
MATCH p=(a:airport {code: 'ANC'})-[r:route*1..3]->(z:airport {code: 'AUS'})
UNWIND [i in relationships(p) | i.dist] AS di
RETURN p, sum(di) AS totalDist
ORDER BY totalDist
LIMIT 5
```
## Menulis ulang klausa Cypher FOREACH di OpenCypher
Klausa FOREACH bukan bagian dari spesifikasi OpenCypher. Hal ini sering digunakan untuk memperbarui data di tengah-tengah query, sering dari agregasi atau elemen dalam jalur.
Sebagai contoh jalur, temukan semua bandara di jalur dengan tidak lebih dari dua pemberhentian antara Anchorage (ANC) dan Austin (AUS) dan tetapkan properti yang dikunjungi di masing-masing bandara:
```
# Neo4J Example
MATCH p=(:airport {code: 'ANC'})-[*1..2]->({code: 'AUS'})
FOREACH (n IN nodes(p) | SET n.visited = true)
# Neptune openCypher
MATCH p=(:airport {code: 'ANC'})-[*1..2]->({code: 'AUS'})
WITH nodes(p) as airports
UNWIND airports as a
SET a.visited=true
```
Contoh lain adalah:
```
# Neo4J Example
MATCH p=(start)-[*]->(finish)
WHERE start.name = 'A' AND finish.name = 'D'
FOREACH (n IN nodes(p) | SET n.marked = true)
# Neptune openCypher
MATCH p=(start)-[*]->(finish)
WHERE start.name = 'A' AND finish.name = 'D'
UNWIND nodes(p) AS n
SET n.marked = true
```
## Menulis ulang prosedur APOC Neo4j di Neptunus
[Contoh di bawah ini menggunakan OpenCypher untuk menggantikan beberapa prosedur APOC yang paling umum digunakan.](https://neo4j.com/blog/intro-user-defined-procedures-apoc/) Contoh-contoh ini hanya untuk referensi, dan dimaksudkan untuk memberikan beberapa saran tentang cara menangani skenario umum. Dalam praktiknya, setiap aplikasi berbeda, dan Anda harus membuat strategi Anda sendiri untuk menyediakan semua fungsionalitas yang Anda butuhkan.
### Prosedur penulisan ulang `apoc.export`
[Neptunus menyediakan berbagai opsi untuk grafik penuh dan ekspor berbasis kueri dalam berbagai format output seperti CSV dan JSON, menggunakan utilitas ekspor neptunus (lihat).](https://github.com/aws/neptune-export) [Mengekspor data dari cluster DB Neptunus](neptune-data-export.md)
### Prosedur penulisan ulang `apoc.schema`
Neptunus tidak memiliki skema, indeks, atau kendala yang didefinisikan secara eksplisit, sehingga banyak prosedur tidak lagi diperlukan. `apoc.schema` Contohnya adalah:
+ `apoc.schema.assert`
+ `apoc.schema.node.constraintExists`
+ `apoc.schema.node.indexExists`,
+ `apoc.schema.relationship.constraintExists`
+ `apoc.schema.relationship.indexExists`
+ `apoc.schema.nodes`
+ `apoc.schema.relationships`
Neptunus OpenCypher memang mendukung pengambilan nilai yang serupa dengan yang dilakukan prosedur, seperti yang ditunjukkan di bawah ini, tetapi dapat mengalami masalah kinerja pada grafik yang lebih besar karena hal itu memerlukan pemindaian sebagian besar grafik untuk mengembalikan jawabannya.
```
# openCypher replacement for apoc.schema.properties.distinct
MATCH (n:airport)
RETURN DISTINCT n.runways
```
```
# openCypher replacement for apoc.schema.properties.distinctCount
MATCH (n:airport)
RETURN DISTINCT n.runways, count(n.runways)
```
### Alternatif untuk `apoc.do` prosedur
Prosedur ini digunakan untuk menyediakan eksekusi kueri bersyarat yang mudah diimplementasikan menggunakan klausa OpenCypher lainnya. Di Neptunus setidaknya ada dua cara untuk mencapai perilaku serupa:
+ Salah satu caranya adalah dengan menggabungkan kemampuan Pemahaman Daftar OpenCypher dengan klausa. `UNWIND`
+ Cara lain adalah dengan menggunakan langkah choose () dan coalesce () di Gremlin.
Contoh pendekatan ini ditunjukkan di bawah ini.
#### Alternatif untuk apoc.do.when
```
# Neo4J Example
MATCH (n:airport {region: 'US-AK'})
CALL apoc.do.when(
n.runways>=3,
'SET n.is_large_airport=true RETURN n',
'SET n.is_large_airport=false RETURN n',
{n:n}
) YIELD value
WITH collect(value.n) as airports
RETURN size([a in airports where a.is_large_airport]) as large_airport_count,
size([a in airports where NOT a.is_large_airport]) as small_airport_count
# Neptune openCypher
MATCH (n:airport {region: 'US-AK'})
WITH n.region as region, collect(n) as airports
WITH [a IN airports where a.runways >= 3] as large_airports,
[a IN airports where a.runways < 3] as small_airports, airports
UNWIND large_airports as la
SET la.is_large_airport=true
WITH DISTINCT small_airports, airports
UNWIND small_airports as la
SET la.small_airports=true
WITH DISTINCT airports
RETURN size([a in airports where a.is_large_airport]) as large_airport_count,
size([a in airports where NOT a.is_large_airport]) as small_airport_count
#Neptune Gremlin using choose()
g.V().
has('airport', 'region', 'US-AK').
choose(
values('runways').is(lt(3)),
property(single, 'is_large_airport', false),
property(single, 'is_large_airport', true)).
fold().
project('large_airport_count', 'small_airport_count').
by(unfold().has('is_large_airport', true).count()).
by(unfold().has('is_large_airport', false).count())
#Neptune Gremlin using coalesce()
g.V().
has('airport', 'region', 'US-AK').
coalesce(
where(values('runways').is(lt(3))).
property(single, 'is_large_airport', false),
property(single, 'is_large_airport', true)).
fold().
project('large_airport_count', 'small_airport_count').
by(unfold().has('is_large_airport', true).count()).
by(unfold().has('is_large_airport', false).count())
```
#### Alternatif untuk apoc.do.case
```
# Neo4J Example
MATCH (n:airport {region: 'US-AK'})
CALL apoc.case([
n.runways=1, 'RETURN "Has one runway" as b',
n.runways=2, 'RETURN "Has two runways" as b'
],
'RETURN "Has more than 2 runways" as b'
) YIELD value
RETURN {type: value.b,airport: n}
# Neptune openCypher
MATCH (n:airport {region: 'US-AK'})
WITH n.region as region, collect(n) as airports
WITH [a IN airports where a.runways =1] as single_runway,
[a IN airports where a.runways =2] as double_runway,
[a IN airports where a.runways >2] as many_runway
UNWIND single_runway as sr
WITH {type: "Has one runway",airport: sr} as res, double_runway, many_runway
WITH DISTINCT double_runway as double_runway, collect(res) as res, many_runway
UNWIND double_runway as dr
WITH {type: "Has two runways",airport: dr} as two_runways, res, many_runway
WITH collect(two_runways)+res as res, many_runway
UNWIND many_runway as mr
WITH {type: "Has more than 2 runways",airport: mr} as res2, res, many_runway
WITH collect(res2)+res as res
UNWIND res as r
RETURN r
#Neptune Gremlin using choose()
g.V().
has('airport', 'region', 'US-AK').
project('type', 'airport').
by(
choose(values('runways')).
option(1, constant("Has one runway")).
option(2, constant("Has two runways")).
option(none, constant("Has more than 2 runways"))).
by(elementMap())
#Neptune Gremlin using coalesce()
g.V().
has('airport', 'region', 'US-AK').
project('type', 'airport').
by(
coalesce(
has('runways', 1).constant("Has one runway"),
has('runways', 2).constant("Has two runways"),
constant("Has more than 2 runways"))).
by(elementMap())
```
## Alternatif untuk properti berbasis daftar
Neptunus saat ini tidak mendukung penyimpanan properti berbasis Daftar. Namun, hasil serupa dapat diperoleh dengan menyimpan nilai daftar sebagai string yang dipisahkan koma dan kemudian menggunakan `split()` fungsi `join()` and untuk membangun dan mendekonstruksi properti list.
Misalnya, jika kita ingin menyimpan daftar tag sebagai properti, kita dapat menggunakan contoh penulisan ulang yang menunjukkan cara mengambil properti yang dipisahkan koma dan kemudian menggunakan `join()` fungsi `split()` dan dengan Pemahaman Daftar untuk mencapai hasil yang sebanding:
```
# Neo4j Example (In this example, tags is a durable list of string.
MATCH (person:person {name: "TeeMan"})
WITH person, [tag in person.tags WHERE NOT (tag IN ['test1', 'test2', 'test3'])] AS newTags
SET person.tags = newTags
RETURN person
# Neptune openCypher
MATCH (person:person {name: "TeeMan"})
WITH person, [tag in split(person.tags, ',') WHERE NOT (tag IN ['test1', 'test2', 'test3'])] AS newTags
SET person.tags = join(newTags,',')
RETURN person
```
## Menulis ulang subkueri CALL
Subquery `CALL` Neptunus tidak mendukung `CALL (friend) { ... }` sintaks untuk mengimpor variabel ke dalam lingkup subquery (, dalam contoh ini). `friend` Silakan gunakan `WITH` klausa di dalam subquery untuk hal yang sama, misalnya,. `CALL { WITH friend ... }`
`CALL`Subquery opsional tidak didukung saat ini.
## Perbedaan lain antara Neptunus OpenCypher dan Cypher
+ Neptunus hanya mendukung koneksi TCP untuk protokol Bolt. WebSocketskoneksi untuk Bolt tidak didukung.
+ Neptune OpenCypher menghapus spasi seperti yang didefinisikan oleh Unicode di, dan fungsi. `trim()` `ltrim()` `rtrim()`
+ Di Neptunus OpenCypher`tostring(`, `)` ganda tidak secara otomatis beralih ke notasi E untuk nilai ganda yang besar.
# Sumber daya untuk bermigrasi dari Neo4j ke Neptunus
Neptunus menyediakan beberapa alat dan sumber daya yang dapat membantu dalam proses migrasi.
**Alat untuk membantu bermigrasi dari Neo4j ke Neptunus**
+ OpenCypher [CheatSheet](https://github.com/aws-samples/amazon-neptune-samples/blob/master/opencypher/Cheatsheet.md).
+ [neo4 j-to-neptune](https://github.com/awslabs/amazon-neptune-tools/tree/master/neo4j-to-neptune) — Utilitas baris perintah untuk memigrasikan data dari Neo4j ke Neptunus. Alat ini mencakup kemampuan untuk:
+ Ekspor data dari grafik Neo4j yang dikonfigurasi dengan benar.
+ Ubah data itu menjadi format Neptunus.
+ Massal memuat data itu ke Neptunus.
+ Lakukan beberapa konversi dasar data selama konversi ke format Neptunus, seperti mengganti nama label simpul atau tepi dan menghasilkan elemen.
+ Hasilkan properti untuk node dan tepi menggunakan templat (misalnya, buat `~id` nilai menggunakan templat seperti `Person_{personid}` untuk situasi di mana Anda perlu membuat pengidentifikasi unik untuk elemen).
+ [OpenCypher Query Compatibility Checker](https://github.com/awslabs/amazon-neptune-tools/tree/master/opencypher-compatability-checker) — Alat ini mengambil masukan dari query OpenCypher dan akan:
+ Periksa kompatibilitas dengan versi Neptunus yang dipilih.
+ Identifikasi fungsi dan klausa tertentu yang tidak didukung dengan posisinya.
+ Sarankan penggantian jika tersedia.
+ Berikan deskripsi kesalahan dari kesalahan sintaks lainnya.