Proč byste měli používat databázi grafů

Jeff Carpenter je technickým evangelistou ve společnosti DataStax.

V poslední době došlo k velkému humbuku ohledně databází grafů. Zatímco databáze grafů, jako jsou DataStax Enterprise Graph (založené na Titan DB), Neo4 a IBM Graph, existují již několik let, nedávná oznámení o spravovaných cloudových službách, jako je AWS Neptune a přidání možnosti grafu společnosti Microsoft do Azure Cosmos DB, naznačují, že databáze grafů vstoupili do hlavního proudu. Jak se vším tímto zájmem zjistíte, zda je databáze grafů vhodná pro vaši aplikaci?

Co je databáze grafů?

Než půjdeme dále, definujme terminologii. Co je databáze grafů? Přemýšlejte o tom z hlediska datového modelu. Datový model grafu se skládá z vrcholy které představují entity v doméně a hrany které představují vztahy mezi těmito entitami. Protože vrcholy i hrany mohou mít volány další páry název-hodnota vlastnosti, tento datový model je formálně známý jako graf vlastností. Některé databáze grafů vyžadují, abyste definovali a schéma pro váš graf - tj. definování štítky nebo názvy svých vrcholů, hran a vlastností před vyplněním jakýchkoli dat - zatímco jiné databáze vám umožňují pracovat bez pevného schématu.

Jak jste si možná všimli, v datovém modelu grafu nejsou žádné nové informace, které bychom nemohli zachytit v tradičním relačním datovém modelu. Nakonec je snadné popsat vztahy mezi tabulkami pomocí cizích klíčů, nebo můžeme popsat vlastnosti vztahu s tabulkou spojení. Klíčovým rozdílem mezi těmito datovými modely je způsob organizace a přístupu k datům. Rozpoznání hran jako „občana první třídy“ vedle vrcholů v datovém modelu grafu umožňuje základnímu databázovému stroji velmi rychle iterovat v libovolném směru prostřednictvím sítí vrcholů a hran, aby uspokojily aplikační dotazy, což je proces známý jako traverz.

Flexibilita datového modelu grafu je klíčovým faktorem, který řídí nedávný nárůst popularity databáze grafů. Stejné požadavky na dostupnost a masivní rozsah, které vedly k vývoji a přijetí různých nabídek NoSQL za posledních zhruba 10 let, přinášejí ovoce v nedávném trendu grafů.

Jak zjistit, kdy potřebujete databázi grafů

Stejně jako u jakékoli populární technologie však může existovat tendence aplikovat databáze grafů na každý problém. Je důležité se ujistit, že máte vhodný případ použití. Například grafy se často používají na problémové domény, jako jsou:

• Sociální sítě
• Doporučení a personalizace
• Zákazník 360, včetně řešení entit (korelace uživatelských dat z více zdrojů)
• Detekce podvodů
• Správa majetku

Ať už se váš případ použití vejde do jedné z těchto domén nebo ne, je třeba zvážit několik dalších faktorů, které vám pomohou určit, zda je pro vás databáze grafů vhodná:

• Vztahy mnoho k mnoha. Martin Kleppmann ve své knize „Designing Data Intensive Applications“ (O’Reilly) naznačuje, že časté vztahy typu „mnoho k mnoha“ ve vaší problémové doméně jsou dobrým indikátorem pro využití grafů, protože relační databáze mají tendenci se tyto vztahy efektivně orientovat.
• Vysoká hodnota vztahů. Další heuristika, kterou jsem často slyšel: pokud jsou vztahy mezi vašimi datovými prvky stejně důležité nebo důležitější než samotné prvky, měli byste zvážit použití grafu.
• Nízká latence ve velkém měřítku. Přidání další databáze do vaší aplikace také přidá vaší aplikaci složitost. Tato dodatečná složitost je důvodem pro schopnost databází grafů procházet vztahy reprezentovanými ve velkých souborech dat rychleji než jiné typy databází. To platí zejména v případech, kdy složitý relační spojovací dotaz již neprovádí a neexistují žádné další optimalizační zisky, které je třeba provést v dotazu nebo relační struktuře.

Definování schématu grafu a dotazů pomocí Gremlina

Pojďme se podívat na to, jak začít používat databázi grafů pomocí skutečného příkladu, systému doporučení, který jsme nedávno přidali do KillrVideo. KillrVideo je referenční aplikace pro sdílení a sledování videí, kterou jsme vytvořili, abychom vývojářům pomohli naučit se používat DataStax Enterprise, včetně DataStax Enterprise Graph, databáze grafů postavené na vysoce škálovatelných datových technologiích včetně Apache Cassandra a Apache Spark.

Jazyk používaný k popisu a interakci s grafy v DataStax Enterprise Graph je Gremlin, který je součástí projektu Apache TinkerPop. Gremlin je známý jako go-to jazyk pro popis procházení grafů díky své flexibilitě, rozšiřitelnosti a podpoře deklarativních i imperativních dotazů. Gremlin je založen na jazyce Groovy a ovladače jsou k dispozici ve více jazycích. Nejdůležitější je, že Gremlin je podporován nejoblíbenějšími databázemi grafů, včetně DataStax Enterprise Graph, Neo4j, AWS Neptune a Azure Cosmos DB.

Navrhli jsme algoritmus doporučení k identifikaci dat, která bychom potřebovali jako vstup. Přístup spočíval v generování doporučení pro daného uživatele na základě videí, která se podobným uživatelům líbila. Naším cílem bylo generovat doporučení v reálném čase, když uživatelé interagují s aplikací KillrVideo, tj. Jako interakce OLTP.

K definování schématu jsme identifikovali podmnožinu dat spravovaných programem KillrVideo, která jsme potřebovali pro náš graf. To zahrnovalo uživatele, videa, hodnocení a značky, jakož i vlastnosti těchto položek, na které bychom mohli v algoritmu odkazovat nebo je zobrazit ve výsledcích doporučení. Poté jsme v Gremlinu vytvořili schéma grafu, které vypadalo takto:

// vytvoření štítků vrcholů
schema.vertexLabel („uživatel“). partitionKey („userId“).
  vlastnosti („userId“, „email“, „added_date“). ifNotExists (). create ();
schema.vertexLabel („video“). partitionKey („videoId“).
  vlastnosti („videoId“, „name“, „description“, „added_date“,
preview_image_location ”). ifNotExists (). create ();
schema.vertexLabel („značka“). partitionKey („jméno“).
  vlastnosti („name“, „tagged_date“). ifNotExists (). create ();
// vytvoření hranových štítků
schema.edgeLabel („hodnocené“). multiple (). properties („hodnocení“).
  připojení („uživatel“, „video“). ifNotExists (). create ();
schema.edgeLabel („uploaded“). single (). properties („added_date“).
  připojení („uživatel“, „video“). ifNotExists (). create ();
schema.edgeLabel („taggedWith“). single ().
  připojení („video“, „značka“). ifNotExists (). create ();

Rozhodli jsme se modelovat uživatele, videa a značky jako vrcholy a pomocí okrajů jsme určili, kteří uživatelé nahráli která videa, hodnocení videí a značky spojené s každým videem. Přiřadili jsme vlastnosti vrcholům a hranám, na které se odkazuje v dotazech nebo jsou zahrnuty ve výsledcích. Výsledné schéma vypadá takto v DataStax Studio, vývojářském nástroji ve stylu poznámkového bloku pro vývoj a provádění dotazů v CQL a Gremlin.

Na základě tohoto schématu jsme definovali dotazy, které vyplňují data do grafu, a dotazy, které načítají data z grafu. Podívejme se na grafový dotaz, který generuje doporučení. Zde je základní postup: U daného uživatele identifikujte podobné uživatele, kterým se líbila videa, které se danému uživateli líbily, vyberte videa, která se podobným uživatelům také líbila, vyloučte videa, která daný uživatel již sledoval, seřazte tato videa podle popularity a poskytněte výsledky.

def numRatingsToSample = 1000
def localUserRatingsToSample = 10
def minPositiveRating = 4
def ID uživatele = ...
g.V (). has („user“, „userId“, userID) .as („^ currentUser“)
  // zobrazí všechna videa, která uživatel sledoval, a uloží je
  .map (out (‘hodnoceno’). dedup (). fold ()). as („^ sledovaná videa“)
  // návrat k aktuálnímu uživateli
  .select („^ currentUser“)
  // identifikujte videa, která uživatel vysoce hodnotil
  .outE („hodnocené“). má („hodnocení“, gte (minPositiveRating)). inV ()
  // co ostatní uživatelé hodnotili tato videa vysoce?
  .inE („hodnocené“). má („hodnocení“, gte (minPositiveRating))
  // omezit počet výsledků, aby to fungovalo jako OLTP dotaz
  .sample (numRatingsToSample)
  // seřadit podle hodnocení a upřednostnit uživatele, kteří tato videa ohodnotili jako nejvyšší
  .by („rating“). outV ()
  // eliminovat aktuálního uživatele
  .where (neq („^ currentUser“))

Zastavme se na chvíli, abychom popadli dech. Zatím jsme v tomto průchodu identifikovali podobné uživatele. Druhá část procházení vezme tyto podobné uživatele, pořídí omezený počet videí, která se podobným uživatelům líbila, odstraní videa, která uživatel již sledoval, a vygeneruje sadu výsledků seřazenou podle popularity.

  // vyberte omezený počet vysoce hodnocených videí od každého podobného uživatele
   .local (outE („hodnoceno“). má („hodnocení“, gte (minPositiveRating)). limit (localUserRatingsToSample)). sack (přiřadit) .by („hodnocení“). inV ()
  // vyloučit videa, která uživatel již sledoval
  .not (kde (v rámci („^ sledovaných videí“)))
  // identifikujte nejoblíbenější videa podle součtu všech hodnocení
  .group (). by (). by (sack (). sum ())
  // nyní, když máme velkou mapu [video: skóre], objednejte si ji
  .order (local) .by (values, decr) .limit (local, 100). select (keys) .unfold ()
  // výstup doporučených videí včetně uživatele, který nahrál každé video
  .project („video“, „uživatel“)
  .podle()
  .by (__. in („uploaded“))

I když tento přechod vypadá komplikovaně, mějte na paměti, že se jedná o celou obchodní logiku doporučovacího algoritmu. Nebudeme se zde podrobně věnovat každému kroku tohoto průchodu, ale jazyková reference je skvělým zdrojem a jsou k dispozici vysoce kvalitní školicí kurzy.

Doporučuji interaktivně vyvíjet procházení přes reprezentativní datovou sadu pomocí nástroje, jako je DataStax Studio nebo konzole Gremlin od Apache TinkerPop. To vám umožní rychle iterovat a zpřesnit vaše procházení. DataStax Studio je webové prostředí, které poskytuje několik způsobů, jak vizualizovat výsledky procházení jako sítě uzlů a hran, jak je znázorněno na obrázku níže. Mezi další podporovaná zobrazení patří tabulky, grafy a grafy a sledování výkonu.

DataStax

Začlenění databáze grafů do vaší architektury

Jakmile navrhnete své schéma grafu a dotazy, je čas integrovat graf do vaší aplikace. Takto jsme integrovali DataStax Enterprise Graph do KillrVideo. Víceúrovňová architektura KillrVideo se skládá z webové aplikace, která je umístěna nad sadou mikroslužeb, které spravují uživatele, videa (včetně značek) a hodnocení. Tyto služby využívají databázi DataStax Enterprise Graph (postavenou na Apache Cassandra) pro ukládání dat a přístup k datům pomocí CQL.

Náš modul doporučení jsme implementovali jako součást služby Navrhovaná videa, jak je uvedeno níže. Tato služba generuje seznam doporučení s daným ID uživatele. Abychom implementovali modul doporučení, přeložili jsme výše popsaný Gremlinův přechod do kódu Java.

DataStax

Tato architektura zdůrazňuje častou výzvu v architekturách mikroslužeb - nutnost interakce s daty vlastněnými více službami. Jak je uvedeno výše, graf použitý ke generování doporučení závisí na datech ze služeb Správa uživatelů, Katalog videa a Hodnocení.

Zachovali jsme vlastnictví dat našich stávajících služeb pomocí asynchronního zasílání zpráv. Služby Správa uživatelů, Video katalog a Hodnocení publikují události o změnách dat. Služba Navrhovaná videa se přihlásila k odběru těchto událostí a provede odpovídající aktualizace grafu. Kompromisy, které jsme zde provedli, jsou typické pro aplikace, které používají přístup založený na více modelech, což je téma, které jsem prozkoumal ve svém předchozím článku.

Implementace Gremlin traversals v Javě

Ovladač DataStax Java poskytuje přátelské a plynulé rozhraní API pro implementaci Gremlinových přechodů pomocí DataStax Enterprise Graph. API umožnilo triviální migraci dotazů založených na Groovy, které jsme vytvořili v DataStax Studio, do kódu Java.

Poté jsme byli schopni udělat náš kód Java ještě čitelnějším a udržovatelnějším pomocí funkce Gremlin známé jako DSL, jazyky specifické pro doménu. DSL je rozšíření Gremlin do konkrétní domény. Pro KillrVideo jsme vytvořili DSL, abychom rozšířili implementaci Travemeru Gremlin o termíny, které jsou relevantní pro doménu videa. The KillrVideoTraversalDsl třída definuje operace dotazu, jako je user (), který vyhledá vrchol v grafu s poskytnutým UUID, a recommendByUserRating (), který generuje doporučení pro poskytovaného uživatele na základě parametrů, jako je minimální hodnocení a požadovaný počet doporučení.

Použití DSL zjednodušilo implementaci služby Navrhovaná videa na něco jako ukázka níže, která vytvoří GraphStatement které pak provedeme pomocí ovladače Java DataStax Java:

GraphStatement gStatement = DseGraph.statementFromTraversal (killr.users (userIdString)
  .recommendByUserRating (100, 4, 500, 10)
);

Použití DSL nám umožnilo skrýt některé složitosti našich interakcí grafů v opakovaně použitelných funkcích, které lze poté podle potřeby kombinovat a vytvářet složitější procházení. To nám umožní implementovat další motory doporučení, které vycházejí z vrcholu vybraného uživatele poskytovaného uživatel() a umožnit aplikaci přepínat mezi různými implementacemi.

Příklad fungujícího grafu

Výsledky naší integrace DataStax Enterprise Graph do KillrVideo můžete vidět v níže uvedené části „Doporučeno pro vás“ webové aplikace. Vyzkoušejte si to na //www.killrvideo.com vytvořením účtu a hodnocením několika videí.

DataStax

Doufám, že tento článek vám poskytne několik skvělých nápadů, jak může mít databáze grafů smysl pro vaši aplikaci a jak začít s Gremlin a DataStax Enterprise Graph.

Jeff Carpenter je technickým evangelistou ve společnosti DataStax, kde využívá své pozadí v systémové architektuře, mikroslužbách a Apache Cassandra, aby pomohl vývojářům a provozním technikům postavit distribuované systémy, které jsou škálovatelné, spolehlivé a bezpečné. Jeff je autorem knihy Cassandra: The Definitive Guide, 2. vydání.

—

Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na adresu[email protected].