Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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
Menilai migrasi data dari Neo4j ke Neptunus
Langkah pertama saat menilai migrasi data apa pun adalah menentukan bagaimana Anda akan memigrasikan data. Opsi tergantung 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
sumber ke cluster Kafka. Setelah ini selesai, ekspor sistem yang sedang berjalan dapat diambil, mengikuti instruksiMengekspor data dari Neo4j saat bermigrasi ke Neptunus, 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
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
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 ID node dan edge
Neo4j secara otomatis menghasilkan ID panjang numerik. 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 menyediakan ID berbasis string Anda sendiri untuk simpul dan tepi. Jika Anda tidak menyediakan ID Anda sendiri, Neptunus secara otomatis menghasilkan representasi string UUID 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 ID Neo4j. Nilai numerik yang dihasilkan oleh Neo4j dapat bertindak sebagai ID yang disediakan pengguna saat 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 ~id dengan nilai properti yang dinominasikan dalam file CSV pemuatan massal Anda. Jika Anda melakukan ini, Anda juga harus menulis ulang nilai ~from dan ~to 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 sebagaiID='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 keempat opsional. Karena bagaimana Neptunus membangun dan menggunakan indeks, kueri yang mengikuti tepi keluar lebih efisien daripada yang menggunakan tepi masuk. Dalam hal model penyimpanan data grafik 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, 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 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 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 Neptunus OpenSearch memungkinkan Anda mengindeks properti geolokasi.
Migrasi properti multivaluasi dari Neo4j ke Neptunus
Neo4j memungkinkan daftar homogen tipe sederhana
Neptunus, bagaimanapun, hanya mengizinkan kardinalitas set atau tunggal 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 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
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
Mengimpor data dari Neo4j saat bermigrasi ke Neptunus
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. Pemuat massal mendukung dua format CSV yang berbeda, di mana data yang diekspor dari Neo4j dapat dikonversi menggunakan utilitas sumber terbuka yang disebutkan di atas di bagian ini. Mengekspor data
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 (yang direkomendasikan) atau dengan menggunakan driver baut.