For det første er der en vigtig sondring at gøre her:MongoDB er en database til generelle formål, Elasticsearch er en distribueret tekstsøgemaskine, der understøttes af Lucene. Folk har talt om at bruge Elasticsearch som en database til generelle formål, men ved, at det ikke var dets originale design. Jeg tror, at NoSQL-databaser og søgemaskiner til generelle formål er på vej mod konsolidering, men som det er nu, kommer de to fra to meget forskellige lejre.
Vi bruger både MongoDB og Elasticsearch i min virksomhed. Vi gemmer vores data i MongoDB og bruger udelukkende Elasticsearch til dets fuldtekstsøgningsmuligheder. Vi sender kun en delmængde af de mongo-datafelter, som vi skal forespørge på, til elastic. Vores anvendelsestilfælde adskiller sig fra din ved, at vores Mongo-data ændres hele tiden:en post eller en delmængde af felterne i en post, kan opdateres flere gange om dagen, og dette kan kræve en re-indeksering af denne post til elastisk. Alene af den grund er det ikke en god mulighed for os at bruge elastic som eneste datalager, da vi ikke kan opdatere udvalgte felter; vi bliver nødt til at genindeksere et dokument i dets helhed. Dette er ikke en elastisk begrænsning, det er sådan Lucene fungerer, den underliggende søgemaskine bag elastik. I dit tilfælde sparer det faktum, at posterne ikke vil blive ændret, når de først er gemt, dig fra at skulle træffe det valg. Når det er sagt, hvis datasikkerhed er et problem, ville jeg tænke to gange om at bruge Elasticsearch som den eneste lagringsmekanisme til dine data. Det kan komme der på et tidspunkt, men jeg er ikke sikker på, at det er der endnu.
Med hensyn til hastighed er Elastic/Lucene ikke kun på niveau med forespørgselshastigheden for Mongo, i dit tilfælde, hvor der er "meget lidt konstant med hensyn til hvilke felter der bruges til filtreringen til enhver tid", kan det være ordrer på størrelse hurtigere, især da datasættene bliver større. Forskellen ligger i de underliggende forespørgselsimplementeringer:
- Elastic/Lucene bruger Vector Space Model og inverterede indekser til informationssøgning, som er yderst effektive måder at sammenligne registreringslighed med en forespørgsel på. Når du spørger Elastic/Lucene, kender den allerede svaret; det meste af dets arbejde ligger i at rangordne resultaterne for dig efter de mest sandsynlige, der matcher dine søgetermer. Dette er et vigtigt punkt:søgemaskiner, i modsætning til databaser, kan ikke garantere dig nøjagtige resultater; de rangerer resultaterne efter, hvor tæt de kommer på din forespørgsel. Det sker bare sådan, at resultaterne de fleste gange er tæt på nøjagtige.
- Mongos tilgang er en mere generel datalager; den sammenligner JSON-dokumenter med hinanden. Du kan på alle måder få stor ydeevne ud af det, men du skal omhyggeligt udforme dine indekser, så de matcher de forespørgsler, du vil køre. Specifikt, hvis du har flere felter, som du vil forespørge efter, skal du omhyggeligt udforme dine sammensatte nøgler, så de reducerer det datasæt, der vil blive forespurgt så hurtigt som muligt. For eksempel. din første nøgle skal filtrere størstedelen af dit datasæt ned, din anden skal yderligere filtrere det tilbage, og så videre og så videre. Hvis dine forespørgsler ikke matcher nøglerne og rækkefølgen af disse nøgler i de definerede indekser, vil din ydeevne falde en del. På den anden side er Mongo en ægte database, så hvis nøjagtighed er, hvad du har brug for, vil de svar, den giver, være i orden.
For udløbende gamle poster har Elastic en indbygget TTL-funktion. Mongo har lige introduceret det fra version 2.2 tror jeg.
Da jeg ikke kender dine øvrige krav såsom forventet datastørrelse, transaktioner, nøjagtighed eller hvordan dine filtre vil se ud, er det svært at komme med specifikke anbefalinger. Forhåbentlig er der nok her til at komme i gang.