Perché i database relazionali funzionano affatto, data la complessità esponenziale teorica della ricerca di risposte (nella dimensione della query)?


19

Sembra essere noto che per trovare una risposta a una query su un database relazionale D , occorre tempo | D | | Q | e non ci si può liberare dell'esponente | Q | .QD|D||Q||Q|

Dato che può essere molto grande, ci chiediamo perché i database funzionino affatto nella pratica.D

È solo una questione delle solite query che non sono affatto grandi nelle applicazioni del mondo reale? (Quindi è interessante sapere qual è la dimensione normale delle query poste ai sistemi di database relazionali e qual è la dimensione "massima" delle query che si prevede che in pratica sia effettivamente rispondibile da un sistema DB .)

Note sull'esponente non "rimovibile"|Q|

Per dimostrare che l'esponente non è rimovibile, è possibile utilizzare una query che chiede se esiste una cricca di dimensione n nel grafico fornito dal database. Per verificare se un grafico ha un n -clique è un problema NP-completo. Inoltre, non è trattabile a parametro fisso, con parametro n . I dettagli sono disponibili, ad esempio, in Libkin, L .: Elements Of Finite Model Theory. Springer (2004) o Papadimitriou, CH, Yannakakis, M .: Sulla complessità delle query del database. J. Comput. Syst. Sci. 58 (3), 407–427 (1999)|Q|nnn



7
Le query ordinarie (come SELECT * FROM users WHERE username="abc" AND passwrod="xyz") sono ricerche semplici, che richiedono l'esecuzione di O (| D |). Se è presente un indice nei relativi campi del database, ci vorrà O (log | D |). Non mi occupo di database, ma non credo che query più complicate richiederebbero tempo esponenziale.
MS Dousti,

7
@imz: Nel tuo esempio, la complessità è , che è ancora polinomiale. Sembra che, se ci sono k join nella query, la complessità è O ( | D | k + 1 ) . Questo è un polinomio per k fisso, ma penso che per k di grandi dimensioni, l'esecuzione della query sarà molto lenta in pratica. Quindi bisogna evitare troppi join a tutti i costi. O(|D|2)O(|D|k+1)
MS Dousti,

7
La complessità temporale è esponenziale nella lunghezza di una query nel caso peggiore . Ciò non contraddice che alcune query lunghe sono veloci. I professionisti del database sanno quali query vengono eseguite rapidamente nei motori di database tipici e non fanno comunque affidamento sul caso peggiore in termini di lunghezza della query.
Tsuyoshi Ito,

2
@Kaveh: "Il libro sulla complessità descrittiva di Immerman ha avuto una piccola discussione nell'ultimo capitolo": Ottimo suggerimento. Nitpicking: è discusso nel penultimo capitolo. @imz: potresti trovare utile anche l'articolo Expressive Power of SQL .
MS Dousti,

5
@imz: "Questo grafico ha una n-cricca" in pratica non è una query comune. La maggior parte delle query sono più simili a quelle suggerite da @Sadeq e hanno una struttura fortemente ad albero. Inoltre, per database molto grandi anche una query completamente lineare è troppo costosa e si deve lavorare con uno schizzo del database.
András Salamon,

Risposte:


16

Esistono grandi classi di query che sono "facili", anche nel caso peggiore. In particolare, se la classe di query contiene solo query congiuntive e ogni query ha una larghezza limitata (ad esempio larghezza dell'albero, larghezza dell'albero del suo grafico di incidenza, larghezza ipertestuale frazionaria o larghezza sottomodulare), è possibile rispondere alla query utilizzando qualcosa come un albero di join , insieme all'enumerazione della forza bruta per le parti locali della query che si discostano dall'albero. Ciò richiede tempo polinomiale, con il grado del polinomio determinato dal parametro width.

Sembra che molte domande incontrate nella pratica siano entrambe congiuntive e abbiano una larghezza ridotta. Quindi il runtime polinomiale ha un basso grado in questo caso.

Dániel Marx ha recentemente presentato un documento allo STOC 2010 sulla larghezza sottomodulare, la cui versione completa include un bel riassunto delle varie nozioni di larghezza e di come la formulazione CSP si collega al formalismo del database (la versione della conferenza non lo ha).

  • Dániel Marx, Proprietà hypergraph trattabili per soddisfazione dei vincoli e query congiuntive , 2010. arxiv: 0911.0801

Questa non è una risposta completa, poiché non si occupa della complessità "tipica" delle query del database, ma anche con l'analisi del caso peggiore ci sono query facili.


6

È possibile utilizzare le query Q_n per verificare se un grafico, rappresentato come database, contiene una cricca con n elementi. Controllare se un grafico ha una cricca è un problema NP completo. Inoltre, non è trattabile a parametro fisso, con parametro n (che significa D ^ n).


Si prega di pubblicare ulteriori spiegazioni riguardanti lo sfondo della domanda sia come "commento" (non una "risposta") - con il pulsante "Aggiungi commento" sotto la domanda, o come suggerimento di modifica - con il collegamento "modifica" sotto la domanda. Le "risposte" non sono per alcuna discussione e aggiunta alla domanda. (Partecipare qui dovrebbe essere più comodo se ti registri come utente non anonimo; quindi è più facile tenere traccia di chi ha detto cosa nelle discussioni.)
imz - Ivan Zakharyaschev

@imz: lo ha inserito come una risposta perché non ha il privilegio di commentare. È necessario disporre di almeno 50 rappresentanti. per poter commentare ovunque.
Tomek Tarczynski,

@Tomek, @imz, beh, si sta discutendo sul meta al momento se dovremmo permettere di commentare usando le risposte o meno.
Kaveh,

5

Un altro modo di rispondere a questa domanda è "non lo fanno!"

Se si assegna a una tipica implementazione DBMS una query contenente un numero molto elevato di join, non supererà nemmeno la fase di pianificazione / ottimizzazione (per non parlare della valutazione), anche se la query è aciclica o ha una struttura molto semplice come András allude a sopra.

Ma, per carichi di lavoro DBMS "tipici", tali query sembrano non sorgere.


1
Per query complesse, il risultato della fase di ottimizzazione è un piano scelto casualmente. Questo non è così negativo come sembra, perché il percorso di esecuzione potrebbe essere ancora "abbastanza buono", e ci sono molte altre ragioni per cui l'ottimizzazione è difficile al di là della combinatoria del numero di join.
Tegiri Nenashi,

4

Ecco una versione più attenta alla realtà della risposta di tigreen dal punto di vista di una persona che fa un uso intensivo di database (relazionali): il punto e la complessità della loro applicazione è strutturarli in un modo che richiederebbero si unisce per ciascuno e per ogni query sempre più necessario in quanto possibile ed è per questo che in realtà funzionano . In altre parole, non aspettatevi che i database risolvano da soli i problemi complessi - non lo farebbero, ma se usati saggiamente sono uno strumento davvero utile e applicabile.


0

I join sono solo quadratici rispetto alle relazioni molti-a-molti. Questi sono relativamente rari: in pratica, la maggior parte delle relazioni e dei join sono da 1 a molti, quindi impiegheranno tempo lineare se vengono definiti indici / chiavi. Le query con più join molti-a-molti sono un problema serio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.