Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Nota
Fitur ini saat ini dalam pratinjau publik. Pratinjau ini disediakan tanpa perjanjian tingkat layanan, dan tidak disarankan untuk beban kerja produksi. Fitur tertentu mungkin tidak didukung atau mungkin memiliki kemampuan terbatas. Untuk informasi selengkapnya, lihat Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure.
Database grafik adalah jenis database yang mewakili informasi sebagai simpul (entitas) dan tepi (hubungan) alih-alih tabel dan baris. Struktur ini membuatnya mudah untuk menjelajahi koneksi dan pola yang kompleks di seluruh data Anda.
Jenis database grafik yang paling umum digunakan mengimplementasikan model grafik properti berlabel (LPG): entitas (simpul) dan hubungan (tepi) dapat memiliki label dan properti (pasangan kunci-nilai). Model fleksibel ini memungkinkan desain opsional skema dan berbasis skema, dan memungkinkan Anda mengekspresikan hubungan yang kompleks. Karena koneksi disimpan secara eksplisit sebagai tepi, kueri melintasi hubungan dengan mengikuti tepi alih-alih menghitung gabungan mahal pada waktu kueri.
Nota
Contoh dalam artikel ini menggunakan contoh himpunan data grafik jejaring sosial.
Konsep inti database graf
Database grafik mengatur data ke dalam tiga blok penyusun mendasar:
-
Simpul mewakili entitas seperti orang, produk, atau tempat. Simpul dapat memiliki label dan properti yang menjelaskan atributnya. Misalnya, node
Personmungkin memiliki properti sepertifirstName,lastName, danage. -
Tepi mewakili bagaimana entitas terhubung, misalnya
FRIENDS_WITH, ,PURCHASEDatauLOCATED_IN. Tepi juga dapat membawa properti dan label untuk mengambil metadata hubungan. - Properti melampirkan detail ke simpul dan tepi (misalnya, nama seseorang atau tepi sejak tanggal).
Cara kerja relasi kueri
Kueri grafik mengambil informasi yang terhubung dengan melintas dari simpul awal ke tetangganya, kemudian ke tetangga mereka, dan sebagainya. Biaya traversal tergantung pada jumlah tepi yang disentuhnya (lingkungan lokal), bukan ukuran total himpunan data. Karakteristik ini membuat pertanyaan tentang jalur, koneksi, dan pola—seperti teman teman, jalur terpendek, atau dependensi multi-hop—alami dan efisien untuk diekspresikan.
Database grafik menggunakan bahasa kueri berbasis pola, seperti Graph Query Language (GQL), untuk menjelaskan traversal ini secara ringkas. Grup kerja internasional yang sama yang mengawasi SQL (ISO/IEC 39075) menstandarkan GQL, yang menyelaraskan kueri grafik dengan standar database yang ditetapkan.
Contoh (pencocokan pola dengan GQL):
MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100
Pola ini dibaca sebagai: mulai dari simpul Person untuk Annemarie, mengikuti sisi :knows ke setiap simpul teman, lalu mengikuti sisi :likes ke simpul terkait :Comment. Mengembalikan 100 komentar terbaru yang diurutkan berdasarkan tanggal pembuatannya.
Penalaran berbasis grafik yang dibantu AI (pratinjau)
Database grafik sangat cocok untuk penalaran AI karena mereka mengodekan hubungan yang diperlukan model bahasa untuk menjawab pertanyaan multi-hop secara akurat. Dalam Microsoft Fabric, Fabric Data Agent mendukung grafik sebagai sumber data, memungkinkan pengguna untuk mengajukan pertanyaan bahasa alami yang dijawab agen dengan mengkueri grafik. Untuk detail tentang cara NL2GQL menerjemahkan bahasa alami ke dalam GQL, lihat pengumuman penalaran AI yang didukung Graph.
Model data grafik dan fleksibilitas skema
Model data graf bersifat opsional terhadap skema: Anda dapat memulai dengan model yang fleksibel dan memformalkannya seiring waktu. Dalam grafik dalam Microsoft Fabric, perubahan struktural — seperti menambahkan properti baru, memodifikasi label, atau mengubah jenis hubungan — saat ini memerlukan penyerapan ulang data ke dalam model baru. Pendekatan ini mengurangi kebutuhan akan duplikasi data dan memungkinkan tim menyatukan data dari beberapa sumber tanpa desain ulang di muka yang berat. Untuk informasi selengkapnya tentang model data yang digunakan dalam grafik di Microsoft Fabric, lihat grafik properti Labeled.
Penggunaan umum untuk database grafik
Database graf selaras dengan domain di mana koneksi mendorong nilai, seperti:
- Jejaring sosial — hubungan model antara orang dan interaksi mereka
- Grafik pengetahuan — menghubungkan konsep, entitas, dan fakta untuk pencarian dan penalaran semantik
- Sistem rekomendasi — melintasi interaksi item pengguna untuk menampilkan saran yang dipersonalisasi
- Jaringan penipuan dan risiko — mendeteksi pola mencurigakan di seluruh akun, transaksi, dan perangkat
- Topologi jaringan dan TI — memetakan dependensi antara server, layanan, dan komponen infrastruktur
- Analisis dependensi rantai pasokan — melacak asal komponen dan hubungan di seluruh pemasok
- Pembuatan berbasis grafik dengan retrieval-augmented generation (RAG) — gunakan struktur grafik sebagai sumber pengetahuan untuk agen AI yang memerlukan penalaran multi-hop dengan jawaban yang dapat dijelaskan dan didasari.
Dalam skenario ini, pertanyaan lebih jarang ditujukan pada catatan tunggal dan lebih fokus pada berapa banyak entitas yang terkait dan berinteraksi melalui beberapa tahap.
Kapan harus mempertimbangkan database grafik
Database grafik sangat cocok ketika hubungan mendorong pertanyaan inti yang perlu Anda jawab. Pilih database grafik saat:
- Pertanyaan utama Anda melibatkan jalur, lingkungan, dan pola dalam data yang terhubung.
- Jumlah hop bervariasi atau tidak diketahui sebelumnya.
- Anda perlu menggabungkan dan menavigasi hubungan di seluruh himpunan data yang berbeda.
Jika Anda secara teratur mengajukan pertanyaan semacam ini, model grafik sangat cocok.
Bagaimana grafik dalam Microsoft Fabric dibandingkan dengan database grafik mandiri
Mewakili data Anda sebagai graf dan menyimpannya dalam database graf mandiri sering memperkenalkan ETL (ekstrak, transformasi, muat) dan beban tata kelola. Sebaliknya, grafik dalam Microsoft Fabric beroperasi langsung di OneLake, yang mengurangi atau menghilangkan kebutuhan akan alur ETL terpisah dan duplikasi data. Pertimbangkan kompromi-kompromi berikut:
- Pergerakan dan duplikasi data: Database grafik mandiri biasanya memerlukan ekstraksi, transformasi, dan pemuatan data ke penyimpanan terpisah, yang meningkatkan kompleksitas dan dapat menyebabkan himpunan data duplikat. Grafik beroperasi di OneLake sehingga Anda dapat memodelkan dan mengkueri data yang terhubung tanpa memindahkannya.
- Biaya operasional: Tumpukan grafik mandiri berjalan sebagai kluster atau layanan terpisah dan sering membawa biaya kapasitas diam. Dalam grafik, beban kerja memanfaatkan unit kapasitas yang dikumpulkan (CUs) dengan pengurangan skala otomatis dan metrik terpusat, yang menyederhanakan operasi serta dapat mengurangi biaya.
- Skalabilitas: Beberapa database grafik mandiri bergantung pada peningkatan skala atau pengklusteran khusus vendor. Grafik dirancang untuk grafik skala besar dan menggunakan sharding peluasan skala di beberapa pekerja untuk menangani beban kerja big-data secara efisien.
- Alat dan keterampilan: Sistem grafik khusus vendor dapat memerlukan bahasa khusus dan kerangka kerja analitik terpisah. Grafik menyediakan pemodelan terpadu, kueri berbasis standar (GQL), algoritma analitik grafik bawaan, integrasi BI dan AI termasuk Fabric Data Agent dukungan untuk natural language graph querying (pratinjau), dan alat eksplorasi rendah/tanpa kode. Kemampuan ini memungkinkan sekumpulan pengguna yang lebih luas untuk bekerja dengan data yang terhubung.
- Tata kelola dan keamanan: Penyebaran grafik terpisah memerlukan tata kelola independen dan penyiapan keamanan. Grafik menggunakan tata kelola OneLake, silsilah data, dan kontrol akses berbasis peran ruang kerja (RBAC) sehingga kepatuhan, audit, dan izin tetap konsisten dengan lingkungan Fabric Anda lainnya.