Programování

Proč by vývojáři měli používat databáze grafů

Před dvaceti lety můj vývojový tým vytvořil stroj pro zpracování přirozeného jazyka, který skenoval inzeráty na zaměstnání, auto a nemovitosti pro vyhledatelné kategorie. Věděl jsem, že máme náročnou výzvu pro správu dat. Data v některých typech reklam byla relativně přímá, jako je identifikace značek a modelů automobilů, ale jiné vyžadovaly více inferencí, například identifikaci kategorie práce na základě seznamu dovedností.

Vyvinuli jsme model metadat, který zachytil všechny prohledávatelné výrazy, ale motor pro zpracování přirozeného jazyka vyžadoval, aby model odhalil významné vztahy metadat. Věděli jsme, že návrh modelu metadat s libovolnými spoji mezi datovými body v relační databázi je složitý, a proto jsme zkoumali použití objektových databází ke správě modelu.

To, čeho jsme se tehdy snažili dosáhnout pomocí databází objektů, lze dnes lépe dosáhnout pomocí databází grafů. Databáze grafů ukládají informace jako uzly a data specifikující jejich vztahy s ostatními uzly. Jsou to osvědčené architektury pro ukládání dat se složitými vztahy.

Využití databáze grafů v posledním desetiletí jistě vzrostlo, protože společnosti uvažovaly o jiných technologiích NoSQL a big data. Globální trh s databázemi grafů byl v roce 2018 odhadován na 651 milionů USD a podle předpovědí by měl do roku 2026 růst na 3,73 miliardy USD. Mnoho dalších velkých technologií pro správu dat, včetně Hadoop, Spark a dalších, však zaznamenalo mnohem výraznější růst popularity, přijetí dovedností, a případy použití produkce ve srovnání s databázemi grafů. Pro srovnání, velikost trhu s velkými datovými technologiemi byla v roce 2018 odhadována na 36,8 miliard USD a podle předpovědi by měla do roku 2026 růst na 104,3 miliardy USD.

Chtěl jsem pochopit, proč více organizací neuvažuje o databázích grafů. Vývojáři přemýšlejí o objektech a pravidelně používají hierarchické reprezentace dat v XML a JSON. Technologové a obchodní partneři grafům skutečně rozumějí, protože internet je propojený graf prostřednictvím hypertextových odkazů a konceptů, jako jsou přátelé a přátelé přátel ze sociálních sítí. Proč tedy ve svých aplikacích nepoužilo více vývojových týmů databáze grafů?

Učení dotazovacích jazyků databází grafů

Ačkoli může být relativně snadné pochopit modelování uzlů a vztahů používaných v databázích grafů, jejich dotazování vyžaduje osvojení nových postupů a dovedností.

Podívejme se na tento příklad výpočtu seznamu přátel a přátel přátel. Před patnácti lety jsem spoluzaložil cestovní sociální síť a rozhodl jsem se zachovat jednoduchý datový model ukládáním všeho do MySQL. Tabulka, ve které je uložen seznam uživatelů, se sama připojila, aby zastupovala přátele, a byl to poměrně přímý dotaz na extrahování seznamu přátel. Získání přítele ze seznamu přátel však vyžadovalo obludně složitý dotaz, který fungoval, ale neuspěl dobře, když uživatelé měli rozšířené sítě.

Mluvil jsem s Jimem Webberem, hlavním vědeckým pracovníkem Neo4j, jedné ze zavedených databází grafů, o tom, jak vytvořit dotaz přátel přátel. Vývojáři mohou dotazovat na databáze grafů Neo4j pomocí RDF (Resource Description Framework) a Gremlin, ale Webber mi řekl, že více než 90 procent zákazníků používá Cypher. Takto vypadá dotaz v Cypheru na extrakci přátel a přátel přátel:

MATCH (me: Person {name: 'Rosa'}) - [: FRIEND * 1..2] -> (f: Person)

KDE mě f

NÁVRAT f

Tomuto dotazu porozumíte takto:

  • Najděte mi vzor, ​​kde je uzel se štítkem Osoba a názvem vlastnosti: „Rosa“, a vytvořte vazbu s proměnnou „já“. Dotaz určuje, že „já“ má odchozí PŘÁTELSKÝ vztah v hloubce 1 nebo 2 k jakémukoli jinému uzlu se štítkem Person a váže tyto shody na proměnnou „f“.
  • Ujistěte se, že „já“ není rovno „f“, protože jsem přítel mých přátel!
  • Vraťte všechny přátele a přátele přátel

Dotaz je elegantní a efektivní, ale má křivku učení pro ty, kteří se používají k psaní dotazů SQL. V tom spočívá první výzva pro organizace směřující k databázím grafů: SQL je všudypřítomná sada dovedností a Cypher a další jazyky dotazů na grafy jsou novou dovedností, kterou se lze naučit.

Navrhování flexibilních hierarchií s databázemi grafů

Katalogy produktů, systémy pro správu obsahu, aplikace pro řízení projektů, ERP a CRM - všechny používají hierarchie ke kategorizaci a označování informací. Problém samozřejmě spočívá v tom, že některé informace nejsou skutečně hierarchické a předměty musí vytvářet konzistentní přístup ke strukturování informační architektury. To může být bolestivý proces, zvláště pokud existuje interní debata o strukturování informací, nebo když koncoví uživatelé aplikace nemohou najít informace, které hledají, protože jsou v jiné části hierarchie.

Databáze grafů nejen umožňují libovolné hierarchie, ale také umožňují vývojářům vytvářet různé pohledy na hierarchii pro různé potřeby. Například tento článek o databázích grafů se může zobrazit v hierarchiích v systému správy obsahu pro správu dat, nově vznikající technologie, průmyslová odvětví, která pravděpodobně používají databáze grafů, běžné případy použití databáze grafů nebo podle technologických rolí. Nástroj doporučení pak má mnohem bohatší sadu dat, aby odpovídal obsahu a zájmu uživatelů.

Mluvil jsem s Markem Kluszou, spoluzakladatelem společnosti Construxiv, společnosti prodávající technologie pro stavební průmysl, včetně Grit, platformy pro plánování výstavby. Pokud se podíváte na harmonogram komerčního stavebního projektu, uvidíte odkazy na více obchodů, vybavení, dílů a referencí na modely. Jeden pracovní balíček může snadno obsahovat stovky úkolů se závislostmi v plánu projektu. Tyto plány musí integrovat data z ERP, Building Information Modeling a dalších plánů projektu a představovat pohledy plánovačům, projektovým manažerům a subdodavatelům. Klusza vysvětlil: „Použitím databáze grafů v Gritu vytváříme mnohem bohatší vztahy o tom, kdo co dělá, kdy, kde, s jakým vybavením a s jakými materiály. To nám umožňuje lépe přizpůsobit pohledy a lépe předvídat konflikty plánování úloh. “

Chcete-li využít výhod flexibilních hierarchií, pomáhá vám od základu navrhovat aplikace pomocí databáze grafů. Celá aplikace je poté navržena na základě dotazování na graf a využití uzlů, vztahů, popisků a vlastností grafu.

Možnosti nasazení v cloudu snižují provozní složitost

Nasazení řešení pro správu dat do datového centra není triviální. Infrastruktura a provoz musí zohledňovat bezpečnostní požadavky; zkontrolovat aspekty výkonu pro zvětšení velikosti serverů, úložišť a sítí; a také zprovoznit replikované systémy pro zotavení po katastrofě.

Organizace experimentující s databázemi grafů nyní mají několik možností cloudu. Inženýři mohou nasadit Neo4j do GCP, AWS, Azure nebo využít Neo4j's Aura, databázi jako službu. TigerGraph má cloudovou nabídku a startovací sady pro případy použití, jako je zákazník 360, detekce podvodů, motory doporučení, analýza sociálních sítí a analýza dodavatelského řetězce. Dodavatelé veřejného cloudu mají také možnosti databází grafů, včetně AWS Neptune, rozhraní Gremlin API v Azure CosmoDB, open source JanusGraph v GCP nebo funkce grafů v cloudových databázových službách Oracle.

Vracím se ke své původní otázce. Proč všechny nejzajímavější případy použití, vyspělé platformy databází grafů, možnosti naučit se vývoj databází grafů a možnosti nasazení v cloudu, proč nepoužívají více databází grafů?