View a markdown version of this page

Praktik terbaik untuk mengelola hubungan banyak-ke-banyak dalam tabel DynamoDB - Amazon DynamoDB

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

Praktik terbaik untuk mengelola hubungan banyak-ke-banyak dalam tabel DynamoDB

Daftar kedekatan adalah pola desain yang berguna untuk pemodelan hubungan banyak-ke-banyak di Amazon DynamoDB. Secara lebih umum, daftar ini menyediakan cara untuk merepresentasikan data grafik (simpul dan edge) di DynamoDB.

Pola desain daftar kedekatan

Ketika entitas yang berbeda dari suatu aplikasi memiliki hubungan banyak-ke-banyak di antara entitas tersebut, hubungan ini dapat dimodelkan sebagai daftar kedekatan. Dalam pola ini, semua entitas tingkat atas (sama dengan simpul dalam model grafik) direpresentasikan menggunakan kunci partisi. Hubungan apa pun dengan entitas lain (edge dalam grafik) direpresentasikan sebagai item dalam partisi dengan mengatur nilai kunci urutan ke ID entitas target (simpul target).

Keunggulan pola ini antara lain duplikasi data yang minimal dan pola kueri yang disederhanakan untuk menemukan semua entitas (simpul) yang terkait dengan entitas target (memiliki edge terhadap simpul target).

Contoh aktual kegunaan pola ini adalah sistem faktur dengan faktur yang berisi beberapa tagihan. Satu tagihan bisa masuk ke beberapa faktur. Kunci partisi dalam contoh ini adalah InvoiceID atau BillID. Partisi BillID memiliki semua atribut yang khusus untuk tagihan. Partisi InvoiceID memiliki item yang menyimpan atribut khusus faktur, dan item untuk masing-masing BillID yang dimasukkan ke faktur.

Skemanya akan seperti berikut.

Skema tabel untuk contoh daftar kedekatan penagihan.

Menggunakan skema sebelumnya, Anda dapat melihat bahwa semua tagihan dalam faktur dapat dikueri menggunakan kunci primer pada tabel. Untuk mencari semua faktur yang memuat bagian dari tagihan, buat indeks sekunder global pada kunci urutan tabel.

Proyeksi untuk indeks sekunder global akan seperti berikut.

Proyeksi GSI untuk contoh daftar kedekatan penagihan.

Pola grafik terwujud

Banyak aplikasi perlu memahami peringkat antar rekan, hubungan antar entitas, dan status entitas tetangga. Jika aplikasi Anda menggunakan jenis alur kerja gaya grafik ini, pertimbangkan pola desain skema berikut.

Sebagai contoh dunia nyata, pertimbangkan aplikasi jejaring sosial. Dalam aplikasi ini, orang memiliki hubungan dengan orang lain, memiliki keterampilan, tinggal di tempat, dan memiliki tanggal terkait (seperti tanggal lahir). Setiap orang adalah simpul dalam grafik. Hubungan antara orang-orang, seperti persahabatan, adalah tepi. Asosiasi antara orang dan atribut mereka (keterampilan, tempat, tanggal) juga merupakan tepi.

Dengan pola grafik yang terwujud, Anda dapat menyimpan node dan tepi dalam satu tabel DynamoDB dan melintasi hubungan secara efisien. Diagram berikut menunjukkan bagaimana memodelkan grafik jejaring sosial ini. Diagram pertama menunjukkan struktur tabel utama. Diagram berikutnya menunjukkan proyeksi indeks sekunder global.

Skema tabel utama untuk pola grafik yang terwujud di DynamoDB, menunjukkan orang sebagai kunci partisi dengan tepinya sebagai item dalam setiap partisi.
Proyeksi indeks sekunder global pertama di DynamoDB, dibangun di atas atribut Data kelebihan beban untuk kueri berdasarkan tanggal, nama, tempat, dan keterampilan.
Proyeksi indeks sekunder global kedua di DynamoDB, dibangun di atas kunci kom TypeTarget posit untuk pencarian terbalik.

Tabel menggunakan struktur kunci berikut:

  • Kunci partisi — ID entitas (misalnya,Person-1,Person-2). Setiap partisi berisi satu item simpul dan beberapa item tepi.

  • Sort key — Untuk item node, ID entitas itu sendiri. Untuk item tepi, gabungan dari jenis tepi dan target (misalnya, Friend-Person-2 atauSkill-DynamoDB).

Item edge berisi atribut Target dan Type. Ini membentuk kunci komposit TypeTarget "" yang mengidentifikasi item dalam tabel utama dan dalam indeks sekunder global kedua. Misalnya, "Person-1 berteman dengan Person-2" menghasilkanType=Friend,Target=Person-2, danTypeTarget=Friend-Person-2.

Indeks sekunder global pertama dibangun di atas atribut Data. Atribut ini menggunakan kelebihan beban indeks sekunder global untuk mengindeks beberapa jenis atribut dalam indeks yang sama:

  • Dates— tanggal lahir, tanggal bergabung (misalnya,1971-12-21)

  • Names— nama tampilan (misalnya,Ana Carolina Silva)

  • Places— lokasi (misalnya,Seattle)

  • Skills— kompetensi (misalnya,DynamoDB)

Anda dapat menggunakan indeks sekunder global tunggal ini untuk menanyakan semua orang yang lahir pada tanggal tertentu, semua orang di suatu lokasi, atau semua orang dengan keterampilan tertentu.

Indeks sekunder global kedua digunakan TypeTarget sebagai kunci partisi untuk pencarian terbalik. Misalnya, Anda dapat menemukan semua orang yang mendaftar Person-2 sebagai teman dengan menanyakan. TypeTarget=Friend-Person-2

Saat Anda memasukkan item ke dalam tabel, Anda dapat menggunakan strategi sharding cerdas untuk mendistribusikan kumpulan item dengan agregasi besar (tanggal lahir, keterampilan) di sebanyak mungkin partisi logis pada indeks sekunder global yang diperlukan untuk menghindari masalah panas. read/write

Dengan kombinasi pola desain ini, Anda mendapatkan penyimpanan data yang solid untuk alur kerja grafik real-time yang sangat efisien. Anda dapat menggunakannya untuk membangun kueri status entitas tetangga dan agregasi tepi berkinerja tinggi untuk mesin rekomendasi, aplikasi jejaring sosial, peringkat node, agregasi subpohon, dan kasus penggunaan grafik umum lainnya.

Jika kasus penggunaan Anda tidak sensitif terhadap konsistensi data waktu nyata, Anda dapat menggunakan proses Amazon EMR terjadwal untuk mengisi edge dengan agregasi ringkasan grafik yang relevan untuk alur kerja Anda. Anda dapat menggunakan proses terjadwal untuk menggabungkan hasil jika aplikasi Anda tidak perlu segera mengetahui kapan edge ditambahkan ke grafik.

Untuk mempertahankan beberapa tingkat konsistensi, desain dapat menyertakan Amazon DynamoDB Streams dan AWS Lambda untuk memproses pembaruan edge. Desain ini juga bisa menggunakan tugas Amazon EMR untuk memvalidasi hasil secara berkala. Pendekatan ini diilustrasikan dengan diagram berikut. Ini biasanya digunakan dalam aplikasi jejaring sosial, jika biaya kueri waktu nyata tinggi dan kebutuhan untuk mengetahui pembaruan pengguna individu rendah.

Diagram yang mengilustrasikan alur kerja grafik.

Manajemen layanan TI (IT service-management/ITSM) dan aplikasi keamanan umumnya perlu merespons secara waktu nyata terhadap perubahan status entitas yang terdiri dari agregasi edge yang kompleks. Aplikasi semacam itu membutuhkan sistem yang dapat mendukung agregasi beberapa simpul waktu nyata dari hubungan tingkat kedua dan ketiga, atau traversal edge yang kompleks. Jika kasus penggunaan Anda memerlukan jenis alur kerja kueri grafik waktu nyata ini, sebaiknya pertimbangkan menggunakan Amazon Neptune untuk mengelola alur kerja ini.

catatan

Jika Anda perlu menanyakan kumpulan data yang sangat terhubung atau melintasi beberapa node (kueri multi-hop) dengan latensi milidetik, pertimbangkan untuk menggunakan Amazon Neptune. https://docs.aws.amazon.com/neptune/latest/userguide/ Amazon Neptune adalah mesin database grafik berkinerja tinggi yang dibuat khusus. Ini dioptimalkan untuk menyimpan miliaran hubungan dan menanyakan grafik dengan latensi milidetik.