Come interrogare velocemente un elenco molto lungo di proprietà

4

Ho una struttura per la memorizzazione delle proprietà degli elementi su SQL Server:

ItemId PropertyId Value
1      1          a
1      2          b
2      1          a
2      2          5

Attualmente ci sono oltre 130000 articoli e 10000 proprietà e i numeri stanno crescendo. Il numero attuale di file è un po 'più di 15 milioni. Se avessi creato una tabella pivot per questi dati, avrebbe un po 'più di 1,3 miliardi di celle, 15 milioni delle quali non sono nulle.

Gli utenti possono creare espressioni personalizzate su questi dati come:

X: P1 = 'a' (rule X selects items which have property 1 with value 'a')
Y: P2 <> 'b'
Z: P3 like '%c%'
T: P4 > 5 (rule T selects items which have property 4 with a value greater than 5)

e formano filtri usando espressioni come:

(X AND T) (items that match both X and Y)
(X AND Y) OR (Z AND T)
(X OR Y) AND (Z OR NOT T)
(X OR Y AND T) OR Z

Ho bisogno di interrogare il risultato di alcuni filtri (generalmente 4 o 5) come risposta di una singola richiesta web. Come posso farlo velocemente? Esiste un metodo di archiviazione o un algoritmo super efficiente per ottenere questo filtro?

Sarebbe grandioso se questo fosse possibile su SQL Server, ma sono anche aperto a soluzioni come la memorizzazione di questa porzione di dati su un database non sql.

    
posta serhatozgel 28.01.2011 - 00:15
fonte

3 risposte

3

Saranno necessari indici accuratamente costruiti sulla tabella, basati su una sessione iterativa con il server SQL per garantire che il motore selezioni gli indici ed eviti scansioni complete della tabella.

Suppongo che a, b, c e d siano valori forniti dall'utente. In tal caso, mi aspetto che X, Y e T siano facili da creare per gli indici, ma che la clausola "like" di Z sarà un killer poiché la ricerca di testo generica richiede molto spazio e si rischia ancora di dover effettuare ricerche di tabelle complete. Non so se SQL Server supporta la ricerca full text direttamente senza effettuare ricerche complete nella tabella.

Quindi, devi imparare come il pianificatore di SQL Server lavora per decidere come valutare il tuo SQL e inserire gli indici per evitare scansioni complete della tabella.

    
risposta data 28.01.2011 - 00:27
fonte
0

Da quello che hai detto penso che una rapida ricerca a pieno carico e in memoria sarebbe probabilmente l'opzione migliore per iniziare. Oggetti da 15 mln non dovrebbero richiedere troppo tempo. In questo caso, caricare i dati abbastanza rapidamente sarà molto probabilmente il collo di bottiglia. Verifica se il server SQL è abbastanza veloce o se puoi conservare i dati in memoria o se puoi / dovresti utilizzare le soluzioni NoSQL.

Se conosci più specifiche sul tipo di filtri utilizzati, puoi ottimizzare da lì. Quindi registra le query.

    
risposta data 28.01.2011 - 00:34
fonte
0

Prendere in considerazione quali sono i requisiti per la modifica dei dati prima di pianificare l'indicizzazione. E avrai bisogno dell'indicizzazione.

Avere tutto in memoria in modo carino se ne hai abbastanza (c'è mai abbastanza).

A seconda della versione di SQL Server (Enterprise offre la maggior parte delle funzionalità in un ambiente di produzione), potresti essere in grado di sfruttare il partizionamento di tabelle e indici.

Puoi creare viste indicizzate, ma avere molte transazioni di modifica dei dati potrebbe non rendere questo ideale (altrimenti, dovremmo solo indicizzare tutto.).

Hai a che fare solo con una tabella che non ha altre tabelle dati correlate?

    
risposta data 28.01.2011 - 01:18
fonte

Leggi altre domande sui tag