Cache pencarian Neptune dapat mempercepat kueri baca

Amazon Neptune mengimplementasikan cache pencarian yang menggunakan R5d SSD berbasis instans NVMe untuk meningkatkan kinerja baca kueri dengan pencarian nilai properti atau literal yang sering dan berulang. RDF Cache pencarian untuk sementara menyimpan nilai-nilai ini dalam NVMe SSD volume di mana mereka dapat diakses dengan cepat.

Fitur ini tersedia dimulai dengan Versi Mesin Amazon Neptune 1.0.4.2.R2 (2021-06-01).

Kueri baca yang mengembalikan properti sejumlah besar simpul dan tepi, atau banyak RDF tiga kali lipat, dapat memiliki latensi tinggi jika nilai properti atau literal perlu diambil dari volume penyimpanan cluster daripada memori. Contohnya termasuk kueri baca berjalan lama yang mengembalikan sejumlah besar nama lengkap dari grafik identitas, atau alamat IP dari grafik deteksi penipuan. Karena jumlah nilai properti atau RDF literal yang dikembalikan oleh kueri Anda meningkat, memori yang tersedia berkurang dan eksekusi kueri Anda dapat menurun secara signifikan.

Kasus penggunaan untuk cache pencarian Neptunus

Cache pencarian hanya membantu ketika kueri baca Anda mengembalikan properti dari sejumlah besar simpul dan tepi, atau tiga kali lipat. RDF

Untuk mengoptimalkan kinerja kueri, Amazon Neptunus menggunakan R5d jenis instans untuk membuat cache besar untuk nilai properti atau literal tersebut. Mengambilnya dari cache kemudian jauh lebih cepat daripada mengambilnya dari volume penyimpanan cluster.

Sebagai aturan praktis, hanya bermanfaat untuk mengaktifkan cache pencarian jika ketiga kondisi berikut terpenuhi:

• Anda telah mengamati peningkatan latensi dalam kueri baca.

• Anda juga mengamati penurunan BufferCacheHitRatio CloudWatch metrik saat menjalankan kueri baca (lihatMemantau Neptunus Menggunakan Amazon CloudWatch).

• Kueri baca Anda menghabiskan banyak waktu dalam mematerialisasi nilai kembali sebelum me-render hasilnya (lihat contoh profil Gremlin di bawah ini untuk cara untuk menentukan berapa banyak nilai properti yang sedang dimaterialisasi untuk kueri).

catatan

Fitur ini hanya membantu dalam skenario spesifik yang dijelaskan di atas. Misalnya, cache pencarian tidak membantu kueri agregasi sama sekali. Kecuali Anda menjalankan kueri yang akan mendapat manfaat dari cache pencarian, tidak ada alasan untuk menggunakan tipe R5d instance alih-alih jenis instance yang setara dan lebih murahR5.

Jika Anda menggunakan Gremlin, Anda dapat menilai biaya materialisasi kueri dengan Gremlin profile API. Di bawah “Operasi Indeks', ia menunjukkan jumlah istilah yang termaterialisasi selama eksekusi:

Index Operations
Query execution:
    # of statement index ops: 3
    # of unique statement index ops: 3
    Duplication ratio: 1.0
    # of terms materialized: 5273
Serialization:
    # of statement index ops: 200
    # of unique statement index ops: 140
    Duplication ratio: 1.43
    # of terms materialized: 32693

Jumlah istilah non-numerik yang termaterialisasi berbanding lurus dengan jumlah istilah pencarian yang harus dilakukan Neptune.

Menggunakan cache pencarian

Cache pencarian hanya tersedia pada jenis R5d instance, di mana cache ini diaktifkan secara otomatis secara default. Instans R5d Neptunus memiliki spesifikasi R5 yang sama dengan instans, ditambah hingga 1,8 TB penyimpanan berbasis lokal. NVMe SSD Cache pencarian adalah khusus instans, dan beban kerja yang mendapat keuntungan dapat diarahkan secara khusus ke instans R5d dalam sebuah klaster Neptune, sementara beban kerja lainnya dapat diarahkan ke R5 atau tipe instans lainnya.

Untuk menggunakan cache pencarian pada instance Neptunus, cukup tingkatkan instance itu ke jenis instance. R5d Ketika Anda melakukannya, Neptunus secara otomatis menyetel parameter cluster DB 1 ke (diaktifkan), dan membuat cache pencarian pada instance tertentu. neptune_lookup_cache Anda kemudian dapat menggunakan Status instans API untuk mengonfirmasi bahwa cache telah diaktifkan.

Demikian pula, untuk menonaktifkan cache pencarian pada instance tertentu, turunkan instance dari tipe R5d instance ke tipe R5 instance yang setara.

Saat instans R5d diluncurkan, cache pencarian diaktifkan dan dalam mode start dingin, yang berarti bahwa cache kosong. Neptunus pertama-tama memeriksa di cache pencarian untuk nilai properti RDF atau literal saat memproses kueri, dan menambahkannya jika belum ada. Ini secara beransur-ansur memanaskan cache.

Saat Anda mengarahkan kueri baca yang memerlukan pencarian nilai properti atau RDF -literal ke instance pembaca R5d, kinerja baca sedikit menurun saat cache-nya memanas. Namun, ketika cache memanas, performa baca mempercepat secara signifikan dan Anda juga dapat melihat penurunan biaya I/O yang berkaitan dengan pencarian yang menemukan cache alih-alih penyimpanan klaster. Pemanfaatan memori juga meningkat.

Jika instans penulis adalah sebuah R5d, instans tersebut memanaskan cache pencariannya secara otomatis pada setiap operasi tulis. Pendekatan ini sedikit meningkatkan latensi untuk kueri tulis, tetapi memanaskan cache pencarian dengan lebih efisien. Kemudian jika Anda mengarahkan kueri baca yang memerlukan pencarian nilai properti atau RDF -literal ke instance penulis, Anda segera mulai meningkatkan kinerja baca, karena nilainya telah di-cache di sana.

Selain itu, jika Anda menjalankan loader massal pada instans tulis R5d, Anda mungkin memperhatikan bahwa performanya sedikit terdegradasi karena cache.

Karena cache pencarian dikhususkan untuk setiap node, penggantian host me-reset cache ke start dingin.

Anda dapat menonaktifkan sementara cache pencarian pada semua instance di cluster DB Anda dengan menyetel parameter cluster neptune_lookup_cache DB ke 0 (dinonaktifkan). Secara umum, bagaimanapun, lebih masuk akal untuk menonaktifkan cache pada instance tertentu dengan menurunkannya dari tipe R5 instance R5d ke bawah.