Pred dvadsiatimi rokmi môj vývojový tím vytvoril stroj na spracovanie prirodzeného jazyka, ktorý skenoval inzeráty týkajúce sa zamestnania, automobilov a nehnuteľností pre vyhľadávateľné kategórie. Vedel som, že máme náročnú výzvu v oblasti správy údajov. Údaje v niektorých typoch reklám boli pomerne priame, ako napríklad identifikácia značiek a modelov automobilov, iné si však vyžadovali viac záverov, napríklad identifikáciu kategórie práce na základe zoznamu zručností.
Vyvinuli sme model metadát, ktorý zachytil všetky hľadateľné výrazy, ale motor na spracovanie prirodzeného jazyka vyžadoval, aby model odhalil významné vzťahy metadát. Vedeli sme, že návrh modelu metadát s ľubovoľnými spojeniami medzi údajovými bodmi v relačnej databáze bol zložitý, a preto sme na správu modelu preskúmali použitie objektových databáz.
To, čo sme sa vtedy snažili dosiahnuť pomocou databáz objektov, je dnes možné dosiahnuť lepšie pomocou databáz grafov. Databázy grafov ukladajú informácie ako uzly a údaje špecifikujúce ich vzťahy s ostatnými uzlami. Sú osvedčenou architektúrou na ukladanie údajov so zložitými vzťahmi.
Využitie databázy grafov za posledné desaťročie určite vzrástlo, pretože spoločnosti uvažovali o iných technológiách NoSQL a big data. Globálny trh s databázami grafov sa v roku 2018 odhadoval na 651 miliónov dolárov a predpokladá sa, že do roku 2026 vzrastie na 3,73 miliárd dolárov. Mnoho ďalších technológií na správu veľkých dát, napríklad Hadoop, Spark a ďalších, však zaznamenalo oveľa výraznejší rast popularity, osvojenia zručností, a výrobné prípady použitia v porovnaní s databázami grafov. Pre porovnanie, veľkosť trhu s veľkými dátovými technológiami sa v roku 2018 odhadovala na 36,8 miliárd dolárov a predpokladá sa, že do roku 2026 vzrastie na 104,3 miliárd dolárov.
Chcel som pochopiť, prečo viac organizácií neuvažuje o databázach grafov. Vývojári myslia na objekty a pravidelne používajú hierarchické reprezentácie údajov v XML a JSON. Technológovia a obchodné zainteresované subjekty grafom skutočne rozumejú, pretože internet je vzájomne prepojeným grafom prostredníctvom hypertextových odkazov a konceptov, ako sú priatelia a priatelia priateľov zo sociálnych sietí. Prečo potom nepoužilo viac vývojových tímov vo svojich aplikáciách databázy grafov?
Naučiť sa dopytovacie jazyky databáz grafov
Aj keď môže byť pomerne ľahké pochopiť modelovanie uzlov a vzťahov použitých v databázach grafov, ich dopytovanie si vyžaduje osvojenie nových postupov a zručností.
Pozrime sa na tento príklad výpočtu zoznamu priateľov a priateľov priateľov. Pred pätnástimi rokmi som spoluzakladal cestovnú sociálnu sieť a rozhodol som sa zachovať jednoduchosť dátového modelu ukladaním všetkého do MySQL. Tabuľka, v ktorej je uložený zoznam používateľov, sa sama pripojila, aby zastupovala priateľov, a išlo o pomerne jednoduchý dotaz na extrahovanie zoznamu priateľov. Ale dostať sa k priateľovi zo zoznamu priateľov si vyžadovalo príšerne zložitý dotaz, ktorý síce fungoval, ale nepodával dobrý výkon, keď mali používatelia rozšírené siete.
Hovoril som s Jimom Webberom, hlavným vedcom spoločnosti Neo4j, jednej zo zavedených dostupných databáz grafov, o tom, ako vytvoriť dopyt priateľov. Vývojári môžu dopytovať databázy grafov Neo4j pomocou RDF (Resource Description Framework) a Gremlin, ale Webber mi povedal, že viac ako 90 percent zákazníkov používa Cypher. Takto vyzerá dopyt v službe Cypher na extrakciu priateľov a priateľov priateľov:
ZÁPAS (ja: Osoba {meno: 'Rosa'}) - [: FRIEND * 1..2] -> (f: Osoba)
KDE ma f
NÁVRAT f
Tu je príklad, ako porozumieť tomuto dotazu:
- Nájdite mi vzor, kde je uzol so štítkom Osoba a názvom vlastnosti: „Rosa“, a spojte ho s premennou „ja“. Dotaz špecifikuje, že „me“ má odchádzajúci priateľský vzťah v hĺbke 1 alebo 2 k akémukoľvek inému uzlu s menovkou Person a viaže tieto zhody na premennú „f“.
- Uistite sa, že „ja“ sa nerovná „f“, pretože som priateľ svojich priateľov!
- Vráťte všetkých priateľov a priateľov priateľov
Dotaz je elegantný a efektívny, ale má krivku učenia pre tých, ktorí sa používajú na písanie dotazov SQL. V tom spočíva prvá výzva pre organizácie, ktoré prechádzajú k databázam grafov: SQL je všadeprítomná sada zručností a Cypher a ďalšie jazyky na vyhľadávanie grafov sú novou zručnosťou, ktorú sa treba naučiť.
Navrhovanie flexibilných hierarchií s databázami grafov
Katalógy výrobkov, systémy na správu obsahu, aplikácie na riadenie projektov, ERP a CRM, všetky používajú hierarchie na kategorizáciu a označovanie informácií. Problém samozrejme spočíva v tom, že niektoré informácie nie sú skutočne hierarchické a predmety musia vytvoriť konzistentný prístup k štruktúrovaniu informačnej architektúry. Môže to byť bolestivý proces, najmä ak sa vedie interná debata o štruktúrovaní informácií, alebo keď koncoví používatelia aplikácií nenájdu informácie, ktoré hľadajú, pretože sú v inej časti hierarchie.
Databázy grafov umožňujú nielen ľubovoľné hierarchie, ale tiež umožňujú vývojárom vytvárať rôzne pohľady na hierarchiu pre rôzne potreby. Napríklad tento článok o databázach grafov sa môže zobraziť v hierarchiách v systéme správy obsahu pre správu údajov, objavujúce sa technológie, odvetvia, ktoré pravdepodobne používajú databázy grafov, bežné prípady použitia databáz grafov alebo podľa technologických rolí. Nástroj odporúčaní má potom oveľa bohatšiu množinu údajov, aby zodpovedal obsahu záujmom používateľov.
Hovoril som s Markom Kluszom, spoluzakladateľom spoločnosti Construxiv, spoločnosti zaoberajúcej sa predajom technológií pre stavebný priemysel, vrátane Grit, platformy pre plánovanie stavieb. Ak sa pozriete na harmonogram projektu komerčnej výstavby, uvidíte odkazy na rôzne remeslá, vybavenie, diely a referencie na modely. Jeden pracovný balík môže mať v pláne projektu ľahko stovky úloh so závislosťami. Tieto plány musia integrovať údaje z ERP, informačných modelov budov a ďalších projektových plánov a predkladať pohľady plánovačom, projektovým manažérom a subdodávateľom. Klusza vysvetlil: „Použitím databázy grafov v Grite vytvárame oveľa bohatšie vzťahy o tom, kto čo robí, kedy, kde, s akým vybavením a s akými materiálmi. To nám umožňuje prispôsobiť pohľady a lepšie predvídať konflikty plánovania úloh. “
Ak chcete využiť výhody flexibilných hierarchií, pomáha vám od základu navrhovať aplikácie pomocou databázy grafov. Celá aplikácia je potom navrhnutá na základe dopytovania po grafe a využívania uzlov, vzťahov, označení a vlastností grafu.
Možnosti nasadenia v cloude znižujú prevádzkovú zložitosť
Nasadenie riešení na správu údajov do dátového centra nie je maličkosti. Infraštruktúra a prevádzka musia zohľadňovať bezpečnostné požiadavky; skontrolovať aspekty výkonu pri zväčšovaní serverov, úložných priestorov a sietí; a tiež uviesť do prevádzky replikované systémy na zotavenie po katastrofe.
Organizácie experimentujúce s databázami grafov majú teraz niekoľko možností cloudu. Inžinieri môžu nasadiť Neo4j na GCP, AWS, Azure alebo využiť Neo4j’s Aura, databázu ako službu. TigerGraph má cloudovú ponuku a štartovacie sady pre prípady použitia, ako je zákazník 360, detekcia podvodov, vyhľadávače odporúčaní, analýza sociálnych sietí a analýza dodávateľského reťazca. Verejní cloudoví dodávatelia majú tiež možnosti databázy grafov, vrátane AWS Neptune, Gremlin API v Azure CosmoDB, open source JanusGraph v GCP alebo funkcie grafov v Oracle Database Database Services.
Vraciam sa k svojej pôvodnej otázke. Prečo so všetkými zaujímavými prípadmi použitia, vyspelými platformami databáz grafov, možnosťami vývoja grafových databáz a možnosťami nasadenia v cloude, prečo viac technologických organizácií nevyužíva databázy grafov?
