Caching vs Indexing

Question

Qual è la vera differenza tra una soluzione di caching e una soluzione di indicizzazione? Mi sembra che una soluzione di indicizzazione stia effettivamente memorizzando nella cache la possibilità di eseguire query di ricerca (come: Elastic Search). Sarebbe mai esistito un vero motivo per utilizzare sia una soluzione di caching e una soluzione di indicizzazione all'interno dello stesso progetto o la soluzione di indicizzazione fondamentalmente rende ridondante qualsiasi altro caching?

Esempio: suppongo di utilizzare NEST per ElasticSearch, che memorizzerebbe e restituirà POCO; se faccio una query su ElasticSearch e mi viene restituito il POCO, non è considerato l'utilizzo di un oggetto memorizzato nella cache restituito da ElasticSearch?

Al momento, ho memorizzare i dati in una cache utilizzando un'interfaccia ICacheManager ho .. qualcosa di simile:

return CacheManager.Get(cacheKey,() => 
{ 
    // return something... 
}); 

sarebbe questo diventare ridondante con elasticsearch?

EDIT

Grazie a tutti voi per le risposte. Sono pienamente consapevole di cosa sia una cache e ho già compreso l'idea generale alla base di un indice per la ricerca testuale, quindi mi stavo solo chiedendo se l'indice raddoppia già come cache e renderebbe quindi ridondante qualsiasi altra cache. Dopo tutto, non vorrei conservare 2 cache nella memoria (esempio: ElasticSearch + Redis) quando si andrebbe bene. Penso di avere un'idea migliore adesso; specialmente quando ho capito che non tutti i campi sono sempre memorizzati nell'indice e quindi è necessario recuperare l'oggetto da una cache o direttamente dal db, almeno in alcuni casi. Ringrazia tutti!

Answer 1

L'intero scopo di una cache è di restituire i dati già richiesti il più rapidamente possibile. Un vincolo di cache è che non possono essere troppo grandi o come il tempo di ricerca aumenterebbe e quindi sconfiggere lo scopo di avere una cache in primo luogo. Detto questo, non sorprende che se si prevede di avere alcuni milioni/miliardi di record nel DB, non sarà difficile indicizzarli tutti ma sarà difficile memorizzarli tutti nella cache, anche se la RAM sta diventando più economico ed economico, potresti essere in grado di memorizzare tutto ciò che ti serve in memoria. È inoltre necessario chiedersi se la cache deve essere distribuita tra più host o meno (sia ora che in futuro).

Considerando che le ricerche e le query in ES sono estremamente veloci (+ ES ti offre molti più vantaggi in aggiunta a quello, come il punteggio), cioè di solito più veloce del recupero degli stessi dati dal tuo DB, avrebbe senso usare ES come cache. Un problema che vedo è comune, vale a direnon appena inizi a duplicare i dati (DB -> ES), devi assicurarti che entrambi i negozi non vadano fuori sincronia.

Ora, se in aggiunta si inserisce una cache in questo mix, è un terzo archivio dati da conservare e garantire che sia coerente con l'archivio dati principale. Se sai che i tuoi dati sono piuttosto stabili, cioè scritti e quindi non aggiornati frequentemente, allora potrebbe essere ok, ma è necessario tenere sempre presente questa preoccupazione durante la progettazione della strategia di accesso ai dati.

Come ha detto @paweloque, alla fine tutto dipende dal vostro caso di utilizzo esatto. Ogni problema è diverso e posso affermare che, dopo alcune dozzine di progetti attorno a ES negli ultimi cinque anni, non ho mai visto due progetti configurati allo stesso modo. Una cache potrebbe avere senso per alcuni casi specifici, ma non per gli altri.

È necessario riflettere su come e dove è necessario archiviare i dati, chi li richiede (ea che velocità), chi li sta creando/aggiornando (e con quale frequenza), ma alla fine, il migliore la pratica è di mantenere il tuo stack il più snello possibile con solo il minor numero possibile di componenti, ognuno dei quali rappresenta un potenziale collo di bottiglia che devi capire, integrare, mantenere, regolare e monitorare.

Infine, aggiungerei ancora una cosa: aggiungere una cache o un indice dovrebbe essere considerato un'ottimizzazione delle prestazioni del proprio stack software. Come probabilmente sai il detto corrente "Premature optimization is root of all evil", dovresti prima andare solo con il tuo database, misurare le prestazioni, caricarlo, quindi verificare che non supporti il ​​carico. Solo così, puoi decidere di lanciare una cache e/o un indice a seconda delle esigenze. Ancora una volta, caricare test, misurare, quindi decidere. Se hai solo dieci utenti che fanno poche richieste al giorno, avere solo un DB potrebbe essere perfettamente soddisfacente. Devi capire quando e perché devi aggiungere un altro livello sulla tua Torre di Babele, ma soprattutto devi aggiungere un livello alla volta e vedere come quel livello migliora/degrada la stabilità della pila.

Ultimo ma non meno importante, è possibile trovare alcuni articoli online da persone che hanno utilizzato ES come cache (principalmente key-value stores e object caches).

Answer 2

Interessante domanda! Bene, si potrebbe in uso utilizzare elasticsearch per implementare una cache. Fornisce alcune funzioni con cui puoi scartare i documenti, ma non sono sicuro che siano adatti per far scadere la cache. Il problema è che elasticsearch non è costruito per essere una soluzione di memorizzazione nella cache. Il punto debole è l'indicizzazione e la ricerca di documenti.

L'indicizzazione è il compito di creare un indice, come è stato fatto per i libri: si legge l'intero testo e si scrive su quale pagina sono state trovate le parole. Questo ci permette in seguito di trovare le posizioni delle parole nel testo molto velocemente.

Elasticsearch fornisce una casella degli strumenti che consente di definire come indicizzare ed elaborare il testo, ovvero applicare la derivazione. Quindi, nel passaggio successivo, fornirà diversi tipi di query per trovare i tuoi documenti.

È possibile, tuttavia, scrivere documenti in elasticsearch e utilizzare l'id del documento per leggerlo. In questo modo è possibile utilizzare elasticsearch come archivio che potrebbe essere utilizzato come cache.

Answer 3

La tua domanda:

D. Qual è la vera differenza tra una soluzione di caching e di una soluzione di indicizzazione?

A. La semplice differenza è che la cache viene utilizzata per memorizzare i dati utilizzati di frequente per servire più velocemente le stesse richieste. Essenzialmente la tua cache è più veloce del tuo negozio principale ma è di dimensioni inferiori, quindi i dati che può memorizzare (considerando il comune che sarebbe più costoso)

L'indicizzazione viene effettuata su tutti i dati per renderla più veloce per la ricerca . Una semplice Hashtable/HashMap ha hash come indici e in una matrice gli 0 e gli 1 sono gli indici.

È possibile indicizzare alcune colonne per cercarle più rapidamente. Ma la cache è il posto in cui vorresti avere i tuoi dati per recuperarli più velocemente. Normalmente Cache è la RAM e il database proviene da HardDisk

Anche la cache è di solito un archivio di valori chiave, quindi se si conosce la chiave, quindi recuperarla dalla cache, non è necessario eseguire una query. In NHibernate ed EntityFrameworks, le cache di query sono collegate con le query come chiavi e tutti i dati vengono memorizzati nella cache. Ora le tue query verranno recuperate dalla cache invece di eseguirle attraverso il database.