Articles

a Microsoft SQL Server grafikonja-egy sikertelen kísérlet (egyelőre)

Posted by admin
Tran Ngoc Thach
TRAN Ngoc Thach

követés

Jun 29, 2020 * 9 perc olvasás

jogi nyilatkozat: a cikkben szereplő vélemény egyedül az enyém, az SQL Server grafikonjának korlátozott kitettsége alapján. Nem vagyok az SQL Server szakértője. Lehet, hogy elfogult vagyok a Neo4j felé.

a Gráfadatbázis növekvő használatával és a Neo4j dominanciájával ezen a réspiacon, valamint a nagymértékben összekapcsolt adatok lekérdezésében elért jelentős teljesítménynövekedésével érthető, hogy a Microsoft nem akar kimaradni ebből a mega-trendből.

az SQL Server 2017-től kezdve az SQL Server Graph funkciókat kínált, aMATCH kulcsszó bevezetésével. A 2019-es verzióban többek között két új figyelemre méltó szolgáltatás került hozzáadásra: Élkorlátozások és származtatott táblák használata MATCH lekérdezésekben. Búvárkodás ez a technológia elég hosszú, van egy benyomásom, hogy, mint a most:

  • az SQL Server Gráftámogatása még mindig messze van egy teljes értékű Gráfadatbázistól, pl. Neo4j.
  • a funkcionalitás hozzáadása lassan növekszik.
  • a gráf funkció vonakodva illeszkedik a relációs adatbázis gondolkodásmódjába.

menjünk bele a részletekbe!

előnyök & hátrányok

aMATCH kulcsszó véleményem szerint csupán Szintatikus cukor. Ahelyett, hogy:

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

… a felhasználók nagyjából lerövidíthetik a lekérdezést:

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

a rövidített lekérdezés kétségtelenül kellemes a szemnek. A. net világban azonban az Entity Framework előnyben részesíthető az adatorientált szoftveralkalmazások számára; ennek eredményeként nincs szükség SQL egyszerű szöveges parancsokra. A fejlesztők csak hagyják, hogy a keretrendszer optimális lekérdezéseket generáljon számukra, miközben magas szintű absztrakciókra összpontosítanak. Ezzel a logikával a MATCH kellemes hatása hirtelen irreleváns. Ami még rosszabb, jelenleg még nincs ütemterv ezen gráf képességek támogatására az Entity Framework (Core) programban.

összehasonlítva a Neo4j-vel, a fenti lekérdezéseket újra megvizsgálva elkerülhetetlen, hogy a felhasználók gráf gondolkodásmódjukat relációs adatbázis-világba hajlítsák. Még mindig előre meg kell állapítanunk, hogy a FROM záradékban mely táblázatok hajtják végre az illesztést (inkább a grafikon tekinthető ‘átjárható egésznek’, és nem kell törődni a részletes adatszervezéssel?). Amikor a MATCH nyíl irányának ismerete kötelező, a felhasználók felismerik az 1-1 leképezést a MATCH és az eredeti JOIN záradék között, abban az értelemben, hogy meg kell különböztetni a Forráscsomópontot és a Célcsomópontot. Ezzel szemben a Neo4j Cypher szintaxisa lehetővé teszi ennek a megkülönböztetésnek a figyelmen kívül hagyását. Mindezek nem feltétlenül változtatják meg a játékot, hanem egyszerűen a kényelem és a fejlődés örömének kérdése. (Később, az 1. tanulmányi esetben látni fogjuk, hogy emiatt UNION ALL – ot kell tennünk.)

a natív Gráfadatbázis nagy teljesítményének egyik kulcsa a csatlakoztatott adatok áthaladásában az indexmentes szomszédság. Sajnos az SQL Server Graph funkciójával nincs ilyen:

nem minden csomóponton tartunk fenn szomszédsági listát; ehelyett az éladatokat táblázatokban tároljuk. Mivel ez egy relációs adatbázis, az adatok táblázatok formájában történő tárolása természetesebb választás volt számunkra

egy másik bosszantó probléma a grafikonra szabott vizualizációs eszközök hiánya, mind a séma, mind az adatok számára. Megkerülő megoldásként a felhasználók továbbra is létrehozhatnak Sémadiagramot az SSMS-ben, de ezek a csomópontok és élek táblák különálló, leválasztott táblákként végződnek, még akkor is, ha Élkorlátjaik vannak. A Grafikontechnológiának többek között vizuális fellebbezéseket is kell hoznia, megkönnyítve a felhasználókat a helyes lekérdezések elkészítésében. Az ilyen eszközök hiánya frusztráló és káros a fejlesztők termelékenységére.

grafikon táblázatok diagramja

tehát mit tegyünk a gráf séma megszerzéséhez? Azt hiszem, megnyitjuk az egyes Éltáblákat, hogy manuálisan lássuk a korlátokat, majd egy darab papír segítségével Érveljünk rájuk, hogy kitaláljuk az egész gráf sémát.

Graph ‘ s Edge Constructions

az adatok megjelenítésével kapcsolatban Kipróbáltam a Microsoft Power BI-t a Force-Directed Graph addonnal. Ez az eszköz azonban nem ingyenes, és nem támogatja az SQL Server Graph képességeit a dobozon kívül, ami azt jelenti, hogy a csomópontok és élek táblákat normál adatbázis tábláknak tekinti. Az oszloplistákat alaposan megvizsgálva furcsa kinézetű oszlopnevek vannak, például graph_id_...,from_obj_id.... Ezek belső oszlopok, amelyek automatikusan generálódnak a csomópont/Éltáblák létrehozásakor, kívülről elérhetetlenek. Az alábbiak szerint hibát vet fel a Power BI Get Data funkciója, ha hozzáfér ezekhez az oszlopokhoz.

Power BI – “Adatok beolvasása” az SQL Server

Grafikontábláiból a probléma megoldásához létre kell hozni egy adatbázis nézetet, amely csak releváns/elérhető oszlopokat tartalmaz, pl. from_id és to_id az Éltáblában, node_id a csomópont táblában. Ezután a Power BI-ban bontsa ki az adatokat ezen a nézeten keresztül. Remélhetőleg nem tévedek, úgy tűnik, hogy a Power BI Force Directed grafikonja egyetlen táblázatot igényel, amely oszlopokból áll Source, Target, Weight, Source Type, Target Type, Link Type. Mintasémánk egyszerű; így ennek az egyetlen táblázatnak a létrehozása triviális. Mi lenne, ha a séma +20 csomópont táblát és +10 Éltáblát tartalmazna, végül egyetlen táblával tudnánk megjeleníteni az egész gráfot a Power BI segítségével?

# Frissítve 04.07.2020: Jobban belegondolva, ez biztosan lehetséges, még akkor is, ha még mindig nehézkes. Az Éltábláknál kell kezdeni, amelyek mindegyikében a $from_id és $to_id össze vannak kapcsolva a megfelelő Csomóponttáblákkal, hogy az összes csomópont megosztott tulajdonságává váljon, pl. Namevagy Id. Ezután tegye meg a UNION ALL parancsot, hogy mindenki egyesítse a Power BI által megkövetelt utolsó egyetlen táblába.

a csomópontok és élek lekérdezése a Gráftechnika egyik lehetősége. Ami egy Gráfadatbázist kiemelkedővé tehet, az a gráf algoritmusok beépített, mégis bővíthető támogatása, mint például a PageRank és a Louvain Community Detection (más néven. Louvain modularitás). Sajnos ismét nem állnak rendelkezésre ilyen elemzési funkciók az SQL Server Graph-ban, amint azt mondták:

egyes gráfadatbázisok dedikált gráfanalitikai funkciókat biztosítanak, például ” legrövidebb út “vagy” page rank.”Az SQL Graph nem nyújt ilyen funkciókat ebben a kiadásban. Ismét a T-SQL hurkok és a temp táblák használhatók az ilyen forgatókönyvek megkerülésére.

a Neo4j-ben ezek az algoritmusok a graph Data Science Library-nek köszönhetően könnyen elérhetők a gyártási fokozatban. Ráadásul nyílt forráskódú. Általában a dokumentáció hasznos, de néha nem elegendő. A nyílt forráskódú fejlesztők letölthetik és belemerülhetnek egy adott algoritmus megvalósításába; vagy akár újrafordíthatják a könyvtárat, további naplózási információkkal, hogy jobban megértsék. A PageRank megvalósítása SQL-ben lehetséges, de bonyolultabb algoritmus, például Louvain modularitás kihívást jelenthet. Ennek ellenére sok szoftvermérnök inkább jobban zavarja az üzleti logikát, ahelyett, hogy alacsony szintű műszaki részletekkel leragadna.

végül, de nem utolsósorban, véleményem szerint a Common Table kifejezés egyfajta származtatott táblázat. Az SQL Server 2019 óta ez a technika hivatalosan működőképes a Graph segítségével:

Common Table Expression (CTE) Gráftáblákkal és MATCH záradékkal

de ha követi a nézet létrehozását, akkor képes:

nézet létrehozása grafikon táblázatok és MATCH záradék

azt hiszem, ez annak a jele, következetlenség. A 2.megközelítéshez állandóan létrehozott nézetre van szükség, mivel az SQL Server alkalmazásban nem lehet ideiglenes nézetet létrehozni. Normális esetben a felhasználók ezt a CTE-vel oldják meg, de a CTE ismét nem működik a Graph-val, amint azt fentebb bemutattuk.

vizsgálati esetek

minta forgatókönyv: diákok és tanárok.

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)

az SQL Server 2019 grafikonja:

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

1. eset: a csomópontok összes bejövő és kimenő kapcsolata

motiváció: ezeknek a kapcsolatoknak a megszámlálása minden csomópontnál az egyik módja annak, hogy megtudja, melyek a legfontosabbak.

Neo4j ‘ Cypher:

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

az SQL Server 2019 grafikája:

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

Megjegyzések: Az SQL verzió nemcsak hosszabb, hanem kényelmetlenebb is, mivel a MATCH nyilak irányát mindig figyelembe kell venni.

2.eset: a leghosszabb utak

motiváció: a hosszú függőségi láncok hajlamosak törékenyek lenni. Például a könyvtárfüggőség.

Neo4j ‘ Cypher:

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

az SQL Server 2019 grafikája:

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

Megjegyzések: Az SQL Server verzió, az egyik, hogy igénybe rekurzív közös tábla kifejezés technika. Nagyjából magában foglalja a relációs adatbázis gondolkodásmódját a Gráfproblémák megoldására.

következtetés

a Gráftartományban az SQL Server SQL parancsa, a Gráfproblémák kezelésére használt vagy nem használt Gráffunkcióval, általában sokkal hosszabb és összetettebb, mint a Neo4j Cypherje. Ez azzal a következménnyel jár, hogy a kód kifejlesztése időigényesebb lesz, és később nehéz fenntartani és kiterjeszteni. Egy másik mérnök, vagy akár az eredeti, egy hónappal később ugyanazt a kódrészletet nézve frusztrálónak fogja találni annak minden aspektusát. A helyzet leírására jól ismert kifejezés a technikai adósság.

a fent említett pontok kombinálásával, a kód szempontjától a szolgáltatás-támogatásig, az eszköz/könyvtár ökoszisztémáig, az SQL Server Graph funkcionalitása jelenleg, bár biztató, elmarad a várakozásoktól.

az SQL Server rendkívül érett a relációs adatbázis tekintetében, de egyértelműen újonc a Graph adatbázisban. Ezt a grafikon támogatást valószínűleg úgy tekintik, hogy a relációs adatbázis mentalitása tartalmazza.

Related Post

Leave A Comment