Articles

Microsoft SQL Server ’ s Graph-an attempt that fall short (for now)

Posted by admin
TRAN Ngoc Thach
TRAN Ngoc Thach

Follow

Jun 29, 2020 * 9 min Lue

Vastuuvapauslauseke: lausunto tässä artikkelissa on minun yksin, perustuu minun rajoitettu altistuminen SQL Server kuvaaja. En ole millään tavalla asiantuntija SQL Server. Saatan olla puolueellinen Neo4j: n suhteen.

Graafitietokannan yleistyminen ja Neo4j: n ylivoima näillä markkinarakoilla sekä sen merkittävä suorituskykylisäys erittäin kytkettyjen tietojen kyselyssä on ymmärrettävää, ettei Microsoft halua jäädä tämän megatrendin ulkopuolelle.

SQL Server 2017: stä alkaen SQL Server tarjosi Graafitoimintoja, jolloinMATCH – hakusana otettiin käyttöön. Vuoden 2019 versioon lisättiin muun muassa kaksi uutta merkittävää ominaisuutta: Reunarajoitukset ja johdettujen taulukoiden käyttö MATCH kyselyissä. Sukellus tämän teknologian tarpeeksi kauan, minulla on käsitys, että, kuten nyt:

  • SQL Serverin Graafituki on vielä kaukana täysimittaisesta Graafitietokannasta, esimerkiksi Neo4j.
  • toiminnallisuuden lisääminen on hitaasti inkrementaalista.
  • Kuvaajaominaisuus on vastahakoisesti sovitettu relaatiotietokannan ajattelutapaan.

mennään yksityiskohtiin!

plussat & miinukset

MATCH avainsana on mielestäni vain Syntaattinen sokeri. Mieluummin kuin:

SELECT *
FROM NodeTable1 nt1 JOIN EdgeTable et ON nt1.$node_id = et.$from_id JOIN NodeTable2 nt2 ON nt2.$node_id = et.$to_id

… käyttäjät voivat melko paljon lyhentää kyselyn:

SELECT *
FROM NodeTable1 nt1, EdgeTable et, NodeTable2 nt2
WHERE MATCH(nt1-(et)->nt2)

lyhennetty kysely on epäilemättä miellyttävä silmille. . Net Worldissa Entity Framework voi kuitenkin olla parempi datasuuntautuneille ohjelmistosovelluksille, minkä seurauksena SQL: n selkotekstikomennoille ei ole tarvetta. Kehittäjät vain antaa kehyksen tuottaa optimaalisen kyselyt heille, kun he keskittyvät korkean tason abstraktioita. Tällä logiikalla MATCH miellytysvaikutus on yhtäkkiä merkityksetön. Mikä pahinta, tällä hetkellä ei ole edes etenemissuunnitelmaa näiden graafisten valmiuksien tukemiseksi Entity Frameworkissa (Core).

verrattaessa Neo4j: ään, tarkasteltaessa jälleen yllä olevia kyselyitä, käyttäjien on väistämätöntä taivuttaa Kuvaajamiettoaan Relaatiotietokantamaailmaan. Meidän on vielä ilmoitettava etukäteen, mitkä taulukot FROM lausekkeessa vastaavat (pitäisikö sen pikemminkin olla graafi, jota pidetään ”läpitunkevana kokonaisuutena”, eikä yksityiskohtaisesta tiedon järjestämisestä tarvitse välittää?). Kun nuolen suunta MATCH on pakollinen, käyttäjät tulevat toteuttamaan 1-1-kartoituksen MATCH lausekkeen ja alkuperäisen JOIN lausekkeen välillä siinä mielessä, että on erotettava Lähdesolmu ja Kohdesolmu. Sen sijaan Neo4j: n Cypher-syntaksi mahdollistaa tämän eron huomiotta jättämisen. Kaikki nämä eivät välttämättä ole pelinvaihtajia, vaan yksinkertaisesti mukavuuskysymys ja kehityksen ilo. (Myöhemmin 1. Tutkimusjutussa nähdään, että joudumme tekemään UNION ALL tämän takia.)

yksi avain native Graph Databasen tehokkaaseen suorituskykyyn liitettyjen tietojen läpiviennissä on indeksitön adjacency. Valitettavasti, ei ole tällaista asiaa kuvaajan ominaisuus SQL Server:

emme säilytä adjacency-luetteloa jokaisella solmulla, vaan Tallennamme edge-tietoja taulukoihin. Koska kyseessä on relaatiotietokanta, datan tallentaminen taulukoiden muodossa oli meille luontevampi valinta

toinen harmittava asia on graafiin räätälöityjen visualisointityökalujen puute sekä skeeman että datan osalta. Kuten kiertää, käyttäjät voivat silti luoda skeema kaavio SSMS, mutta nämä solmut ja reunat taulukoita päätyä yksittäisiä, irrotettu taulukoita vaikka ne ovat reuna rajoitteet. Muun muassa Graafitekniikan pitäisi tuoda myös visuaalisia vetoomuksia, mikä helpottaa käyttäjiä rakentamaan oikeita kyselyitä. Tällaisten työkalujen puuttuminen on turhauttavaa ja haitallista kehittäjien tuottavuudelle.

kaavio Graafitaulukoille

joten mitä teemme saadaksemme kaavion skeeman? Luulen, että avaamme jokaisen Reunataulukon käsin nähdäksemme rajoitteet, ja sitten järkeilemme niitä paperinpalan avulla selvittääksemme koko kaavion skeeman.

graafin Reunarajoitukset

datan visualisoinnin suhteen kokeilin Microsoft Power BI: tä voimalla ohjatulla Graafilisällä. Tämä työkalu ei kuitenkaan ole ilmainen, eikä se tue SQL Serverin Graafiominaisuuksia out-of-the-box, eli se näkee solmut ja Edget-taulukot normaaleina tietokantataulukoina. Kun kolumnilistoja tutkii tarkasti,löytyy kummallisen näköisiä palstanimiä, esimerkiksi graph_id_...,from_obj_id.... Ne ovat sisäisiä sarakkeita, jotka syntyvät automaattisesti solmun / Reunataulukon luomisen yhteydessä, saavuttamattomissa ulkopuolelta. Virhe nostetaan, kuten alla, by Power BI: n Get Data-toiminto, Jos pääsy näihin sarakkeisiin.

Power BI – ”Get Data” SQL Serverin Graafitaulukoista

tämän ongelman korjaamiseksi on luotava Tietokantanäkymä, joka sisältää vain relevantteja/tavoitettavissa olevia sarakkeita, esim. from_id ja to_id Reunataulukossa, node_id Solmutaulukossa. Sitten vallassa BI, poimia tiedot kautta, että näkymä. Toivottavasti en ole väärässä, teho BI voima suunnattu kuvaaja näyttää vaativan yhden taulukon, joka koostuu sarakkeet Source, Target, Weight, Source Type, Target Type, Link Type. Meidän näyte skeema on yksinkertainen; näin luoda tämän yhden taulukon on triviaali. Mitä jos skeema sisälsi +20 Solmupöytää ja +10 Reunapöytää, voisimmeko päätyä yhteen taulukkoon visualisoimaan koko kuvaajan teholla BI?

#päivitetty 04.07.2020: Toisaalta tämä on varmasti mahdollista, vaikka se on edelleen hankalaa. Aloitetaan Edges-taulukoista, joissa kussakin $from_id ja $to_id on yhdistetty asiaankuuluvia Solmutaulukoita vastaan, jotta voidaan muuttaa kaikkien solmujen yhteiset ominaisuudet, esim. Name tai Id. Tee sitten UNION ALL, jotta kaikki voivat yhdistyä Power BI: n vaatimaan viimeiseen yksittäiseen taulukkoon.

solmujen ja reunojen tiedustelu on yksi Graafitekniikan mahdollisuuksista. Graafitietokannan voi erottaa toisistaan sisäänrakennetulla mutta laajennettavalla tuella Graafialgoritmeille, kuten PageRank – ja Louvain-Yhteisötunnistuksella (aka. Louvain modulaarisuus). Valitettavasti jälleen, ei tällaisia analytiikka toimintoja saatavilla SQL Server kaaviossa, kuten sanoi:

jotkut graafitietokannat tarjoavat dedikoituja graafin analyyttisiä toimintoja, kuten ” lyhin polku ”tai” page rank.”SQL Graph ei tarjoa mitään tällaisia toimintoja tässä julkaisussa. Jälleen, T-SQL silmukoita ja temp taulukoita voidaan käyttää kirjoittaa kiertää näitä skenaarioita.

Neo4j: ssä nämä algoritmit ovat helposti saatavilla tuotantotasolla Graph Data Science Libraryn ansiosta. Lisäksi se on avoimen lähdekoodin. Yleensä dokumentointi on hyödyllistä, mutta joskus ei riitä. Open-source, kehittäjät voivat ladata ja sukeltaa, miten tietty algoritmi toteutetaan; tai jopa kääntää kirjaston, jossa on ylimääräisiä lokitietoja, edelleen ymmärtää. PageRankin toteuttaminen SQL: ssä on mahdollista, mutta monimutkaisemmat algoritmit kuten Louvainin modulaarisuus voivat olla haastavia. Siitä huolimatta monet ohjelmistoinsinöörit haluavat olla enemmän vaivautuneita bisneslogiikan kanssa sen sijaan, että olisivat juuttuneet matalan tason teknisiin yksityiskohtiin.

viimeisenä mutta ei vähäisimpänä mielestäni yleinen Taulukkoilmaisu on eräänlainen johdetut taulukot. Koska SQL Server 2019, tämä tekniikka on virallisesti tarkoitus olla toimiva Graph:

Common Table Expression (CTE) with Graph tables and MATCH clause

But if following VIEW creation, it is do-able:

Katso luominen Graafitaulukoilla ja OTTELULAUSEELLA

tämä on mielestäni merkki epäjohdonmukaisuudesta. Toinen lähestymistapa vaatii pysyvästi luodun näkymän, koska tilapäisen näkymän luominen SQL Serveriin ei ole mahdollista. Normaalisti käyttäjät voittavat tämän CTE: llä, mutta jälleen CTE ei toimi graafin kanssa, kuten yllä on esitetty.

Tutkimustapaukset

otosskenaario: opiskelijat ja opettajat.

Neo4j ’ s Cypher:

CREATE (S1:NStudents {name: "S1"}), (S2:NStudents {name: "S2"}), (T1:NTeachers {name: "T1"}), (S3:NStudents {name: "S3"}), (T2:NTeachers {name: "T2"}), (S4:NStudents {name: "S4"}), (S1)-->(S2), (S2)-->(T1), (T1)-->(T2), (T2)-->(S4), (S3)-->(T1)

SQL Server 2019: n graafi:

CREATE TABLE NStudents ( NVARCHAR(MAX) NOT NULL, INT NOT NULL) AS NODE;CREATE TABLE NTeachers ( NVARCHAR(MAX) NOT NULL, FLOAT NOT NULL) AS NODE;CREATE TABLE Talks (CONSTRAINT EC_Talk CONNECTION (NStudents TO NStudents, NStudents TO NTeachers, NTeachers TO NStudents, NTeachers TO NTeachers) ON DELETE CASCADE) AS EDGE;INSERT INTO NStudents VALUES ('S1',1),('S2',2),('S3',3),('S4',4);
INSERT INTO NTeachers VALUES ('T1',123), ('T2',456);
INSERT INTO Talks VALUES (
(SELECT $node_id FROM NStudents WHERE = 'S1'),
(SELECT $node_id FROM NStudents WHERE = 'S2'));
INSERT INTO Talks VALUES (
(SELECT $node_id FROM NStudents WHERE = 'S2'),
(SELECT $node_id FROM NTeachers WHERE = 'T1'));
INSERT INTO Talks VALUES (
(SELECT $node_id FROM NTeachers WHERE = 'T1'),
(SELECT $node_id FROM NTeachers WHERE = 'T2'));
INSERT INTO Talks VALUES (
(SELECT $node_id FROM NTeachers WHERE = 'T2'),
(SELECT $node_id FROM NStudents WHERE = 'S4'));
INSERT INTO Talks VALUES (
(SELECT $node_id FROM NStudents WHERE = 'S3'),
(SELECT $node_id FROM NTeachers WHERE = 'T1'));

tapaus 1: Kaikki solmujen saapuvat ja lähtevät yhteydet

Motivaatio: näiden yhteyksien laskeminen kullekin solmulle on yksi tapa selvittää, mitkä ovat tärkeimmät.

Neo4j ’ scypher:

MATCH (n)--()
RETURN n.name, COUNT(r) AS allCons
ORDER BY allCons DESC

SQL Server 2019: n graafi:

--Create a View first, for convenience purpose.
CREATE VIEW view_AllPeople
AS
SELECT $node_id AS ,
FROM NStudents
UNION ALL
SELECT $node_id AS ,
FROM NTeachers;--Query using the View.
WITH CTE()
AS
(
SELECT ap1.
FROM view_AllPeople ap1, Talks t, view_AllPeople ap2
WHERE MATCH(ap1-(t)->ap2)
UNION ALL
SELECT ap1.
FROM view_AllPeople ap1, Talks t, view_AllPeople ap2
WHERE MATCH(ap1<-(t)-ap2)
)
SELECT , COUNT(*) AS allConns
FROM CTE
GROUP BY
ORDER BY allConns DESC

huomautukset: SQL-versio on paitsi pidempi, myös hankalampi, sillä nuolien suunta MATCH on aina otettava huomioon.

Tapaus 2: ylimmät pisimmät polut

Motivaatio: Pitkät riippuvuusketjut herkästi haurastuvat. Esimerkiksi kirjastoriippuvuus.

Neo4j ’ scypher:

// The WHERE is to filter out duplicate paths, e.g. A->B = B->A.
MATCH p=(n)--(m)
WHERE ID(n) < ID(m)
RETURN n.name, m.name, length(p) AS len, AS node_list
ORDER BY len DESC

SQL Server 2019: n graafi:

WITH CTE(from_id, to_id, , )
AS
(
SELECT $from_id, $to_id, 1 AS , CONVERT(NVARCHAR(MAX), $to_id) AS
FROM Talks
UNION ALL
SELECT t.$from_id, t.$to_id, +1, CONVERT(NVARCHAR(MAX), CTE. + ',' + CONVERT(NVARCHAR(MAX), $to_id))
FROM Talks t JOIN CTE ON t.$to_id = CTE.
)
SELECT vap., ,
FROM CTE JOIN (SELECT MAX(c.) AS maxLevel FROM CTE c GROUP BY c.) myMax ON CTE. = myMax.maxLevel JOIN
view_AllPeople vap ON CTE. = vap.
ORDER BY DESC

huomautukset: SQL Server-versiossa on turvauduttava Rekursiiviseen yhteiseen Taulukkoilmaisutekniikkaan. Se melko paljon käsittää relaatiotietokannan ajattelutapa ratkaista kaavion ongelmia.

Conclusion

Graph domainissa SQL Serverin SQL-komento, jota käytetään graafisten ongelmien ratkaisemiseen tai ei, on tyypillisesti paljon pitempi ja monimutkaisempi verrattuna Neo4j: n Cypheriin. Tämä johtaa siihen, että koodin kehittäminen vie enemmän aikaa ja sitä on vaikea myöhemmin ylläpitää ja laajentaa. Toinen insinööri tai jopa alkuperäinen, joka katsoo samaa koodinpätkää kuukautta myöhemmin, on turhauttavaa ymmärtää kaikki sen näkökohdat. Tunnettu termi tätä tilannetta kuvaamaan on tekninen velka.

kaikki edellä mainitut kohdat koodinäkökulmasta ominaisuuksien tukemiseen, työkalu-/kirjastoekosysteemiin yhdistäen SQL Serverin Graafitoiminnot tällä hetkellä, vaikka ne ovatkin rohkaisevia, eivät vastaa odotuksia.

SQL Server on relaatiotietokannan suhteen erittäin kypsä, mutta selvästi vasta-alkaja Graafitietokannassa. Tämä Graafituki katsotaan todennäköisesti sisältyvän relaatiotietokannan mentaliteettiin.

Related Post

Leave A Comment