Ricerca a grana fine su un set di dati di grandi dimensioni

Non hai detto quanto sono grandi i dati, quanto sono grandi i singoli campi o il budget che hai.

Indipendentemente dal sistema di indicizzazione scelto, considera l'eventualità di lanciare l'hardware sul problema. Non dovresti aver bisogno di cercare i dischi per niente. Indicizza tutti i dati, usando uno schema che è molto veloce da attraversare (forse un elenco o un albero ordinato). Memorizza l'indice sul disco, ma poi memorizza l'intero indice nella RAM. Potresti aver bisogno di decine o addirittura centinaia di gigabyte di RAM per farlo.

Se i singoli campi sono grandi o di dimensioni variabili, prendi in considerazione l'hashing degli indici di hash.

Il prezzo per il server da fare potrebbe essere spaventoso.

Ignorando tutti i dettagli tecnici questo è un problema di organizzazione / gestione e deve essere risolto dalla direzione della tua organizzazione.

Il tuo manager deve essere disposto a risolvere il problema al piano di sopra e / o convincere i suoi utenti a sollevare il problema a un livello elevato.

Al tuo livello, metti insieme o richiedi una stima per farlo con l'hardware Oracle e Oracle. Quindi crea una stima realistica per un cluster Hadoop.

Nonostante il clamore, questi cluster non costano poco (probabilmente avete bisogno di qualcosa come 18 nodi di processore con 64 GB di memoria e 4 x 2 TB distribuiti su tre rack, poi altri 4 nodi per il catalogo, ecc.). Non sottovalutare ; se vinci, dovrai implementarlo.

Quindi, per prima cosa chiariamo chiaramente il problema in termini di requisiti:

1. Il sistema deve memorizzare un minimo di 4 milioni di registrazioni al giorno.
2. Il sistema deve fornire un'interfaccia di ricerca all'utente
   2.1 La capacità di ricerca deve restituire risultati in un massimo di 3 secondi
3. Il sistema deve essere in grado di cercare almeno 10,2 miliardi di record
4. Il sistema deve utilizzare un database progettato su misura
   4.1 Il sistema deve avere hardware e software ottimizzati per lo sviluppo del database

Ci sono probabilmente ulteriori requisiti non funzionali, oltre a dettagli su quanto sono grandi i singoli record, che sono probabilmente rilevanti per la tua situazione.

La risposta breve è che hai un problema con i requisiti. Se si osservano questi requisiti, tre di essi (i primi tre) si applicano correttamente al sistema per definirne la funzione e il comportamento. L'ultimo requisito non è un requisito valido da una prospettiva purista, ma ho visto che questi tipi di requisiti vengono inseriti in dichiarazioni di lavoro.

Quindi, il modo in cui questo problema viene risolto è di stimare il costo del 4 ° requisito, dati gli altri tre. Una volta che lo fai, presentalo come soluzione. La direzione andrà in panico e immediatamente vi chiederanno perché il problema non può essere risolto per un prezzo ragionevole. Questo è il punto di partenza per la tua discussione su ciò che deve accadere. Avere un'alternativa economica disponibile e pronta per essere presentata.

Questo è in contrasto con ciò che stai facendo in questo momento, il che presuppone che gli altri tre non possano essere soddisfatti dato l'ultimo. Il management non capisce, perché tutto ciò che vedono sono i segni del dollaro.

Se fossi nei tuoi panni, inizierei con un'implementazione ragionevole, da manuale, utilizzando nient'altro che un normale RDBMS, incorporato nell'applicazione, in modo che non si sentano come se dovessero supportare qualcosa . SQLite, H2 o qualsiasi altro database incorporato alternativo dovrebbero fare: nessun file flat speciale, nessun indice esotico, niente: solo un'applicazione semplice di pratiche standard per risolvere il problema, per la maggior parte ignorando il immensità dei dati. (Ovviamente, sceglierei un numero abbastanza grande come una chiave, e questo è tutto, praticamente.)

Mentre ci lavoravo, probabilmente mi si presentavano un paio di altre idee su come farlo funzionare più velocemente senza ricorrere a qualcosa di esotico.

Quindi, testerei questo per vedere come si comporta e vorrei dimostrare i risultati, insieme alla soluzione operativa, ai "poteri di essere" nella tua organizzazione.

1. Esiste la possibilità che la tua implementazione diretta funzioni all'interno dei vincoli richiesti, quindi starai bene lì, non c'è bisogno di fare nient'altro, zero risorse sprecate.

2. Se le prestazioni dell'implementazione diretta sono esterne, ma non troppo lontane, ai vincoli richiesti, i "poteri dell'essere" potrebbero dire "bene, questo è abbastanza vicino, non vogliamo fare qualsiasi altra cosa, quindi è quello che sarà ". Di nuovo, zero risorse sprecate.

3. Se le prestazioni dell'implementazione diretta sono esterne, ma entro lo stesso ordine di grandezza, dei vincoli richiesti, direi loro di acquistare solo hardware migliore, più grande e più veloce. La maggior parte delle possibilità sono che lo faranno e il caso sarà chiuso.

4. Se non vogliono acquistare hardware migliore, più grande e più veloce, allora raccomanderei loro di ripensare al loro obbligo di astenersi dall'utilizzare un RDBMS grande e scalabile. Se sono ragionevoli e hai dimostrato di essere ragionevole, è probabile che lo ripensino.

5. Se i poteri di essere non vogliono seguire nessuna delle vie ragionevoli, e invece vogliono che tu interpreti il ruolo di un mago, allora e solo allora inizierei a preoccuparmi di soluzioni esotiche. Molte possibilità sono, le cose non arriveranno a quel punto. Ma anche se lo facessero, la quantità di lavoro che avresti fatto invano fino a quel momento sarà relativamente piccola, e vale la scommessa che potrebbe essere sufficiente.

Pensando dal front-end ...

Se separi i tipi di ricerca nell'interfaccia utente, potresti essere in grado di avere vincoli più ragionevoli.

Sembra che un tipo di ricerca sia un recente evento-azione di dati su un evento, che ti permette di isolare per tempo nella ricerca dei dati. Questo forse fornisce un insieme di dati molto più piccolo, con la probabile aspettativa che un utente possa essere richiamato al più presto.

Altri tipi di ricerca, in cui è necessario eseguire un set di dati di grandi dimensioni o le ricerche dei vecchi time frame, possono avere un'interfaccia utente diversa (o più UI), con un buon spinner per indicare ... pensare ora. Poiché questo può essere compreso dall'utente come un insieme di requisiti più laborioso, la pazienza potrebbe essere ragionevolmente prevista. E naturalmente, realisticamente necessario.

Non so se hai qualche possibilità di influire sul design del tendine anteriore, ma se riesci a trasmettere i vincoli con cui stai lavorando, speriamo che coloro che gestiscono l'interazione con l'utente rispondano con comprensione (almeno alcuni).