Kaksikymmentä vuotta sitten kehitystiimini rakensi luonnollisen kielenkäsittelykoneen, joka skannasi työ-, auto- ja kiinteistömainoksia haettaville luokille. Tiesin, että meillä oli vaikea tiedonhallintahaaste. Joidenkin mainostyyppien tiedot olivat suhteellisen suoraviivaisia, kuten automerkkien ja -mallien tunnistaminen, mutta toiset vaativat enemmän päätelmiä, kuten työpaikkaluokan tunnistaminen taitoluettelon perusteella.
Kehitimme metatietomallin, joka sieppasi kaikki haettavat termit, mutta luonnollinen kielenkäsittelymoottori vaati mallia paljastamaan merkittävät metatietosuhteet. Tiesimme, että metatietomallin suunnittelu mielivaltaisilla yhteyksillä relaatiotietokannan datapisteiden välillä oli monimutkaista, joten tutkimme mallin hallintaa objektitietokantojen avulla.
Se mitä yritimme saavuttaa silloin objektitietokannoilla, voidaan tehdä paremmin tänään graafitietokannoilla. Kaaviotietokannat tallentavat tietoja solmuina ja tietoja, jotka määrittelevät niiden suhteet muihin solmuihin. Ne ovat todistettuja arkkitehtuureja monimutkaisten suhteiden tietojen tallentamiseen.
Kuvaajatietokantojen käyttö on varmasti kasvanut viimeisen vuosikymmenen aikana, kun yritykset harkitsivat muita NoSQL- ja big data -tekniikoita. Grafiikkatietokannan maailmanmarkkinoiden arvioitiin olevan 651 miljoonaa dollaria vuonna 2018 ja niiden ennustettiin kasvavan 3,73 miljardiin dollariin vuoteen 2026 mennessä. Mutta monien muiden suurten tiedonhallintatekniikoiden, kuten Hadoop, Spark ja muut, suosio, taitojen omaksuminen ovat kasvaneet huomattavasti. ja tuotannon käyttötapaukset verrattuna graafitietokantoihin. Vertailun vuoksi suurten tietotekniikkamarkkinoiden koon arvioitiin olevan 36,8 miljardia dollaria vuonna 2018 ja sen ennustettiin kasvavan 104,3 miljardiin dollariin vuoteen 2026 mennessä.
Halusin ymmärtää, miksi useampi organisaatio ei harkitse graafitietokantoja. Kehittäjät ajattelevat objekteissa ja käyttävät hierarkkisia dataesityksiä XML: ssä ja JSON: ssa säännöllisesti. Teknologit ja liike-elämän sidosryhmät ymmärtävät kaavioita luonnostaan, koska Internet on yhdistetty kaavio hyperlinkkien ja käsitteiden, kuten ystävien ja ystävien ystävien kautta sosiaalisista verkostoista, kautta. Miksi siis useammat kehitystiimit eivät ole käyttäneet graafitietokantoja sovelluksissaan?
Kuvaajatietokantojen kyselykielten oppiminen
Vaikka kuvaajatietokannoissa käytettyjen solmujen ja suhteiden mallintaminen voi olla suhteellisen helppoa, niiden kysely vaatii uusien käytäntöjen ja taitojen oppimista.
Katsotaanpa tätä esimerkkiä ystäväluettelon laskemisesta. Viisitoista vuotta sitten perustin matkailualan sosiaalisen verkoston ja päätin pitää tietomallin yksinkertaisena tallentamalla kaiken MySQL: ään. Käyttäjäluettelon sisältävällä taulukolla oli oma liittymä edustamaan ystäviä, ja ystäväluettelon poimiminen oli suhteellisen yksinkertainen kysely. Mutta kaverilistan ystäväni saaminen vaati hirvittävän monimutkaisen kyselyn, joka toimi, mutta ei toiminut hyvin, kun käyttäjillä oli laajennettu verkko.
Keskustelin Neo4j: n, joka on yksi vakiintuneista käytettävissä olevista kaaviotietokannoista, johtavan tutkijan Jim Webberin kanssa siitä, miten voit luoda ystävien ystävien kyselyn. Kehittäjät voivat tehdä kyselyjä Neo4j-graafitietokannoista RDF: n (Resource Description Framework) ja Gremlinin avulla, mutta Webber kertoi minulle, että yli 90 prosenttia asiakkaista käyttää Cypheriä. Cypherissä kysely ystävien ja ystävien poimimisesta näyttää tältä:
MATCH (minä: Henkilö {nimi: 'Rosa'}) - [: YSTÄVÄ * 1..2] -> (f: Henkilö)
Missä minä f
PALAUTA f
Näin ymmärrät tämän kyselyn:
- Etsi minulle malli, jossa on solmu, jossa on tunniste Henkilö ja ominaisuuden nimi: 'Rosa', ja sido se muuttujaan "minä". Kysely määrittää, että "minulla" on lähtevä FRIEND-suhde syvyydessä 1 tai 2 mihin tahansa muuhun solmuun, jolla on Henkilötunniste, ja se sitoo kyseiset ottelut muuttujaan "f".
- Varmista, että "minä" ei ole sama kuin "f", koska olen ystävieni ystävä!
- Palauta kaikki ystävät ja ystävät
Kysely on tyylikäs ja tehokas, mutta sillä on oppimiskäyrä niille, jotka ovat tottuneet kirjoittamaan SQL-kyselyjä. Siinä on ensimmäinen haaste organisaatioille, jotka liikkuvat kohti kaaviotietokantoja: SQL on laaja taitojoukko, ja Cypher ja muut kaavakyselykielet ovat uusi taito oppia.
Joustavien hierarkioiden suunnittelu graafitietokannoilla
Tuoteluettelot, sisällönhallintajärjestelmät, projektinhallintasovellukset, ERP: t ja CRM: t käyttävät kaikki hierarkioita tietojen luokittelemiseen ja merkitsemiseen. Ongelmana on tietysti se, että osa tiedoista ei ole todella hierarkkista, ja aiheiden on luotava johdonmukainen lähestymistapa tietorakenteen rakenteeseen. Se voi olla tuskallinen prosessi, varsinkin jos tietojen jäsentämisestä käydään sisäistä keskustelua tai kun sovelluksen loppukäyttäjät eivät löydä hakemiaan tietoja, koska ne ovat hierarkian eri osissa.
Paitsi että graafitietokannat mahdollistavat mielivaltaiset hierarkiat, niiden avulla kehittäjät voivat myös luoda erilaisia näkymiä hierarkiasta erilaisiin tarpeisiin. Esimerkiksi tämä kaaviotietokantoja koskeva artikkeli saattaa näkyä sisällönhallintajärjestelmän hierarkioissa tiedonhallinnassa, uusissa tekniikoissa, teollisuudessa, jotka todennäköisesti käyttävät kaaviotietokantoja, yleisiä kaaviotietokantojen käyttötapauksia tai tekniikkaroolien mukaan. Suositusmoottorissa on sitten paljon rikkaampi datajoukko, jotta sisältö sovitetaan käyttäjän kiinnostuksen kohteisiin.
Puhuin Mark Kluszan kanssa, joka on Construxivin perustajayritys, joka myy teknologiaa rakennusalalle, mukaan lukien Grit, rakentamisen aikataulutusalusta. Jos tarkastelet kaupallisen rakennushankkeen aikataulua, näet viittauksia useisiin kauppoihin, laitteisiin, osiin ja malliviitteisiin. Yhdessä työpaketissa voi helposti olla satoja tehtäviä, joiden riippuvuudet sisältyvät projektisuunnitelmaan. Näihin suunnitelmiin on integroitava tiedot toiminnanohjausohjelmista, rakennustietomallinnuksesta ja muista projektisuunnitelmista ja esitettävä näkemykset aikatauluttajille, projektipäälliköille ja alihankkijoille. Klusza selitti: "Käyttämällä graafitietokantaa Gritissä luomme paljon rikkaammat suhteet siihen, kuka tekee mitä, milloin, missä, millä laitteilla ja millä materiaaleilla. Tämä antaa meille mahdollisuuden mukauttaa näkymiä ja ennustaa työn aikatauluristiriidat paremmin. "
Joustavien hierarkioiden hyödyntämiseksi se auttaa suunnittelemaan sovelluksia alusta alkaen graafitietokannan avulla. Sitten koko sovellus suunnitellaan graafin kyselyyn ja kaavion solmujen, suhteiden, tunnisteiden ja ominaisuuksien hyödyntämiseen.
Pilviasennusvaihtoehdot vähentävät toiminnallista monimutkaisuutta
Tiedonhallintaratkaisujen käyttöönotto datakeskukseen ei ole triviaalia. Infrastruktuurin ja toiminnan on otettava huomioon turvallisuusvaatimukset; tarkastella suorituskykyä koskevia näkökohtia palvelinten, tallennustilan ja verkkojen koon lisäämiseksi; ja myös ottaa käyttöön toisinnetut järjestelmät hätäpalautumista varten.
Graafitietokantoihin kokeilevilla organisaatioilla on nyt useita pilvivaihtoehtoja. Insinöörit voivat ottaa Neo4j: n käyttöön GCP: ssä, AWS: ssä, Azuressa tai hyödyntää Neo4j: n Auraa, tietokantaa palveluna. TigerGraphilla on pilvitarjonta ja aloituspaketit käyttötapauksiin, kuten asiakas 360, petosten havaitseminen, suositusmoottorit, sosiaalisen verkoston analyysi ja toimitusketjun analyysi. Julkisilla pilvipalvelujen toimittajilla on myös graafitietokantaominaisuudet, mukaan lukien AWS Neptune, Gremlin-sovellusliittymä Azuren CosmoDB: ssä, avoimen lähdekoodin JanusGraph GCP: ssä tai kaavio-ominaisuudet Oraclen Cloud Database Services -palvelussa.
Palaan alkuperäiseen kysymykseeni. Kaikkien mielenkiintoisten käyttötapausten, kypsien graafitietokanta-alustojen, mahdollisuuksien avulla oppia kaaviotietokannan kehittäminen ja pilvipalveluvaihtoehtojen avulla miksi muut teknologiaorganisaatiot eivät käytä graafitietokantoja?
