Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Poznámka:
Tato funkce je aktuálně ve verzi Public Preview. Tato verze Preview se poskytuje bez smlouvy o úrovni služeb a nedoporučuje se pro produkční úlohy. Některé funkce nemusí být podporované nebo můžou mít omezené možnosti. Další informace najdete v dodatečných podmínkách použití pro verze Preview v Microsoft Azure.
Grafová databáze modeluje data jako síť propojených entit a relací. Nejčastěji používaný typ grafové databáze implementuje model grafu vlastností s popiskem : entity (uzly) a relace (hrany) můžou mít popisky a vlastnosti (páry klíč-hodnota). Tento flexibilní model umožňuje návrh s volitelným schématem i s pevným schématem a umožňuje vyjádřit bohatou sémantiku. Vzhledem k tomu, že připojení jsou explicitně uložená jako hrany, dotazy procházejí relacemi využíváním hran místo provádění drahých operací spojení při zpracování dotazu.
Důležité
Tento článek výhradně používá datovou sadu grafů ze sociálních sítí.
Základní koncepty grafové databáze
- Uzly představují věci, jako jsou lidé, produkty nebo místa. Uzly můžou mít popisky a vlastnosti, které popisují jejich atributy.
- Hrany představují, jak jsou tyto věci propojené, například FRIENDS_WITH, PURCHASED nebo LOCATED_IN. Hrany mohou také nést vlastnosti a štítky pro kódování metadat relací.
- Vlastnosti přidávají podrobnosti k uzlům a hranám (například jméno osoby nebo datum, odkdy hrana existuje). Vzhledem k tomu, že relace jsou explicitně uložené jako hrany, dotazy procházejí grafem sledováním spojení, než aby je vypočítávaly v čase dotazu.
Jak funguje dotazování na relace
Grafové dotazy načítají propojené informace procházením od počátečního uzlu k jeho sousedům, pak k jejich sousedům atd. Úsilí, které procházení provede, je svázáno s počtem hran, jimiž prochází (lokální okolí), nikoli celkovou velikostí datové sady. Díky tomu jsou otázky týkající se cest, spojení a vzorů, jako jsou přátelé přátel, nejkratší cesty nebo vícekrokové závislosti, přirozené a efektivní pro vyjádření.
Grafové databáze používají dotazovací jazyky založené na vzorech, jako je stále častěji přijímaný jazyk Graph Query Language (GQL), k stručné popisu těchto procházení. GQL je standardizován stejnou mezinárodní pracovní skupinou, která dohlíží na SQL (ISO/IEC 39075), a zarovná dotazování grafů se zavedenými databázovými standardy.
Příklad (porovnávání vzorů s GQL):
MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100
Tento vzor funguje takto: začnete od uzlu osoby Annemarie, sledujte připojení :knows ke každému příteli, následně sledujte připojení :likes k souvisejícím uzlům :Comment a vraťte 100 nejnovějších z těchto komentářů.
Modelování a schéma
Datové modely grafů jsou schéma-opční: můžete pracovat s pevným schématem, pokud potřebujete silné řízení, nebo model vyvíjet, jak se objevují nové typy uzlů, vztahy nebo vlastnosti. Tento přístup snižuje potřebu duplikace dat a umožňuje týmům sjednotit data z více zdrojů bez náročného návrhu.
Běžné použití pro grafové databáze
Grafové databáze úzce odpovídají doménám, kde připojení řídí hodnotu, jako jsou sociální sítě, grafy znalostí, systémy doporučení, podvody a rizikové sítě, topologie sítě a IT a analýza závislostí dodavatelského řetězce. V těchto scénářích jsou dotazy méně o jednotlivých záznamech a více o tom, kolik entit souvisí a interaguje přes několik přeskoků.
Kdy zvážit grafovou databázi
Vyberte grafovou databázi, pokud vaše hlavní otázky zahrnují cesty, sousedství a vzory v připojených datech; pokud je počet skoků proměnný nebo není předem znám; nebo když potřebujete kombinovat a navigovat v relacích mezi různorodými datovými sadami. Pokud se jedná o otázky, na které potřebujete odpovědět opakovaně, je grafový model přirozeným fitem.
A co ETL
Reprezentace dat jako grafu a jejich uložení v samostatné samostatné grafové databázi často představuje režijní náklady na ETL a zásady správného řízení. Naproti tomu graf v Microsoft Fabric funguje přímo na OneLake, což snižuje nebo eliminuje potřebu samostatných kanálů ETL a duplicit dat. Zvažte tyto kompromisy:
- Přesun a duplikace dat: Samostatné grafové databáze obvykle vyžadují extrakci, transformaci a načítání dat (ETL) do samostatného úložiště, což zvyšuje složitost a může vést k duplikovaným datovým sadám. Graph v Microsoft Fabric funguje na OneLake, takže můžete modelovat a dotazovat připojená data bez jejich přesunutí.
- Provozní náklady: Samostatné zásobníky grafů fungují jako oddělené clustery nebo služby a často zahrnují poplatky za nevyužitou kapacitu. Grafové úlohy ve Fabric spotřebovávají jednotky kapacity ve fondu s automatickým snížením kapacity a centralizovanými metrikami, které zjednodušují provoz a můžou snížit náklady.
- Škálovatelnost: Některé samostatné grafové databáze závisí na škálování pomocí rozšiřování stávajících systémů nebo na clusteringu specifickém pro dodavatele. Graph v rámci Microsoft Fabric je navržený pro rozsáhlé grafy a využívá škálování pomocí horizontálního dělení napříč několika pracovníky k efektivnímu zpracování úloh s velkými objemy dat.
- Nástroje a dovednosti: Systémy grafů specifické pro dodavatele mohou vyžadovat specializované jazyky a samostatné analytické architektury. Graph v Microsoft Fabric poskytuje sjednocené modelování, dotazování založené na standardech (GQL), integrované algoritmy analýzy grafů, integraci BI a AI a nástroje pro průzkumné analýzy bez kódu, takže širší sada uživatelů může pracovat s připojenými daty.
- Zásady správného řízení a zabezpečení: Samostatná nasazení grafů vyžadují nezávislé nastavení zásad správného řízení a zabezpečení. Graph v Microsoft Fabric používá zásady správného řízení OneLake, rodokmen a řízení přístupu na základě role (RBAC), takže dodržování předpisů, auditování a oprávnění zůstává konzistentní se zbytkem vašeho prostředí Fabric.