Articles

Microsoft SQL Server Grafiek – Een poging die viel kort (voor nu)

Posted by admin
TRAN Ngoc Thach
TRAN Ngoc Thach

Volg

29-Jun-2020 · 9 min lezen

Disclaimer: De mening van de in dit artikel is van mij alleen, op basis van mijn beperkte blootstelling aan de SQL Server-Grafiek. Ik ben op geen enkele manier een expert op SQL Server. Ik ben misschien bevooroordeeld in de richting van Neo4j.Met het toenemende gebruik van Graph Database en de dominantie van Neo4j in deze nichemarkt, evenals de aanzienlijke prestatiewinst bij het opvragen van zeer verbonden gegevens, is het begrijpelijk dat Microsoft niet buiten deze mega-trend wil blijven.

vanaf SQL Server 2017 bood SQL Server grafische functionaliteiten, met de introductie van het MATCH sleutelwoord. In versie 2019 werden onder andere twee nieuwe opvallende functies toegevoegd: Randbeperkingen en het gebruik van afgeleide tabellen in MATCH queries. Duiken in deze technologie lang genoeg, Ik heb de indruk dat, vanaf nu:

  • de grafische ondersteuning in SQL Server is nog steeds verre van een volwaardige grafische Database, bijvoorbeeld Neo4j.
  • de toevoeging van functionaliteit is langzaam Incrementeel.
  • de grafiek functie wordt met tegenzin in relationele Database mindset.

laten we in details treden!

Pros & Cons

het MATCH sleutelwoord is naar mijn mening slechts een Syntatische suiker. Eerder dan:

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

… gebruikers kunnen vrij veel verkorten de query als:

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

de verkorte zoekopdracht is ongetwijfeld aangenaam voor het oog. Echter, in. net wereld, entiteit Framework kan de voorkeur voor data-georiënteerde software toepassingen; als gevolg waarvan er geen behoefte aan SQL platte tekst commando ‘ s. Ontwikkelaars gewoon laten het framework genereren optimale queries voor hen, terwijl ze zijn gericht op high-level abstracties. Volgens deze logica is het aangename effect van MATCH plotseling irrelevant. Erger nog, op dit moment is er zelfs geen Roadmap in het ondersteunen van deze grafiek mogelijkheden in Entity Framework (Core).

in vergelijking met Neo4j is het onvermijdelijk dat gebruikers hun grafische mindset in relationele Databasewereld buigen. We moeten nog steeds van tevoren aangeven welke tabellen, in FROM clausule, de matching moeten uitvoeren (zou het eerder de grafiek moeten zijn die wordt beschouwd als een “doorloopbaar geheel” en men hoeft zich geen zorgen te maken over gedetailleerde gegevensorganisatie?). Wanneer men weet dat de pijlrichting in MATCH een must is, komen gebruikers tot het realiseren van de 1-1 mapping tussen MATCH clausule en de oorspronkelijke JOIN clausule, in de zin dat men het Bronknooppunt en het doelknooppunt moet onderscheiden. In tegenstelling, Neo4j ‘ s Cypher syntaxis maakt het mogelijk om dit onderscheid negeren. Al deze zijn niet noodzakelijk een game-changer; maar gewoon een kwestie van gemak en vreugde van ontwikkeling. (Later, in het eerste Studiegeval, zullen we zien dat we hiervoor een UNION ALL moeten doen.)

een sleutel tot hoge prestaties van native Graph Database in het doorkruisen van verbonden gegevens is index-vrije adjacency. Helaas is er niet zoiets met Graph-functie in SQL Server:

we houden geen adjacency-lijst bij op elk knooppunt; in plaats daarvan slaan we edge-gegevens op in tabellen. Omdat het een relationele database is, was het opslaan van gegevens in de vorm van tabellen een meer natuurlijke keuze voor ons

een ander vervelend probleem is het gebrek aan visualisatietools op maat van grafiek, voor zowel schema als data. Als tijdelijke oplossing kunnen gebruikers nog steeds een Schema-Diagram maken in SSM ‘ s, maar die knooppunten en randen-tabellen eindigen als afzonderlijke, niet-verbonden tabellen, zelfs in het geval ze Randbeperkingen hebben. Onder andere, Grafiektechnologie moet ook visuele aantrekkingskracht te brengen, het vergemakkelijken van gebruikers om de juiste query ‘ s te construeren. Het ontbreken van dergelijke tools is frustrerend en schadelijk voor de productiviteit van ontwikkelaars.

Diagram voor grafiektabellen

dus wat doen we om het Grafiektabellenschema te krijgen? Ik denk dat we elke Randtabel openen om handmatig de beperkingen te zien, en dan redeneren op hen, met behulp van een stuk papier, om erachter te komen het hele grafiek schema.

Graph ‘ s Edge Constraints

wat betreft datavisualisatie, heb ik Microsoft Power BI geprobeerd met Force-Directed Graph addon. Deze tool is echter niet gratis en ondersteunt de grafische mogelijkheden van SQL Server out-of-the-box niet, wat betekent dat het de knooppunten en randen tabellen ziet als normale database tabellen. Wanneer we de kolomlijsten nauwkeurig bekijken, zijn er vreemde kolomnamen, bijvoorbeeld graph_id_...,from_obj_id.... Dat zijn interne kolommen, automatisch gegenereerd bij het maken van Node/Edge tabellen, ontoegankelijk van buitenaf. Een fout wordt verhoogd, zoals hieronder, door Macht BI ‘ s Get Data functie als toegang tot die kolommen.

Power BI – “Get Data” van SQL Server ‘ s grafiektabellen

om dit probleem op te lossen, moet men een Databaseweergave aanmaken die alleen relevante/bereikbare kolommen bevat, bijv. from_id en to_id in Edge Table, node_id in Node Table. Dan in Power BI, haal de gegevens door die weergave. Hopelijk vergis ik me niet, Power BI ‘ s kracht gerichte grafiek lijkt een enkele tabel die bestaat uit kolommen vereisen Source, Target, Weight, Source Type, Target Type, Link Type. Ons voorbeeld schema is simplistisch; dus het creëren van deze enkele tabel is triviaal. Wat als het schema +20 knooppunten tabellen en +10 Randen tabel bevat, kunnen we eindigen met een enkele tabel om de hele grafiek te visualiseren met Power BI?

# bijgewerkt op 04.07.2020: Bij nader inzien is dit zeker mogelijk, ook al is het nog steeds omslachtig. Men moet beginnen bij Edges-tabellen, waarin de $from_id en $to_id zijn samengevoegd tegen relevante Knooppunttabellen om te vertalen naar gedeelde eigenschappen van alle knooppunten, bijvoorbeeld Name of Id. Doe dan UNION ALL voor alle te combineren in de laatste enkele tabel vereist door Macht BI.

vragen naar knooppunten en randen is een van de mogelijkheden van Grafiektechnologie. Wat kan een grafiek database opvallen is de ingebouwde maar uitbreidbare ondersteuning voor Grafiek algoritmen, zoals PageRank en Leuven Community Detection (aka. Modulariteit van Leuven). Helaas weer, geen dergelijke analytics functionaliteiten beschikbaar in SQL Server ‘ S grafiek, zoals gezegd:

sommige grafiekdatabases bieden speciale grafiekanalytische functies zoals “kortste weg” of “paginarang”.”SQL Graph biedt geen dergelijke functies in deze release. Ook hier kunnen T-SQL loops en temp tables gebruikt worden om een tijdelijke oplossing te schrijven voor deze scenario ‘ s.

in Neo4j zijn deze algoritmen gemakkelijk beschikbaar in productiekwaliteit dankzij de Graph Data Science Library. Plus, het is open-source. Over het algemeen is documentatie nuttig, maar soms niet voldoende. Met open-source kunnen ontwikkelaars downloaden en duiken in hoe een specifiek algoritme wordt geà mplementeerd; of zelfs de bibliotheek opnieuw compileren, met extra logging info, om verder te begrijpen. Het implementeren van PageRank in SQL is mogelijk, maar complexer algoritme zoals Louvain modulariteit kan een uitdaging zijn. Toch geven veel software engineers er de voorkeur aan zich meer bezig te houden met business logic, in plaats van vast te zitten met technische details op laag niveau.

Last but not least, naar mijn mening, is een veel voorkomende Tabeluitdrukking een soort afgeleide tabellen. Sinds SQL Server 2019 wordt deze techniek officieel verondersteld werkbaar te zijn met Graph:

Common Table Expression (CTE) met grafiektabellen en matching clause

maar als na het maken van de weergave, is het do-able:

bekijk creatie met grafiektabellen en MATCH clause

ik denk dat dit een teken is van inconsistentie. De 2de aanpak vereist een permanent gemaakte weergave omdat het niet mogelijk is om een tijdelijke weergave te maken in SQL Server. Normaal gesproken, gebruikers overwinnen dit met CTE, maar opnieuw CTE werkt niet met Graph, zoals hierboven getoond.

Studiegevallen

een steekproefscenario: studenten en docenten.

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)

grafiek van SQL Server 2019:

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'));

Case 1: Alle inkomende en uitgaande verbindingen van knooppunten

motivatie: Het tellen van deze verbindingen voor elk knooppunt is een manier om erachter te komen welke het belangrijkst zijn.

Neo4j ‘ scyper:

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

grafiek van SQL Server 2019:

--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

toelichting: De SQL-versie is niet alleen langer, maar ook lastiger omdat altijd rekening moet worden gehouden met de richting van de pijlen in MATCH.

geval 2: hoogste langste paden

motivatie: lange afhankelijkheidsketens zijn kwetsbaar. Bijvoorbeeld, bibliotheek afhankelijkheid.

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 Grafiek:

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

Opmerkingen: In SQL Server versie, moet men gebruik maken van recursieve gemeenschappelijke tabel expressie techniek. Het omarmt vrijwel relationele Database mindset om Grafiekproblemen op te lossen.

conclusie

in het Graph-domein is het SQL-commando van een SQL-Server, met al dan niet gebruikte Graph-functie, gebruikt om Grafiekproblemen aan te pakken, meestal veel langer en complexer, in vergelijking met de Cypher van Neo4j. Dit leidt tot een implicatie dat de code meer tijdrovend zal zijn om te ontwikkelen, en moeilijk later te handhaven en uit te breiden. Een andere ingenieur of zelfs de originele, die een maand later naar hetzelfde codefragment kijkt, zal het frustrerend vinden om al zijn aspecten te begrijpen. Een bekende term om deze situatie te beschrijven is technische schuld.

de combinatie van alle bovengenoemde punten, van code aspect tot feature-support, tool/bibliotheek ecosysteem, SQL Server ‘ S grafiek functionaliteit op dit moment, hoewel bemoedigend, niet voldoet aan de verwachtingen.

SQL Server is zeer volwassen met betrekking tot relationele Database, maar duidelijk een newbie in Graph Database. Deze grafische ondersteuning wordt waarschijnlijk geacht te zijn opgenomen in relationele Database mentaliteit.

Related Post

Leave A Comment