Ottimizzazione del completamento automatico per set di dati di grandi dimensioni

Question

Sto lavorando a un progetto di grandi dimensioni in cui devo presentare un modo efficiente per l'utente di immettere dati in un modulo.

Tre dei campi di tale modulo richiedono un valore da un sottoinsieme di un'origine dati comune (tabella SQL). Ho usato JQuery e JQuery UI per creare un completamento automatico, che pubblica un HttpHandler generico.

Internamente il gestore utilizza Linq-to-sql per prelevare i dati richiesti da quella tabella specifica. La tabella ha circa 10 diverse colonne e l'espressione linq utilizza lo SqlMethods.Like() per abbinare il termine di ricerca singolo su ciascuno di quei 10 campi.

Il problema è che quella tabella contiene alcune righe 20K. Il completamento automatico funziona perfettamente, accetta l'enorme volume di dati che introduce deleays, in prossimità di circa 6 secondi (durante il debug sul mio computer locale) prima che si presenti.

Il completamento automatico di JqueryUI ha 0 ritardo, le query sul tasto 3 e il risultato del post viene effettuato in opzioni selezionabili su più righe in stile Facebook. (Ho quasi dovuto riscrivere il plugin di completamento automatico ...).

Quindi il problema è data vs. velocità. Qualche idea su come accelerare questo? Gli unici due pensieri che avevo erano di memorizzare i dati nella cache (come/dove?); o utilizzare il lettore di dati SQL diretto per l'accesso ai dati?

Qualsiasi idea sarebbe molto apprezzata! Grazie,

<bleepzter/> 

Answer 1

vorrei guardare solo restituendo il primo numero X di righe con il metodo .Take(10) LINQ. Questo dovrebbe tradursi in una sensible call sql, che metterà molto meno peso sul tuo database. Man mano che gli utenti digitano, troveranno sempre meno corrispondenze, quindi vedranno solo i dati che richiedono.

Normalmente sono 10 gli elementi sufficienti per consentire all'utente di capire cosa sta succedendo e ottenere comunque i dati di cui hanno bisogno rapidamente (vedere la barra di ricerca di amazon.com per un esempio).

Ovviamente se è possibile ordinare i dati in modo significativo, i risultati 10 saranno molto più propensi a fornire rapidamente all'utente ciò che stanno cercando.

Answer 2

Il ritorno dei primi risultati N è sicuramente una buona idea. Abbiamo trovato (interrogando una potenziale lista di 270K) che la restituzione dei primi 30 è una scommessa migliore per l'utente che trova quello che sta cercando, ma che COMPLETAMENTE dipende dai dati che stai interrogando.

Inoltre, si dovrebbe VERAMENTE cadere il ritardo a qualcosa di sensato come 100-300 ms. Quando imposti il ​​ritardo su ZERO, una volta premuto il grilletto a 3 caratteri, effettivamente OGNI. SINGLE. CHIAVE. ICTUS. viene inviato come una nuova query al tuo server. Ciò potrebbe facilmente avere l'effetto non voluto e indesiderato di rallentare ulteriormente la risposta.