Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Model kolam untuk grafik properti berlabel

Ada tiga pendekatan berbeda untuk model pool LPGs di Amazon Neptunus:

Strategi properti

Dengan LPGs, pengguna dapat menambahkan properti pasangan kunci-nilai ke node, atau simpul, dan tepi. Untuk mencapai pemisahan logis, sebagian besar pelanggan secara intuitif memodelkan ini sebagai properti unik di setiap node dan tepi dengan kunci properti penyewa umum. Kunci properti penyewa mewakili semua penyewa yang memiliki node. Pengidentifikasi penyewa adalah nilai unik yang mengidentifikasi penyewa individu.

Diagram berikut menunjukkan model ini. Dua subgraf yang terputus memiliki berbagai node dan tepi berlabel, dengan kunci properti penyewa diwakili oleh. TId Setiap simpul dan tepi dari satu subgraf memiliki TId nilai. 1 Dalam subgraf lainnya, setiap node dan edge memiliki TId nilai. 2

Dalam grafik properti berlabel, ada dua cara untuk mengelola ini. Bahasa query Gremlin menawarkan perpustakaan PartitionStrategytraversal untuk membantu mengelola partisi data data. Kode dalam contoh berikut mengharapkan setiap node dan edge memiliki properti yang disebutTId:

strategy1 = new PartitionStrategy(partitionKey: "TId", writePartition: "1", readPartitions: ["1"]) 
strategy2 = new PartitionStrategy(partitionKey: "TId", writePartition: "2", readPartitions: ["2"]) 

Ketika node atau tepi baru ditulis, properti "TId" ditambahkan dengan nilai "1" atau"2", tergantung pada apakah strategy1 atau strategy2 dipilih. Untuk pelanggan dengan "TId""1", Anda gunakanstrategy1. Contoh berikut menunjukkan penulisan data untuk pelanggan itu:

g.withStrategies(strategy1).addV("Label1").property("Value", "123456").property(id, "Item_1") 

Untuk kueri baca, filter untuk "TId == '1'" atau "TId == '2'" ditambahkan ke setiap node atau edge traversal dengan menggunakan strategy1 ataustrategy2, masing-masing. Strategi partisi ini menyederhanakan kode Anda, tetapi tidak diperlukan. Manfaat menggunakan strategi ini adalah dapat disuntikkan pada tingkat otorisasi dan diteruskan ke kode tingkat bawah yang membentuk kueri. Ini memisahkan kode yang menentukan identifier pelanggan (TId) dari logika kueri.

Kode contoh berikut menunjukkan query Gremlin untuk membaca data:

g.withStrategies(strategy1).V().hasLabel("Label1")

Kode sebelumnya setara dengan contoh berikut:

g.V().hasLabel("Label1").has("TId", "1")

Demikian juga, saat menulis data dengan menggunakan Gremlin, Anda dapat menggunakan kueri berikut:

g.withStrategies(strategy1).addV("Label1").property("Value").property(id, "Item_1")

Kode sebelumnya setara dengan contoh berikut, yang tidak menggunakan strategi partisi dan oleh karena itu memerlukan "TId" properti untuk ditulis secara eksplisit:

g.addV("Label1").property("TId", "1").property("Value").property(id, "Item_1")

Di OpenCypher, pustaka ini tidak ada. Anda bertanggung jawab untuk menulis dan memodifikasi kueri Anda untuk menambahkan pengenal penyewa sebagai properti pada node dan tepi. Contoh:

CREATE (n:Item {`~id`: 'Item_1', Value: '123456', TId: '1'})
CREATE (n:Item {`~id`: 'Item_2', Value: '123456', TId: '2'})

Perhatikan kesamaan antara kode Gremlin tanpa strategi partisi. Anda kemudian dapat membaca simpul yang ditulis dari CREATE pernyataan pertama dengan menggunakan kode berikut:

MATCH (n:Item {TId: '1'})
RETURN n
--or
MATCH (n:Item)
WHERE n.TId == '1'
RETURN n

Anda dapat memilih strategi properti ketika Anda ingin menggunakan konstruksi TinkerPop Gremlin asli seperti. PartitionStrategy Namun, model ini memiliki kelemahan kinerja di Amazon Neptunus dibandingkan dengan strategi label awalan. Untuk diskusi tentang kelemahan kinerja ini, lihat bagian Implikasi kinerja untuk model LPG.

Jika kondisi berikut berlaku, pertimbangkan untuk memodelkan strategi properti hanya pada node, bukan di tepi:

Strategi label awalan

Jika kinerja menjadi perhatian utama, kami sangat menyarankan untuk mempertimbangkan strategi label awalan daripada strategi properti.

Dalam strategi label awalan, Anda memberi label pada setiap node dengan kombinasi pengenal penyewa dan label node. Misalnya, jika penyewa memiliki pengenal "1" dan label node"Label1", Anda menentukan label node sebagai. "1-Label1" Diagram berikut menunjukkan dua subgraf terputus yang menggunakan model ini.

Saat menulis data di Gremlin, Anda dapat menambahkan nomor identifikasi ke label node apa pun:

g.addV("1-Label1")
g.addV("2-Label6")

Saat menanyakan grafik ini, Anda dapat memeriksa keberadaan awalan ini pada sebuah node:

g.V().hasLabel("1-Label1")

Di OpenCypher Anda dapat menulis data dengan menggunakan pernyataan: CREATE

CREATE (n:`1-Label1` {`~id`: 'Item_1', Value: 'XYZ123456'})

Untuk menanyakan data yang Anda tulis di OpenCypher, gunakan kode berikut:

MATCH n= (:`1-Label1`)
RETURN n

Strategi label awalan mengasumsikan bahwa semua node ditetapkan ke satu atau lebih penyewa dan bahwa izin tidak ditetapkan pada lingkup tepi. Hindari menggunakan strategi ini pada label tepi, karena itu akan menyebabkan sejumlah besar predikat dan akan berdampak negatif pada kinerja Neptunus.

Ada dua kelemahan utama untuk pendekatan label awalan. Pertama, sulit untuk menjalankan kueri apa pun yang menjangkau penyewa. Contohnya adalah kueri yang menghitung semua node dari label yang diberikan untuk pelaporan atau pemantauan. Jika ini adalah kasus penggunaan Anda, pertimbangkan untuk menggabungkan strategi ini dengan strategi multi-label. Untuk informasi selengkapnya tentang menggabungkan strategi, lihat bagian Model hibrida.

Kedua, strategi label awalan memerlukan kontrol yang menerapkan penerapan awalan yang tepat untuk setiap kueri untuk mencegah kebocoran data. Namun, strategi ini adalah opsi paling efisien untuk beban kerja yang memerlukan kueri latensi rendah, dan kami sangat merekomendasikannya. Bagian Implikasi Kinerja untuk model LPG memberikan contoh mengapa ini adalah strategi yang paling efisien.

Strategi multi-label

Opsi ketiga adalah menggunakan strategi multi-label. Untuk pendekatan ini, Anda menambahkan label tambahan ke setiap node pada grafik. Misalnya, jika Anda perlu memfilter semua data untuk penyewa tertentu, tambahkan label ID penyewa. Jika Anda perlu memfilter semua data untuk label tertentu terlepas dari penyewa, tambahkan label itu. Diagram berikut menunjukkan strategi multi-label diterapkan dengan menggunakan tiga label untuk setiap node.

Anda sekarang dapat mengakses grafik dengan menggunakan tiga pola berbeda:

Sebab LPGs, ada dua cara untuk mengimplementasikan ini.

Di Gremlin, Anda dapat menggunakan strategi traversal yang dipanggil SubgraphStrategyuntuk membatasi ruang lingkup semua kueri hanya simpul dengan label tertentu, seperti: "Label1"

g.withStrategies(
    new SubgraphStrategy(
        vertices=hasLabel("Label1")
    )
)

Tidak seperti PartitionStrategy, SubgraphStrategy berdampak hanya membaca data, bukan menulis data. Untuk menulis data, tetapkan label secara manual di setiap kueri:

g.addV("Label1").property("Value","XYZ123456")
.addV("Label2").property("Value","XYZ123456")

Saat membaca data, Anda dapat menggunakan SubgraphStrategy untuk menanyakan semua node dengan"Label1":

g.withStrategies(
new SubgraphStrategy(vertices=.hasLabel("Label1"))
).
V().has("Value","XYZ123456")

Neptunus hanya mengembalikan rekor pertama, yang "Label1" memiliki dan nilai. "XYZ123456" Ini setara dengan kueri berikut, yang tidak menggunakan SubgraphStrategy:

g.V().hasLabel("Label1").hasValue("XYZ123456")

Dalam kueri dasar ini, tampaknya SubgraphStrategy lebih kompleks untuk digunakan. Perlu diingat bahwa perpustakaan Anda dapat menyediakan contoh g dengan strategi yang sudah ditentukan. Pengembang tidak perlu memastikan bahwa filter yang tepat diterapkan:

def getGraphTraversal():
return g.withStrategies(new SubgraphStrategy(vertices=.hasLabel("Label1"))

getGraphTraversal().has("Value","XYZ123456")

Pustaka OpenCypher tidak memiliki konstruksi ini, jadi Anda harus membuat beberapa label untuk setiap node:

CREATE (n:`1`:`Label1`:`1-Label1` {`~id`: 'Item_1', Value: '12345'})

Saat Anda menggunakan label ini untuk memfilter subgraf, Anda dapat mengembalikan node yang memiliki label pelanggan yang Anda cari atau yang berbagi hubungan dengan node lain yang memiliki label itu:

MATCH n=(:Label1:`1`)
// or
MATCH n=(:`1-Label1`)

Strategi multi-label memberi Anda fleksibilitas paling besar untuk menanyakan node berdasarkan type (Label1) atau tenant (1), atau menggunakan strategi label awalan yang lebih efisien saat kinerja paling penting (). 1-Label1

Kelemahan utama dari strategi ini adalah bahwa setiap label adalah objek tambahan yang disimpan dalam grafik Anda. Objek adalah simpul, tepi, atau properti pada simpul atau tepi di LPGs. Kecepatan konsumsi diukur dan diikat oleh objek per detik, dan biaya penyimpanan tergantung pada jumlah gigabyte yang dikonsumsi. Ini berarti bahwa objek tambahan mungkin memiliki dampak yang dapat diukur dalam skala besar.

Implikasi kinerja untuk model LPG

Kursus Pemodelan Data AWS Skill Builder untuk Amazon Neptunus menjelaskan secara mendalam internal model data Neptunus dan implikasi pemodelan, tetapi kami akan merangkum pertimbangan penting untuk desain ini di sini. Pertimbangkan untuk memiliki tiga penyewa (T1, T2, T3) pada satu cluster Neptunus. Penyewa ini memiliki atribut berikut:

Jalankan kueri yang akan mengambil item untuk Tenant 3 dengan menggunakan strategi properti. Neptunus memeriksa statistik untuk dua panggilan indeks:

Pengoptimal kueri Neptunus menentukan bahwa kueri terakhir paling baik diterapkan terlebih dahulu (12 juta hasil) dan kemudian memeriksa setiap item. tenant property key=T3 Anda mengambil 12 juta item untuk menemukan 1 juta hasil.

Perhatikan dampak tetangga yang bising dari kueri ini. Jika Anda memiliki 100 juta node Item per penyewa, kueri pertama akan memiliki 300 juta hasil, bukan 12 juta (Ini terlalu disederhanakan untuk tujuan ilustrasi. Pengoptimal Neptunus mungkin telah menerapkan urutan operasi yang berbeda).

Selanjutnya, pertimbangkan strategi label awalan. Buat panggilan indeks tunggal di manalabel=T3-Item, yang mengembalikan 1 juta hasil. Ini mencapai hasil yang sama dengan strategi properti, tetapi mengambil 11 juta catatan lebih sedikit. Selain itu, Anda tidak lagi memiliki masalah tetangga yang berisik karena label tidak tumpang tindih dalam indeks.

Strategi multi-label tidak memberikan peningkatan kinerja kueri atas strategi properti secara langsung. Pemfilteran berdasarkan nilai properti sebanding dengan pemfilteran berdasarkan nilai label saat ruang pencarian juga sebanding. Sebaliknya, strategi multi-label mendukung lebih banyak fleksibilitas.  Strategi multi-label memberikan kinerja yang setara dengan strategi label awalan untuk atau label. label=T3 T3-Item Strategi multi-label memberikan kinerja yang setara dengan strategi properti untuk. label=Item Manfaatnya adalah mendukung berbagai pola akses.