Programmēšana

Kāpēc izstrādātājiem jāizmanto diagrammu datu bāzes

Pirms divdesmit gadiem mana izstrādes komanda izveidoja dabiskās valodas apstrādes motoru, kas skenēja nodarbinātības, auto un nekustamā īpašuma sludinājumus meklējamām kategorijām. Es zināju, ka mums ir grūta datu pārvaldības problēma. Dažu veidu reklāmās dati bija salīdzinoši vienkārši, piemēram, automašīnu marku un modeļu identificēšana, bet citiem bija nepieciešams lielāks secinājums, piemēram, darba kategorijas noteikšana, pamatojoties uz prasmju sarakstu.

Mēs izstrādājām metadatu modeli, kas aptvēra visus meklēšanas vaicājumus, taču dabiskās valodas apstrādes dzinējs pieprasīja, lai modelis atklātu nozīmīgas metadatu attiecības. Mēs zinājām, ka metadatu modeļa projektēšana ar patvaļīgiem savienojumiem starp datu punktiem relāciju datu bāzē bija sarežģīta, tāpēc mēs izpētījām, kā modeļa pārvaldībai izmantot objektu datu bāzes.

To, ko mēs toreiz centāmies paveikt ar objektu datu bāzēm, šodien labāk var izdarīt ar grafu datu bāzēm. Grafiku datu bāzēs informācija tiek glabāta kā mezgli un dati, kas norāda to attiecības ar citiem mezgliem. Tās ir pārbaudītas arhitektūras datu glabāšanai ar sarežģītām attiecībām.

Grafiku datu bāzes izmantojums pēdējās desmitgades laikā noteikti ir pieaudzis, uzņēmumiem ņemot vērā citas NoSQL un lielo datu tehnoloģijas. Tiek lēsts, ka pasaules grafiku datu bāzes tirgus 2018. gadā bija 651 miljons ASV dolāru, un tika prognozēts, ka līdz 2026. gadam tas pieaugs līdz 3,73 miljardiem ASV dolāru. Bet daudzās citās lielo datu pārvaldības tehnoloģijās, tostarp Hadoop, Spark un citās, ir novērojams daudz ievērojamāks popularitātes pieaugums, prasmju pārņemšana, un ražošanas izmantošanas gadījumi, salīdzinot ar grafu datu bāzēm. Salīdzinājumam: lielo datu tehnoloģiju tirgus lielums 2018. gadā tika lēsts 36,8 miljardu ASV dolāru apmērā un tika prognozēts, ka līdz 2026. gadam tas pieaugs līdz 104,3 miljardiem ASV dolāru.

Es gribēju saprast, kāpēc vairāk organizāciju neuzskata grafiku datu bāzes. Izstrādātāji domā objektos un regulāri izmanto hierarhijas datu attēlojumus XML un JSON. Tehnologi un biznesa interesenti grafikus saprot, jo internets ir savstarpēji saistīts grafiks, izmantojot hipersaites un tādus jēdzienus kā draugi un draugu draugi no sociālajiem tīkliem. Tad kāpēc vairāk izstrādātāju komandu savās lietojumprogrammās nav izmantojuši grafu datu bāzes?

Grafu datu bāzu vaicājumu valodu apguve

Lai gan var būt samērā viegli saprast diagrammu datu bāzēs izmantoto mezglu un attiecību modelēšanu, vaicājot par tām, ir jāapgūst jauna prakse un prasmes.

Apskatīsim šo draugu un draugu draugu saraksta aprēķināšanas piemēru. Pirms piecpadsmit gadiem es nodibināju ceļojumu sociālo tīklu un nolēmu saglabāt datu modeli vienkāršu, visu saglabājot MySQL. Tabulai, kurā glabājas lietotāju saraksts, bija pašpievienošanās, lai pārstāvētu draugus, un draugu saraksta izvilkšana bija samērā vienkārša vaicājums. Bet, lai nokļūtu drauga saraksta draugā, bija nepieciešams ļoti sarežģīts vaicājums, kas darbojās, bet nedarbojās labi, ja lietotājiem bija paplašināti tīkli.

Par to, kā izveidot draugu draugu vaicājumu, es runāju ar Džimu Vēberu, Neo4j, vienas no izveidotajām diagrammu datu bāzēm, galveno zinātnieku. Izstrādātāji var veikt vaicājumus Neo4j diagrammu datu bāzēs, izmantojot RDF (Resource Description Framework) un Gremlin, taču Vēbers man teica, ka vairāk nekā 90 procenti klientu izmanto Cypher. Lūk, kā izskatās vaicājums vietnē Cypher par draugu un draugu iegūšanu:

MATCH (es: Persona {vārds: 'Rosa'}) - [: DRAUGS * 1..2] -> (f: Persona)

KUR es f

ATGRIEZTIES f

Lai saprastu šo vaicājumu, rīkojieties šādi:

  • Atrodiet man modeli, kur ir mezgls ar apzīmējumu Persona un rekvizīta nosaukums: “Rosa”, un piesaistiet to mainīgajam “es”. Vaicājums norāda, ka “man” ir izejošās DRAUGA attiecības 1. vai 2. dziļumā ar jebkuru citu mezglu ar etiķeti Persona, un šīs atbilstības sasaista ar mainīgo “f”.
  • Pārliecinieties, ka “es” nav vienāds ar “f”, jo esmu draugu draugs!
  • Atgrieziet visus draugus un draugu draugus

Vaicājums ir elegants un efektīvs, taču tam ir mācīšanās līkne tiem, kas pieraduši rakstīt SQL vaicājumus. Tajā slēpjas pirmais izaicinājums organizācijām, kas virzās uz diagrammu datu bāzēm: SQL ir visaptveroša prasmju kopa, un Cypher un citas diagrammu vaicājumu valodas ir jauna prasme, kas jāapgūst.

Elastīgu hierarhiju projektēšana ar grafu datu bāzēm

Produktu katalogi, satura pārvaldības sistēmas, projektu vadības lietojumprogrammas, ERP un CRM izmanto hierarhijas informācijas kategorizēšanai un marķēšanai. Protams, problēma ir tā, ka daļa informācijas nav īsti hierarhiska, un priekšmetiem ir jāizveido konsekventa pieeja informācijas arhitektūras strukturēšanai. Tas var būt sāpīgs process, it īpaši, ja notiek iekšējas debates par informācijas strukturēšanu vai kad lietojumprogrammas lietotāji nevar atrast meklēto informāciju, jo tā atrodas citā hierarhijas daļā.

Grafu datu bāzes ne tikai ļauj patvaļīgas hierarhijas, bet arī ļauj izstrādātājiem izveidot dažādus hierarhijas skatus dažādām vajadzībām. Piemēram, šis raksts par diagrammu datu bāzēm var tikt parādīts hierarhijās satura pārvaldības sistēmā datu pārvaldībai, jaunām tehnoloģijām, nozarēm, kuras, visticamāk, izmantos diagrammu datu bāzes, parastos diagrammu datu bāzes lietošanas gadījumos vai pēc tehnoloģiju lomām. Pēc tam ieteikumu motoram ir daudz bagātāks datu kopums, lai saturs atbilstu lietotāju interesēm.

Es runāju ar Marku Kluszu, uzņēmuma Construxiv līdzdibinātāju, kas pārdod tehnoloģijas būvniecības nozarei, ieskaitot būvniecības plānošanas platformu Grit. Apskatot komerciālā būvniecības projekta grafiku, jūs redzēsiet atsauces uz vairākiem darījumiem, aprīkojumu, detaļām un atsauces uz modeļiem. Vienā darba paketē var viegli būt simtiem uzdevumu ar atkarību no projekta plāna. Šajos plānos jāintegrē dati no ERP, Ēku informācijas modelēšanas un citiem projekta plāniem, kā arī jāsniedz skati plānotājiem, projektu vadītājiem un apakšuzņēmējiem. Klusza paskaidroja: “Izmantojot grafu datu bāzi Grit, mēs izveidojam daudz bagātākas attiecības par to, kas ko dara, kad, kur, ar kādu aprīkojumu un ar kādiem materiāliem. Tas mums ļauj personalizēt skatus un labāk prognozēt darba plānošanas konfliktus. ”

Lai izmantotu elastīgo hierarhiju priekšrocības, tas palīdz noformēt lietojumprogrammas jau no paša sākuma, izmantojot diagrammu datu bāzi. Tad visa lietojumprogramma tiek veidota, pamatojoties uz vaicājumiem diagrammā un diagrammas mezglu, attiecību, iezīmju un īpašību izmantošanu.

Mākoņa izvietošanas iespējas samazina darbības sarežģītību

Datu pārvaldības risinājumu izvietošana datu centrā nav mazsvarīga. Infrastruktūrā un darbībās jāņem vērā drošības prasības; pārskatīt veiktspējas apsvērumus, lai palielinātu serverus, krātuves un tīklus; un arī operativizēt atkārtotas sistēmas katastrofu seku novēršanai.

Organizācijām, kas eksperimentē ar diagrammu datu bāzēm, tagad ir vairākas mākoņa iespējas. Inženieri var izvietot Neo4j GCP, AWS, Azure vai izmantot pakalpojumu Neo4j’s Aura, datu bāzi. TigerGraph ir mākoņu piedāvājums un sākuma komplekti tādiem lietošanas gadījumiem kā klients 360, krāpšanas atklāšana, ieteikumu motori, sociālo tīklu analīze un piegādes ķēdes analīze. Tāpat publiskajiem mākoņu piegādātājiem ir grafu datu bāzes iespējas, tostarp AWS Neptune, Gremlin API Azure's CosmoDB, atvērtā koda JanusGraph GCP vai Oracle Cloud Database Services diagrammu funkcijas.

Es atgriežos pie sava sākotnējā jautājuma. Ņemot vērā visus interesantos izmantošanas gadījumus, pieejamās nobriedušu grafu datu bāzes platformas, iespējas uzzināt grafu datu bāzes izstrādi un mākoņa izvietošanas iespējas, kāpēc vairāk tehnoloģiju organizāciju neizmanto grafu datu bāzes?

$config[zx-auto] not found$config[zx-overlay] not found