Първо, тук трябва да се направи важно разграничение:MongoDB е база данни с общо предназначение, Elasticsearch е разпределена текстова търсачка, подкрепена от Lucene. Хората говорят за използване на Elasticsearch като база данни с общо предназначение, но знаят, че това не е оригиналният му дизайн. Мисля, че NoSQL бази данни с общо предназначение и търсачките са насочени към консолидация, но в момента двете идват от два много различни лагера.
Ние използваме както MongoDB, така и Elasticsearch в моята компания. Ние съхраняваме нашите данни в MongoDB и използваме Elasticsearch изключително за неговите възможности за търсене в пълен текст. Изпращаме само подмножество от полетата с данни mongo, които трябва да потърсим до elastic. Нашият случай на използване се различава от вашия по това, че нашите Mongo данни се променят през цялото време:запис или подмножество от полета на запис може да се актуализира няколко пъти на ден и това може да изисква повторно индексиране на този запис до еластична. Само поради тази причина използването на elastic като единствено съхранение на данни не е добра опция за нас, тъй като не можем да актуализираме избрани полета; ще трябва да преиндексираме документ в неговата цялост. Това не е еластично ограничение, така работи Lucene, основната търсачка зад elastic. Във вашия случай фактът, че записите няма да се променят веднъж съхранени, ви спестява от необходимостта да правите този избор. Като казах това, ако безопасността на данните е проблем, бих помислил два пъти да използвам Elasticsearch като единствен механизъм за съхранение на вашите данни. Може да стигне до там в някакъв момент, но не съм сигурен, че все още е там.
По отношение на скоростта, не само Elastic/Lucene е наравно със скоростта на заявка на Mongo, във вашия случай, когато има „много малко константа по отношение на това кои полета се използват за филтриране във всеки един момент“, това може да са поръчки на величина по-бърза, особено когато наборите от данни стават по-големи. Разликата се крие в основните реализации на заявката:
- Elastic/Lucene използват векторния модел на пространството и обърнатите индекси за извличане на информация, които са високоефективни начини за сравняване на сходството на записи със заявка. Когато заявите Elastic/Lucene, той вече знае отговора; по-голямата част от работата му се състои в подреждането на резултатите за вас по най-вероятните, които отговарят на условията на вашата заявка. Това е важен момент:търсачките, за разлика от базите данни, не могат да ви гарантират точни резултати; те класират резултатите според това колко близо се доближават до вашата заявка. Случва се така, че в повечето случаи резултатите са близки до точните.
- Подходът на Mongo е на съхранение на данни с по-общо предназначение; той сравнява JSON документи един с друг. Можете да получите страхотна производителност от него по всякакъв начин, но трябва внимателно да изработите индексите си, за да съответстват на заявките, които ще изпълнявате. По-конкретно, ако имате множество полета, чрез които ще правите заявки, трябва внимателно да създадете вашите съставни ключове, така че да намалят набора от данни, който ще бъде запитан възможно най-бързо. напр. първият ви ключ трябва да филтрира по-голямата част от вашия набор от данни, вторият ви трябва допълнително да филтрира това, което е останало и т.н. и така нататък. Ако вашите заявки не съвпадат с ключовете и реда на тези ключове в дефинираните индекси, производителността ви ще спадне доста. От друга страна, Mongo е истинска база данни, така че ако точността е това, от което се нуждаете, отговорите, които ще даде, ще бъдат на място.
За стари записи, които изтичат, Elastic има вградена TTL функция. Mongo току-що го представи от версия 2.2, мисля.
Тъй като не знам другите ви изисквания, като очакван размер на данните, транзакции, точност или как ще изглеждат вашите филтри, е трудно да дам някакви конкретни препоръки. Надяваме се, че тук има достатъчно, за да започнете.
