Pilar efisiensi performa

Pilar efisiensi kinerja dari AWS Well-Architected Framework berfokus pada cara mengoptimalkan kinerja sambil menelan atau menanyakan data. Optimalisasi kinerja adalah proses tambahan dan berkelanjutan dari hal-hal berikut:

• Mengonfirmasi persyaratan bisnis

• Mengukur kinerja beban kerja

• Mengidentifikasi komponen yang berkinerja buruk

• Menyetel komponen untuk memenuhi kebutuhan bisnis Anda

Pilar efisiensi kinerja menyediakan pedoman khusus kasus penggunaan yang dapat membantu mengidentifikasi model data grafik dan bahasa kueri yang tepat untuk digunakan. Ini juga mencakup praktik terbaik untuk diikuti saat menelan data ke dalam dan mengkonsumsi data dari Amazon Neptunus.

Pilar efisiensi kinerja berfokus pada bidang-bidang utama berikut:

• Pemodelan grafik

• Pengoptimalan kueri

• Ukuran kanan cluster

• Tulis optimasi

Memahami pemodelan grafik

Memahami perbedaan antara model Grafik Properti Berlabel (LPG) dan Resource Description Framework (RDF). Dalam kebanyakan kasus, ini adalah masalah preferensi. Namun, ada beberapa kasus penggunaan, di mana satu model lebih cocok daripada yang lain. Jika Anda memerlukan pengetahuan tentang jalur yang menghubungkan dua node dalam grafik Anda, pilih LPG. Jika Anda ingin menggabungkan data di seluruh cluster Neptunus atau penyimpanan tiga grafik lainnya, pilih RDF.

Jika Anda membangun aplikasi perangkat lunak sebagai layanan (SaaS) atau aplikasi yang membutuhkan multi-tenancy, pertimbangkan untuk memasukkan pemisahan logis penyewa dalam model data Anda alih-alih memiliki satu penyewa untuk setiap cluster. Untuk mencapai jenis desain tersebut, Anda dapat menggunakan grafik bernama SPARQL dan strategi pelabelan, seperti menambahkan pengidentifikasi pelanggan ke label atau menambahkan pasangan nilai kunci properti yang mewakili pengidentifikasi penyewa. Pastikan layer klien Anda menyuntikkan nilai-nilai ini untuk menjaga pemisahan logis itu.

Kinerja kueri Anda tergantung pada jumlah objek grafik (node, tepi, properti) yang perlu dievaluasi dalam pemrosesan kueri Anda. Dengan demikian, model grafik dapat berdampak signifikan pada kinerja aplikasi Anda. Gunakan label granular bila memungkinkan, dan simpan hanya properti yang Anda butuhkan untuk mencapai penentuan jalur atau penyaringan. Untuk mencapai kinerja yang lebih tinggi, pertimbangkan untuk menghitung bagian grafik Anda, seperti membuat simpul ringkasan atau lebih banyak tepi langsung yang menghubungkan jalur umum.

Cobalah untuk menghindari navigasi melintasi node yang memiliki jumlah tepi yang sangat tinggi dengan label yang sama. Node seperti itu sering memiliki ribuan tepi (di mana sebagian besar node memiliki jumlah tepi dalam puluhan). Hasilnya adalah komputasi dan kompleksitas data yang jauh lebih tinggi. Node ini mungkin tidak bermasalah dalam beberapa pola kueri, tetapi kami menyarankan pemodelan data Anda secara berbeda untuk menghindarinya, terutama jika Anda akan menavigasi di seluruh node sebagai langkah perantara. Anda dapat menggunakan log kueri lambat untuk membantu mengidentifikasi kueri yang menavigasi di seluruh node ini. Anda mungkin akan mengamati latensi dan metrik akses data yang jauh lebih tinggi daripada pola kueri rata-rata Anda, terutama jika Anda menggunakan mode debug.

Gunakan simpul deterministik IDs untuk node dan tepi jika kasus penggunaan Anda mendukungnya alih-alih menggunakan Neptunus untuk menetapkan nilai GUID acak. IDs Mengakses node dengan ID adalah metode yang paling efisien.

Optimalkan kueri

Bahasa OpenCypher dan Gremlin dapat digunakan secara bergantian pada model LPG. Jika kinerja menjadi perhatian utama, pertimbangkan untuk menggunakan dua bahasa secara bergantian karena yang satu mungkin berkinerja lebih baik daripada yang lain untuk pola kueri tertentu.

Neptunus sedang dalam proses konversi ke mesin kueri alternatifnya (DFE). OpenCypher berjalan pada DFE saja, tetapi kueri Gremlin dan SPARQL dapat diatur secara opsional untuk berjalan pada DFE dengan menggunakan anotasi kueri. Pertimbangkan untuk menguji kueri Anda dengan DFE diaktifkan dan membandingkan kinerja pola kueri Anda saat tidak menggunakan DFE.

Neptunus dioptimalkan untuk kueri tipe transaksional yang dimulai pada satu node atau set node dan menyebar dari sana, bukan kueri analitis yang mengevaluasi seluruh grafik. Untuk beban kerja kueri analitis Anda, pertimbangkan untuk menggunakan AWS SDK for Pandas atau menggunakan neptune-export yang digabungkan dengan atau Amazon EMR. AWS Glue

Untuk mengidentifikasi inefisiensi dan kemacetan dalam model dan kueri Anda, gunakan dan explain APIs untuk setiap bahasa kueri untuk mendapatkan penjelasan rinci tentang rencana kueri profile dan metrik kueri. Untuk informasi lebih lanjut, lihat profil Gremlin, OpenCypher menjelaskan, dan SPARQL menjelaskan.

Pahami pola kueri Anda. Jika jumlah tepi yang berbeda dalam grafik menjadi besar, strategi akses Neptunus default dapat menjadi tidak efisien. Pertanyaan berikut mungkin menjadi sangat tidak efisien:

• Kueri yang menavigasi mundur melintasi tepi saat tidak ada label tepi yang diberikan.

• Klausa yang menggunakan pola yang sama ini secara internal, seperti .both() di Gremlin, atau klausa yang menjatuhkan node dalam bahasa apa pun (yang mengharuskan menjatuhkan tepi masuk tanpa sepengetahuan label).

• Kueri yang mengakses nilai properti tanpa menentukan label properti. Pertanyaan ini mungkin menjadi sangat tidak efisien. Jika ini cocok dengan pola penggunaan Anda, pertimbangkan untuk mengaktifkan indeks OSGP (objek, subjek, grafik, predikat).

Gunakan pencatatan kueri lambat untuk mengidentifikasi kueri lambat. Kueri yang lambat dapat disebabkan oleh rencana kueri yang tidak dioptimalkan atau sejumlah besar pencarian indeks yang tidak perlu, yang dapat meningkatkan biaya I/O. Neptunus menjelaskan dan membuat profil titik akhir untuk Gremlin, SPARQL, atau OpenCypher dapat membantu Anda memahami mengapa kueri ini lambat. Penyebabnya mungkin termasuk yang berikut:

• Node dengan jumlah tepi yang sangat tinggi dibandingkan dengan simpul rata-rata dalam grafik (misalnya, ribuan dibandingkan dengan puluhan) dapat menambah kompleksitas komputasi dan karenanya latensi yang lebih lama dan konsumsi sumber daya yang lebih besar. Tentukan apakah node ini dimodelkan dengan benar, atau apakah pola akses dapat ditingkatkan untuk mengurangi jumlah tepi yang harus dilalui.

• Kueri yang tidak dioptimalkan akan berisi peringatan bahwa langkah-langkah tertentu tidak dioptimalkan. Menulis ulang kueri ini untuk menggunakan langkah-langkah yang dioptimalkan dapat meningkatkan kinerja.

• Filter redundan dapat menyebabkan pencarian indeks yang tidak perlu. Demikian juga, pola redundan dapat menyebabkan pencarian indeks duplikat yang dapat dioptimalkan dengan meningkatkan kueri (lihat Index Operations - Duplication ratio di output profil).

• Beberapa bahasa seperti Gremlin tidak memiliki nilai numerik yang diketik dengan kuat, dan mereka menggunakan promosi tipe sebagai gantinya. Misalnya, jika nilainya 55, Neptunus mencari nilai yang merupakan bilangan bulat, panjang, float, dan tipe numerik lainnya yang setara dengan 55. Ini menghasilkan operasi tambahan. Jika Anda tahu jenis Anda cocok sebelumnya, Anda dapat menghindari ini dengan menggunakan petunjuk kueri.

• Model grafik Anda dapat sangat memengaruhi kinerja. Pertimbangkan untuk mengurangi jumlah objek yang perlu dievaluasi dengan menggunakan label yang lebih terperinci atau dengan menghitung pintasan ke jalur linier multi-hop.

Jika optimasi kueri saja tidak memungkinkan Anda untuk mencapai persyaratan kinerja Anda, pertimbangkan untuk menggunakan berbagai teknik caching dengan Neptunus untuk mencapai persyaratan tersebut.

Cluster ukuran kanan

Ukur ukuran cluster Anda untuk persyaratan konkurensi dan throughput Anda. Jumlah query bersamaan yang dapat ditangani oleh setiap instance di cluster sama dengan dua kali jumlah virtual CPUs (vCPUs) pada instance itu. Kueri tambahan yang muncul saat semua thread pekerja ditempati dimasukkan ke dalam antrean sisi server. Kueri tersebut ditangani berdasarkan first-in-first-out (FIFO) saat thread pekerja tersedia. CloudWatch Metrik MainRequestQueuePendingRequests Amazon menunjukkan kedalaman antrian saat ini untuk setiap instance. Jika nilai ini sering di atas nol, pertimbangkan untuk memilih instance dengan lebih banyak vCPUs. Jika kedalaman antrian melebihi 8.192, Neptunus akan mengembalikan kesalahan. ThrottlingException

Sekitar 65 persen RAM untuk setiap instance dicadangkan untuk cache buffer. Cache buffer menyimpan kumpulan data yang berfungsi (bukan seluruh grafik; hanya data yang sedang ditanyakan). Untuk menentukan persentase data yang diambil dari cache buffer alih-alih penyimpanan, pantau metrik. CloudWatch BufferCacheHitRatio Jika metrik ini sering turun di bawah 99,9 persen, pertimbangkan untuk mencoba instance dengan lebih banyak memori untuk menentukan apakah itu mengurangi latensi dan biaya I/O Anda.

Replika baca tidak harus berukuran sama dengan instance penulis Anda. Namun, beban kerja tulis yang berat dapat menyebabkan replika yang lebih kecil tertinggal dan reboot karena mereka tidak dapat mengikuti replikasi. Oleh karena itu, kami merekomendasikan membuat replika sama dengan atau lebih besar dari contoh penulis.

Saat menggunakan auto-scaling untuk replika baca Anda, ingatlah bahwa mungkin perlu waktu hingga 15 menit untuk menghadirkan replika baca baru secara online. Ketika lalu lintas klien meningkat dengan cepat tetapi dapat diprediksi, pertimbangkan untuk menggunakan penskalaan terjadwal untuk menetapkan jumlah minimum replika baca yang lebih tinggi untuk memperhitungkan waktu inisialisasi tersebut.

Instans tanpa server mendukung beberapa kasus penggunaan dan beban kerja yang berbeda. Pertimbangkan tanpa server atas instance yang disediakan untuk skenario berikut:

• Beban kerja Anda sering berfluktuasi sepanjang hari.

• Anda membuat aplikasi baru dan Anda tidak yakin berapa ukuran beban kerja nantinya.

• Anda sedang melakukan pengembangan dan pengujian.

Penting untuk dicatat bahwa instans tanpa server lebih mahal daripada instance yang disediakan setara dengan satu dolar per GB basis RAM. Setiap instance tanpa server terdiri dari 2 GB RAM bersama dengan vCPU dan jaringan terkait. Lakukan analisis biaya di antara opsi Anda untuk menghindari tagihan kejutan. Secara umum, Anda akan mencapai penghematan biaya dengan tanpa server hanya ketika beban kerja Anda sangat berat hanya beberapa jam setiap hari dan hampir nol sepanjang hari atau jika beban kerja Anda berfluktuasi secara signifikan sepanjang hari.

Optimalkan menulis

Untuk mengoptimalkan penulisan, pertimbangkan hal berikut:

• Pemuat Massal Neptunus adalah cara optimal untuk memuat database Anda atau menambahkan ke data yang ada. Pemuat Neptunus tidak transaksional dan tidak dapat menghapus data, jadi jangan gunakan jika ini adalah persyaratan Anda.

• Pembaruan transaksional dapat dilakukan dengan menggunakan bahasa kueri yang didukung. Untuk mengoptimalkan operasi tulis I/O, tulis data dalam batch 50-100 objek per komit. Objek adalah node, edge, atau properti pada node atau edge di LPG, atau triple store atau quad di RDF..

• Semua operasi penulisan Neptunus adalah ulir tunggal untuk setiap koneksi. Saat mengirim sejumlah besar data ke Neptunus, pertimbangkan untuk memiliki beberapa koneksi paralel yang masing-masing merupakan data penulisan. Saat Anda memilih instance yang disediakan Neptunus, ukuran instance dikaitkan dengan sejumlah v. CPUs Neptunus membuat dua utas database untuk setiap vCPU pada instance, jadi mulailah dengan dua kali jumlah CPUs v saat menguji paralelisasi optimal.  Instans tanpa server menskalakan jumlah v dengan CPUs kecepatan kira-kira satu untuk setiap 4. NCUs

• Rencanakan dan tangani secara efisien ConcurrentModificationExceptionsselama semua proses penulisan, bahkan jika hanya satu koneksi yang menulis data kapan saja. Rancang klien Anda untuk keandalan saat ConcurrentModificationExceptions terjadi.

• Jika Anda ingin menghapus semua data Anda, pertimbangkan untuk menggunakan API reset cepat alih-alih mengeluarkan kueri penghapusan bersamaan. Yang terakhir akan memakan waktu lebih lama dan menimbulkan biaya I/O yang besar dibandingkan dengan yang pertama.

• Jika Anda ingin menghapus sebagian besar data Anda, pertimbangkan untuk mengekspor data yang ingin Anda simpan dengan menggunakan neptune-export untuk memuat data ke dalam klaster baru. Kemudian hapus cluster asli.