我们目前正在开发一个带有 MEAN 堆栈的系统，后端使用 Mongodb。我们的系统中有员工姓名和 ID，我们的客户希望在我们的系统中进行很好的（阅读：Google Like）搜索以搜索员工记录。他需要我们的系统来推荐员工，即使他拼错了名字等。
我们的开发负责人的建议之一是我们应该使用弹性搜索，但据我所见，弹性搜索是首选，尤其是在我们在大型文本文档中搜索的场景中。我感觉在我们的案例中使用弹性搜索只会增加开销，因为在我们的案例中获取搜索的属性只是名称、电子邮件或 ID 等。
目前，我们的系统只使用一些基本的正则表达式，但我相信，我们可以通过付出一些努力而不转向弹性搜索来改进我们的搜索（尽管开发负责人认为我们只会重新发明轮子，我们应该使用能够做到的技术这些东西给我们。）
所以，我想要一些关于是否转向弹性搜索的指导（建议），还是我们应该坚持使用我们当前的资源来进行比我们现在拥有的更优化的搜索？
正如您所提到的，您正在搜索的只是姓名、电子邮件或 ID 等，而不是大文本。
因此，考虑一个案例，您有 6 个文件/记录的名称如下，那么您可以更好地理解大文本是否重要。
如果用户来搜索 Rohit Bhatnagar，然后使用正则表达式，您将以两种方式显示结果：
案例一：正则表达式是严格匹配的
案例二：当正则表达式放松时
如果我们检查 case Ist，您会遗漏两件事放松（记录 1 和 5 将被遗漏），并且在排名中完全匹配应该排在最重要的位置，这可能更相关。
在案例 2 中，我们放宽了但仍然完全匹配低于排名
因此，如果需要相关搜索，那么是的，您可以使用搜索引擎。您还可以调整是否需要记录 5，因为如果您发现这可能看起来无关紧要，因此您可以控制之间应该有多少单词来考虑文档匹配。如果我们说在两者之间考虑 1 个单词，那么记录 5 将从结果中删除。
除了搜索相关性之外，如果 QPS 很高，您可以水平扩展搜索。您还可以使用机器学习技术（学习排名），也可以应用同义词、词干提取等。还有许多其他好处，您可以从文档中了解加入、流式传输、分片等
Solr： http: //lucene.apache.org/solr/guide/7_6/
ES：https ://www.elastic.co/guide/en/elasticsearch/reference/6.4/index.html
如果需要上面提到的或在不久的将来，那么您可以使用 ElasticSearch 或 Solr 作为搜索引擎，否则您应该对当前系统很好。