Articles

graficul Microsoft SQL Server – o încercare care a căzut scurt (pentru moment)

Posted by admin
TRAN Ngoc Thach
TRAN Ngoc Thach

Jun 29 · 2020 * 9 min citit

Disclaimer: opinia din acest articol este numai a mea, bazată pe expunerea mea limitată la graficul SQL Server. Eu sunt în nici un fel un expert pe SQL Server. S-ar putea fi părtinitoare față de Neo4j.

odată cu utilizarea tot mai mare a bazei de date grafice și dominanța Neo4j pe această piață de nișă, precum și câștigul său semnificativ de performanță în interogarea datelor extrem de conectate, este de înțeles că Microsoft nu vrea să fie lăsat în afara acestei mega-tendințe.

pornind de la SQL Server 2017, SQL Server a oferit funcționalități grafice, odată cu introducerea cuvântului cheieMATCH. În versiunea 2019, printre altele, au fost adăugate două noi caracteristici notabile: constrângeri de margine și utilizarea tabelelor derivate în interogări MATCH. Scufundări în această tehnologie destul de mult, am impresia că, de acum:

  • suportul grafic în SQL Server este încă departe de o bază de date grafică completă, de ex. Neo4j.
  • adăugarea funcționalității este incrementală lent.
  • caracteristica graficului este montată cu reticență în mentalitatea bazei de date relaționale.

să intrăm în detalii!

Pro & contra

cuvântul cheieMATCH este, în opinia mea, doar un zahăr Sintatic. Mai degrabă decât:

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

… utilizatorii pot scurta destul de mult interogarea ca:

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

interogarea scurtată este, fără îndoială, plăcută ochilor. Cu toate acestea, în.Net world, Entity Framework poate fi preferat pentru aplicațiile software orientate spre date; ca urmare a faptului că nu este nevoie de comenzi SQL cu text simplu. Dezvoltatorii lasă cadrul să genereze interogări optime pentru ei în timp ce se concentrează pe abstracții la nivel înalt. Prin această logică, efectul plăcut al MATCH este brusc irelevant. Mai rău, în acest moment, nu există nici măcar o foaie de parcurs în susținerea acestor capabilități grafice în cadrul entității (Core).

comparativ cu Neo4j, privind din nou la interogările de mai sus, este inevitabil ca utilizatorii să-și îndoaie mentalitatea graficului în lumea bazelor de date relaționale. Trebuie să declarăm în prealabil ce tabele, în clauza FROM, să realizăm potrivirea (ar trebui să fie mai degrabă graficul considerat ca un ‘lucru întreg traversabil’ și nu trebuie să ne pese de organizarea detaliată a datelor?). Când cunoașterea direcției săgeții în MATCH este o necesitate, utilizatorii ajung să realizeze maparea 1-1 între clauza MATCH și clauza originală JOIN, în sensul că trebuie să distingem nodul sursă și nodul țintă. În schimb, sintaxa cifru a lui Neo4j permite ignorarea acestei distincții. Toate acestea nu sunt neapărat un schimbător de jocuri; ci pur și simplu o chestiune de comoditate și bucurie de dezvoltare. (Mai târziu, în cazul de studiu 1, vom vedea că trebuie să facem un UNION ALL din această cauză.)

o cheie pentru performanța ridicată a bazei de date grafice native în traversarea datelor conectate este adiacența fără index. Din păcate, nu există nici un astfel de lucru cu caracteristică grafic în SQL Server:

nu menținem o listă de adiacență pe fiecare nod; în schimb stocăm date de margine în tabele. Deoarece este o bază de date relațională, stocarea datelor sub formă de tabele a fost o alegere mai naturală pentru noi

o altă problemă enervantă este lipsa instrumentelor de vizualizare adaptate graficului, atât pentru schemă, cât și pentru date. Ca soluție, utilizatorii pot crea în continuare o diagramă schemă în SSMS, dar acele tabele noduri și margini ajung ca tabele individuale, deconectate chiar și în cazul în care au constrângeri de margine. Printre altele, tehnologia Graph ar trebui să aducă și apeluri vizuale, facilitând utilizatorii să construiască interogări corecte. Lipsa unor astfel de instrumente este frustrantă și dăunătoare productivității dezvoltatorilor.

diagrama pentru tabelele grafice

deci, ce facem pentru a obține schema graficului? Cred că vom deschide fiecare tabel margine pentru a vedea manual constrângerile, și apoi motiv pe ele, cu ajutorul unei bucăți de hârtie, să dau seama întreaga schemă Grafic.

constrângerile de margine ale graficului

în ceea ce privește vizualizarea datelor, am încercat Microsoft Power BI cu Addon grafic direcționat cu forță. Cu toate acestea, acest instrument nu este gratuit și nu acceptă capabilitățile grafice ale SQL Server out-of-the-box, ceea ce înseamnă că vede tabelele noduri și margini ca tabele de baze de date normale. Examinând îndeaproape listele de coloane, există nume de coloane cu aspect ciudat, de ex. graph_id_...,from_obj_id.... Acestea sunt coloane interne, generate automat la crearea tabelelor Node/Edge, inaccesibile din exterior. O eroare este ridicată, ca mai jos, de funcția Get Data A Power BI dacă accesați aceste coloane.

Power BI — „obțineți date” din tabelele grafice SQL Server

pentru a rezolva această problemă, trebuie să creați o vizualizare a bazei de date care conține numai coloane relevante/accesibile, de ex. from_id și to_id în tabelul Edge, node_id în tabelul Node. Apoi, în Power BI, extrageți datele prin acea vizualizare. Sperăm că nu mă înșel, forța de putere BI regizat Grafic pare să necesite un singur tabel, care constă din coloane Source, Target, Weight, Source Type, Target Type, Link Type. Schema noastră de probă este simplistă; crearea acestui singur tabel este banală. Ce se întâmplă dacă schema conținea + 20 noduri tabele și + 10 margini tabel, am putea ajunge cu un singur tabel pentru a vizualiza întregul grafic cu putere BI?

#actualizat la 04.07.2020: Pe de altă parte, acest lucru este cu siguranță posibil, chiar dacă este încă greoi. Unul ar trebui să înceapă de la tabele margini, în fiecare dintre care $from_id și $to_id sunt unite împotriva tabele noduri relevante pentru a traduce în proprietăți partajate ale tuturor nodurilor, de exemplu, Name sau Id. Apoi faceți UNION ALL pentru ca toți să se combine în tabelul unic final cerut de Power BI.

interogarea nodurilor și marginilor este una dintre posibilitățile tehnologiei graficelor. Ceea ce poate face ca o bază de date Grafic să iasă în evidență este suportul încorporat, dar extensibil, pentru algoritmii grafici, cum ar fi PageRank și Louvain Community Detection (aka. Modularitatea Louvain). Din păcate, din nou, nu există astfel de funcționalități de analiză disponibile în graficul SQL Server, așa cum sa spus:

unele baze de date grafice oferă funcții analitice grafice dedicate ,cum ar fi” calea cea mai scurtă „sau” page rank.”SQL Graph nu oferă astfel de funcții în această versiune. Din nou, buclele T-SQL și tabelele temp pot fi utilizate pentru a scrie o soluție pentru aceste scenarii.

în Neo4j, acești algoritmi sunt ușor disponibili la gradul de producție, datorită Graph Data Science Library. În plus, este open-source. În general, documentația este utilă, dar uneori nu este suficientă. Cu open-source, dezvoltatorii pot descărca și se arunca cu capul în modul în care este implementat un algoritm specific; sau chiar recompila biblioteca, cu informații suplimentare de logare, pentru a înțelege în continuare. Implementarea PageRank în SQL este posibilă, dar algoritmul mai complex, cum ar fi modularitatea Louvain, poate fi o provocare. Cu toate acestea, mulți ingineri software preferă să fie mai deranjați de logica de afaceri, în loc să fie împotmoliți cu detalii tehnice de nivel scăzut.

nu în ultimul rând, în opinia mea, expresia tabelului comun este un fel de tabele derivate. Începând cu SQL Server 2019, această tehnică ar trebui Oficial să fie funcțională cu Graph:

expresia tabelului comun (CTE) cu tabele grafice și clauza de potrivire

dar dacă după crearea vizualizării, este capabil:

Vizualizați crearea cu tabele grafice și clauza de potrivire

cred că acesta este un semn de inconsecvență. Abordarea 2 necesită o vizualizare creată permanent, deoarece nu este posibil să se creeze vizualizare temporară în SQL Server. În mod normal, utilizatorii depășesc acest lucru cu CTE, dar din nou CTE nu funcționează cu Graph, așa cum s-a arătat mai sus.

cazuri de studiu

un exemplu de scenariu: elevi și profesori.

cifrul lui Neo4j:

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)

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

cazul 1: toate conexiunile de intrare și ieșire ale nodurilor

motivație: numărarea acestor conexiuni pentru fiecare nod este o modalitate de a afla care sunt cele mai importante.

Neo4j ‘ scypher:

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

graficul 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

observații: Versiunea SQL nu este doar mai lungă, ci și mai incomodă, deoarece direcția săgeților din MATCH trebuie luată în considerare întotdeauna.

Cazul 2: Cele mai lungi căi de top

motivație: lanțurile lungi de dependență sunt predispuse să fie fragile. De exemplu, dependența de bibliotecă.

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

graficul SQL Server 2019:

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

observații: În versiunea SQL Server, trebuie să recurgem la tehnica recursivă comună de expresie a tabelului. Ea îmbrățișează destul de mult mentalitatea bazei de date relaționale pentru a rezolva problemele graficului.

concluzie

în domeniul graficului, comanda SQL a unui server SQL, cu caracteristică grafică utilizată sau nu, utilizată pentru a aborda problemele graficului, este de obicei mult mai lungă și mai complexă, în comparație cu cifrul Neo4j. Acest lucru duce la o implicație că codul va necesita mai mult timp pentru a se dezvolta și va fi dificil de întreținut și extins ulterior. Un alt inginer sau chiar cel original, care se uită la același fragment de cod o lună mai târziu, va găsi frustrant să înțeleagă toate aspectele sale. Un termen bine cunoscut pentru a descrie această situație este datoria tehnică.

combinând toate punctele menționate mai sus, de la aspectul codului, la suportul de caracteristici, la ecosistemul instrument/bibliotecă, funcționalitatea graficului SQL Server în prezent, deși este încurajatoare, nu corespunde așteptărilor.

SQL Server este extrem de matur în ceea ce privește baza de date relațională, dar în mod clar un începător în baza de date Graph. Acest suport grafic este probabil considerat a fi conținut în mentalitatea bazei de date relaționale.

Related Post

Leave A Comment