För det första finns det en viktig skillnad att göra här:MongoDB är en allmän databas, Elasticsearch är en sökmotor för distribuerad text som backas upp av Lucene. Folk har pratat om att använda Elasticsearch som en allmän databas men vet att det inte var dess ursprungliga design. Jag tror att NoSQL-databaser och sökmotorer för allmänna ändamål är på väg mot konsolidering, men som det ser ut kommer de två från två mycket olika läger.
Vi använder både MongoDB och Elasticsearch i mitt företag. Vi lagrar vår data i MongoDB och använder Elasticsearch exklusivt för dess fulltextsökningsmöjligheter. Vi skickar bara en delmängd av mongodatafälten som vi behöver fråga till elastisk. Vårt användningsfall skiljer sig från ditt genom att vår Mongo-data ändras hela tiden:en post, eller en delmängd av fälten i en post, kan uppdateras flera gånger om dagen och detta kan kräva omindexering av den posten till elastisk. Bara av den anledningen är det inte ett bra alternativ för oss att använda elastic som enda datalager, eftersom vi inte kan uppdatera valda fält; vi skulle behöva omindexera ett dokument i dess helhet. Detta är inte en elastisk begränsning, det är så här Lucene fungerar, den underliggande sökmotorn bakom elastic. I ditt fall räddar det faktum att poster inte kommer att ändras när de väl har lagrats dig från att behöva göra det valet. Med det sagt, om datasäkerhet är ett problem, skulle jag tänka två gånger på att använda Elasticsearch som den enda lagringsmekanismen för dina data. Den kan komma dit någon gång, men jag är inte säker på att den är där än.
När det gäller hastighet är inte bara Elastic/Lucene i paritet med förfrågningshastigheten för Mongo, i ditt fall där det är "väldigt lite konstant när det gäller vilka fält som används för filtreringen vid varje ögonblick", kan det vara order om magnitud snabbare, särskilt när datamängderna blir större. Skillnaden ligger i de underliggande frågeimplementeringarna:
- Elastic/Lucene använder Vector Space Model och inverterade index för informationshämtning, vilket är mycket effektiva sätt att jämföra postlikhet med en fråga. När du frågar Elastic/Lucene vet den redan svaret; det mesta av dess arbete ligger i att rangordna resultaten åt dig efter de som mest sannolikt matchar dina söktermer. Detta är en viktig punkt:sökmotorer, i motsats till databaser, kan inte garantera dig exakta resultat; de rangordnar resultaten efter hur nära de kommer din fråga. Det råkar vara så att resultaten oftast är nästan exakta.
- Mongos tillvägagångssätt är en mer allmän datalagring; den jämför JSON-dokument med varandra. Du kan få bra prestanda av det på alla sätt, men du måste noggrant skapa dina index för att matcha de frågor du kommer att köra. Specifikt, om du har flera fält som du ska fråga efter måste du noggrant skapa dina sammansatta nycklar så att de minskar datauppsättningen som kommer att frågas så snabbt som möjligt. T.ex. din första nyckel bör filtrera ner större delen av din datauppsättning, din andra bör ytterligare filtrera ner det som finns kvar, och så vidare och så vidare. Om dina frågor inte matchar nycklarna och ordningen på dessa nycklar i de definierade indexen, kommer din prestanda att sjunka en hel del. Å andra sidan är Mongo en äkta databas, så om noggrannhet är vad du behöver, kommer svaren att ge perfekt.
För gamla rekord som löper ut har Elastic en inbyggd TTL-funktion. Mongo har precis introducerat det från och med version 2.2 tror jag.
Eftersom jag inte känner till dina övriga krav som förväntad datastorlek, transaktioner, noggrannhet eller hur dina filter kommer att se ut, är det svårt att ge några specifika rekommendationer. Förhoppningsvis finns det tillräckligt här för att komma igång.