2011-12-06 11 views
6

Sto valutando MongoDB, proveniente da Membased/memcached perché voglio maggiore flessibilità.MongoDB è efficiente nel fare ricerche con più chiavi?

Ovviamente Membase è eccellente nel fare ricerche veloci (multi-tasto).

Mi piacciono le opzioni aggiuntive fornite da MongoDB, ma è anche veloce nel fare ricerche con più chiavi? Ho visto l'operatore $ o $ in e sono sicuro di poterlo modellare con quello. Voglio solo sapere se è performante (nello stesso campionato) di Membase.

caso d'uso, ad es. Lucene/Solr restituisce 20 ID prodotto. Cerca questi ID prodotto in Couchdb per restituire documenti/campi appropriati.

Grazie, Geert-Jan

risposta

3

Per il tuo caso d'uso, direi che è, dalla mia esperienza: ho hackerato alcune analisi in un mio database che ha creato molte query $in con migliaia di ID e ha funzionato correttamente (era un hack) . Con mia sorpresa, ha funzionato piuttosto bene, nella zona del millisecondo inferiore.

Ovviamente, è difficile confrontare questo e, come sempre, la teoria è un cattivo compagno quando si tratta di prestazioni. Immagino che il modo migliore per scoprirlo sia la migrazione di alcuni dati di test e l'invio di alcune query al sistema.

Utilizzare l'ottimo profiler incorporato di MongoDB, utilizzare $explain, tenere presente l'indice per regola di query, dare un'occhiata ai registri, tenere d'occhio mongostat e fare alcuni benchmark. Questo non dovrebbe richiedere troppo tempo e dare una risposta definitiva e affermativa. Se le tue domande si rivelano lente, le persone qui e sul gruppo di notizie probabilmente hanno alcune idee su come migliorare la query esatta o l'indicizzazione.

+0

Ok, darò un'occhiata. Scavando un po 'sembra che Mongo-DB usi gli alberi B sotto la copertina per i suoi indici, il che significa che cercare i prodotti x sulla chiave primaria probabilmente costa O (x * log N) (invece di complessità O (x) per Membase basato su hashtrees/tabelle) .. Se l'indice è in mem, questo è probabilmente trascurabile per il mio caso d'uso. Grazie –

1

Un indice per query. Talvolta si ritiene che le query su più chiavi possano utilizzare più indici; questo non è il caso di MongoDB. Se si dispone di una query che seleziona su più chiavi e si desidera che la query utilizzi un indice in modo efficiente, allora un indice di chiave composta è necessario.

http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-Oneindexperquery.

Ci sono anche altre informazioni su quella pagina per quanto riguarda gli indici.

La linea di fondo è che Mongo sarà perfetto se i tuoi indici sono in memoria e stai indicizzando sulle colonne che vuoi interrogare usando le chiavi composite. Se hai una scarsa indicizzazione, le tue prestazioni ne risentiranno. Questo è più o meno in linea con la maggior parte dei sistemi.

+0

Multikey! = Più indici – mnemosyn

+0

No, ma non si riferisce direttamente alla sua domanda. Se si aspetta di eseguire query su più colonne senza creare chiavi composite, le prestazioni ne risentiranno. Se è disposto a spendere il tempo per indicizzare correttamente, Mongo sarà ovviamente sufficiente. – methodin

+0

Comprendo il mantra "un indice per query" in quanto si riferisce alla creazione di chiavi composite in modo che sia necessario un solo indice da interrogare. Questo particolare caso d'uso non ha bisogno di indici compositi, ecc. Ho solo circa 10 milioni di documenti (prodotti) ciascuno con un prodotto unico. Vorrei sapere se fare una query come '$ in (, , )' è efficiente, con il caso speciale che productid è la chiave primaria. Quindi ci sarebbe un indice che copre la mia domanda.Forse sono troppo zelante, ma faccio molta attenzione quando vedo qualcosa che assomiglia alla clausola SQL IN quando parliamo di prestazioni. –

Problemi correlati