Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Bagaimana kueri Gremlin diproses di Neptune
Di Amazon Neptune, traversal yang lebih kompleks dapat diwakili oleh serangkaian pola yang menciptakan relasi berdasarkan definisi variabel bernama yang dapat dibagi di seluruh pola untuk membuat gabungan. Seperti yang ditunjukkan dalam contoh berikut.
Pertanyaan: Apa lingkungan dua hop dari vertex? v1
Gremlin code: g.V(‘v1’).out('knows').out('knows').path() Pattern: (?1=<v1>, <knows>, ?2, ?) X Pattern(?2, <knows>, ?3, ?) The pattern produces a three-column relation (?1, ?2, ?3) like this: ?1 ?2 ?3 ================ v1 v2 v3 v1 v2 v4 v1 v5 v6
Dengan berbagi variabel ?2 di dua pola (pada posisi O dalam pola pertama dan posisi S dari pola kedua), Anda membuat gabungan dari tetangga hop pertama ke tetangga hop kedua. Setiap solusi Neptunus memiliki binding untuk tiga variabel bernama, yang dapat digunakan untuk membuat ulang TinkerPop Traverser (termasuk informasi jalur).
Langkah pertama dalam pemrosesan kueri Gremlin adalah mengurai kueri menjadi objek TinkerPop Traversal.V() diwakili dan dieksekusi oleh TinkerPop GraphStep
Karena off-the-shelf TinkerPop langkah-langkah ini dapat dieksekusi, TinkerPop Traversal semacam itu dapat mengeksekusi kueri Gremlin apa pun dan menghasilkan jawaban yang benar. Namun, ketika dieksekusi terhadap grafik besar, TinkerPop langkah-langkah terkadang bisa sangat tidak efisien dan lambat. Alih-alih menggunakannya, Neptune mencoba mengubah traversal menjadi bentuk deklaratif yang terdiri dari grup pola, seperti yang dijelaskan sebelumnya.
Neptune saat ini tidak mendukung semua operator (langkah) Gremlin di mesin kueri aslinya. Jadi Neptune mencoba melakukan collaps pada sebanyak mungkin langkah ke dalam satu NeptuneGraphQueryStep, yang berisi rencana kueri logis deklaratif untuk semua langkah-langkah yang telah dikonversi. Idealnya, semua langkah dikonversi. Tetapi ketika sebuah langkah ditemukan yang tidak dapat dikonversi, Neptunus keluar dari eksekusi asli dan menunda semua eksekusi kueri dari titik itu ke langkah-langkahnya. TinkerPop Neptune tidak mencoba untuk menjalin masuk dan keluar dari eksekusi asli.
Setelah langkah-langkah diterjemahkan ke dalam rencana kueri logis, Neptune menjalankan serangkaian pengoptimal kueri yang menulis ulang rencana kueri berdasarkan analisis statis dan perkiraan kardinalitas. Pengoptimal ini melakukan hal-hal seperti mengatur ulang operator berdasarkan jumlah rentang, memangkas operator yang tidak perlu atau berlebihan, mengatur ulang filter, mendorong operator ke dalam kelompok yang berbeda, dan sebagainya.
Setelah rencana kueri yang dioptimalkan diproduksi, Neptune menciptakan alur operator fisik yang melakukan pekerjaan mengeksekusi kueri. Ini termasuk membaca data dari indeks pernyataan, melakukan penggabungan berbagai jenis, penyaringan, pengurutan, dan sebagainya. Pipeline menghasilkan aliran solusi yang kemudian diubah kembali menjadi aliran objek TinkerPop Traverser.
Serialisasi hasil kueri
Amazon Neptunus saat ini mengandalkan TinkerPop serializer pesan respons untuk mengonversi hasil kueri TinkerPop (Traversers) menjadi data serial untuk dikirim melalui kabel kembali ke klien. Format serialisasi ini cenderung cukup verbose.
Sebagai contoh, untuk melakukan serialisasi hasil dari kueri vertex seperti g.V().limit(1), mesin kueri Neptune harus melakukan pencarian tunggal untuk memproduksi hasil kueri. Namun, serializer GraphSON akan melakukan sejumlah besar pencarian tambahan untuk mengemas vertex ke dalam format serialisasi. Serializer harus melakukan satu pencarian untuk mendapatkan label, satu pencarian untuk mendapatkan kunci properti, dan satu pencarian per kunci properti untuk vertex untuk mendapatkan semua nilai untuk setiap kunci.
Beberapa format serialisasi lebih efisien, tetapi semua memerlukan pencarian tambahan. Selain itu, TinkerPop serializer tidak mencoba menghindari penelusuran duplikat, seringkali mengakibatkan banyak pencarian diulang secara tidak perlu.
Hal ini membuat sangat penting untuk menulis kueri Anda sehingga mereka meminta secara khusus hanya untuk informasi yang mereka butuhkan. Misalnya, g.V().limit(1).id() akan mengembalikan hanya ID vertex dan menghilangkan semua pencarian serializer tambahan. Gremlin profile API di Neptunus memungkinkan Anda untuk melihat berapa banyak panggilan pencarian yang dilakukan selama eksekusi kueri dan selama serialisasi.
