Dibattito sulla registrazione Bentornati all’ultimo dibattito sul registro in cui gli scrittori discutono di argomenti tecnologici e voi lettori scegliete l’argomento vincente.
Il formato è semplice: proponiamo una proposta, gli argomenti a favore della proposta vengono pubblicati lunedì e oggi e gli argomenti contrari vengono pubblicati martedì e domani. Durante la settimana puoi votare per quale parte tifi usando il sondaggio qui sotto, scegliendo se sei a favore o contro. Il risultato finale sarà annunciato venerdì, rivelando quale argomento è stato il più popolare.
Sta ai nostri scrittori convincerti a votare per la loro parte.
La richiesta di questa settimana è:
I database a grafo, in cui le relazioni sono archiviate in modo nativo insieme agli elementi di dati, non offrono un vantaggio significativo rispetto ai database relazionali ben progettati per la maggior parte degli stessi casi d’uso.
Discutere PER proposta ancora una volta, con un contrappunto alle affermazioni di Jim Webber di ieri, è Andy PavloProfessore Associato di Database alla Carnegie Mellon University.
È tutto divertimento e giochi finché le cose non diventano… Relazionali
Il mio stimato collega afferma timidamente di non sapere cosa significhi un DBMS “ben progettato”. Tuttavia, permettetemi di ricordargli le caratteristiche chiave di un tale sistema. Mi concentrerò sulle query analitiche rispetto ai grafici, poiché è qui che i DBMS a grafo affermano di essere migliori dei DBMS relazionali. Anche il mio elenco di seguito è ispirato a questo documento CIDR 2023 [PDF] dai ricercatori del CWI.
- Scansione rapida dei dati digitati: il movimento NoSQL ha indotto gli sviluppatori a pensare che un database senza schema (ovvero uno schema opzionale) sia una buona idea. È necessario per alcuni scenari e la maggior parte dei DBMS relazionali ora supporta i tipi di dati JSON. Ma per la copia veloce dei dati, se il DBMS riconosce lo schema e il tipo di dati, rimuove l’indirizzamento e migliora le prestazioni di scansione.
- Memoria a colonne: l’archiviazione dei dati in modo orientato alle colonne presenta numerosi vantaggi, tra cui la riduzione dell’I/O su disco e il sovraccarico della memoria dovuto all’omissione di colonne non necessarie per una query. I dati colonnari hanno anche un’entropia inferiore rispetto ai dati orientati alle righe, il che li rende più adatti a schemi di compressione che non richiedono prima la decompressione da parte del DBMS.
- Esecuzione di query vettorizzate: utilizzo di un modello di elaborazione vettorializzato [PDF] (al contrario del modello tuple-at-a-time) migliora le prestazioni del DBMS per le query analitiche di 10-100 volte. L’elaborazione in batch consente inoltre al DBMS di sfruttare l’istruzione vettoriale della CPU (SIMD) per migliorare ulteriormente le prestazioni.
- Controllo esplicito della memoria: un DBMS necessita di un controllo completo sulle allocazioni di memoria. Ciò significa non utilizzare un runtime di memoria “gestito” (ad es. JVM, Erland) in cui la frammentazione e la raccolta dei rifiuti causeranno problemi di prestazioni, né il sistema operativo dovrebbe essere autorizzato a determinare quali dati eliminare dalla cache (ad es. MMAP). Un DBMS deve anche disporre di un posizionamento accurato dei dati per garantire che le informazioni correlate si trovino vicine l’una all’altra per migliorare l’efficienza della CPU.
Andy Pavlo: “L’errore che hanno commesso è stato ignorare la storia del database e cercare di reinventare i puntini abbandonando il modello relazionale”
Esistono alcune ottimizzazioni aggiuntive specifiche del grafico che un DBMS relazionale dovrebbe includere:
- API di query orientate ai grafici: lo standard SQL:2023 introduce le query sui grafici delle proprietà (SQL/PCG) per la definizione e l’attraversamento dei grafici in un DBMS relazionale. SQL/PCG è un sottoinsieme dello standard GQL emergente. Pertanto, SQL/PCG riduce ulteriormente il divario funzionale tra DBMS relazionali e DBMS grafici nativi.
- Miglioramenti dell’esecuzione delle query: un DBMS relazionale ben architettato dovrà includere miglioramenti specifici per l’ottimizzazione delle query su grafo, inclusi join ottimali multiway nel caso peggiore (WCOJ), strutture di dati effimere compatte (ad es. righe sparse compresse) ed elaborazione delle query fattorizzate. Sebbene l’aggiunta di questi richieda un’ingegnerizzazione non banale, tali miglioramenti si adattano perfettamente ai motori di runtime DBMS relazionali esistenti e non richiedono la scrittura di un nuovo motore da zero.
A riprova delle prestazioni di un DBMS relazionale architetturale rispetto a un DBMS a grafo, faccio riferimento al documento CIDR 2023 di CWI [PDF]. Hanno esteso il DBMS relazionale analitico integrato di DuckDB per aggiungere il supporto SQL/PCG ei miglioramenti sopra elencati. Lo hanno quindi confrontato con un DBMS grafico principale su un benchmark grafico standard. I loro risultati mostrano che DuckDB, con le estensioni di cui sopra, supera il DBMS grafico originale fino a 10 volte. Questi sono gli ultimi risultati di gennaio 2023, non di cinque anni fa.
E sebbene il team CWI includa alcuni dei migliori ricercatori di sistemi di database al mondo, non hanno raccolto centinaia di milioni di dollari per raggiungere questi risultati.
Per quanto riguarda il riferimento del mio collega all’articolo fondamentale di Stonebraker del 2006 che confuta l’architettura DBMS “taglia unica”, il loro aneddoto secondo cui Neo4j è nato dal loro tentativo di utilizzare un DBMS relazionale negli anni 2000 per carichi di lavoro incentrati sui grafici è la prova dell’argomentazione di Stonebraker. Ma l’errore che hanno commesso è stato ignorare la storia del database e cercare di reinventare la ruota abbandonando il modello relazionale. Incoraggio anche i lettori interessati a leggere il trattato di Stonebraker del 2006 [PDF] sul fallimento di modelli di dati alternativi per sostituire il modello di dati relazionali sin dalla sua invenzione nel 1969. I database a grafo sono solo un’altra categoria di DBMS non relazionali che alla fine diminuiranno di popolarità man mano che i DBMS relazionali ne adotteranno le parti migliori (come altri nel passato).
Infine, mantengo la mia scommessa pubblica del 2021 sul futuro del mercato dei database a grafo. Sostituirò la mia foto ufficiale della CMU con una di me che indossa una maglietta che dice “Graph Databases Are # 1”. Userò quella foto finché non andrò in pensione, verrò licenziato o accoltellato da un ex studente. ®
Dai il tuo voto qui sotto. Chiuderemo il sondaggio giovedì sera e annunceremo il risultato finale venerdì. Puoi seguire l’andamento del dibattito qui.
JavaScript è disabilitato
Si prega di abilitare JavaScript per utilizzare questa funzione.