我正在创建一个微服务来处理在软件中创建的联系人。我需要创建联系人，并根据一些信息（姓名、电子邮件、电话号码）搜索联系人是否存在。想法如下：一个客户打电话来，如果不存在，我们创建一个联系人，询问他的所有个人信息。第二次他打电话来，我们将通过姓名、电子邮件搜索巧合，以检测该联系人是否已经存在于我们的数据库中。我认为使用MongoDB作为主存储，并使用ElasticSearch执行查询。但我不知道这与在普通关系数据库中进行查询是否真的有很大的区别。
编辑：想象一下，一个呼叫中心总是接到来自不同人的电话，我们想快速搜索（按姓名、电子邮件、姓氏），如果那个人在我们的数据库中，难道ElasticSearch不适合吗？
4条答案
按热度按时间l7mqbcuq1#
关系数据库可以存储数据，也可以对数据进行索引。
搜索引擎可以索引数据，也可以存储数据。
关系数据库在读取刚刚写入的内容方面性能更好，搜索引擎在快速搜索方面性能更好，并有各种各样的规范化技巧：小写字母、ä-〉a或ae、前缀匹配、ngram匹配（如果分别索引）。它在存储中的100万或1000万个条目现在不是什么大问题，但你的查询负载是多少？嗯，只有这么多服务中心工作人员，因此查询负载可能远远小于1 qps，这对于关系数据库来说完全没有问题。如果你想要一些规范化，搜索引擎将开始有意义，如上所述，或者你开始索引自由文本评论，客户的描述。
iszxjhcz2#
如果您没有性能问题，那么请保持简单，使用1个数据存储库（可能在应用程序中使用一些缓存）。
Elasticsearch并不是一个主要的数据存储，所以我的建议是使用一个简单的关系数据库，比如Postgres，并使用简单的SQL查询/ORMMap器。如果数据集不是很大，它应该足够快。
当你在搜索上有性能问题时，你可以使用关系数据库和Elasticsearch的组合。你可以使用Elasticsearch feeder用你的关系数据库中的数据更新ES。
flvlnr443#
索引RDBMS适用于搜索
如果您的数据是结构化的，即列定义明确，那么在RDBMS中搜索100万条记录也不是问题。
何时使用弹性
作为应用程序数据提供程序具有弹性
Elastic不应该被看作是数据存储，即使你在其中存储数据。这是关于你如何理解Elastic。Elastic应该被用来存储和设置应用程序的数据。它是应用程序决定如何和何时使用Elastic（搜索和建议）。如果与RDBMS相比，Elastic不是nosql存储的替代方案，你应该使用nosql数据库代替。
这种观点使elastic与redis和kafka一致，这些工具是应用程序设计的关键组件，它们被用作应用程序的事件存储、搜索引擎和缓存等。
具有弹性的数据库
您的设计应该同时使用这两种方法。使用数据库存储联系人，索引联系人以供查询。同时使数据在弹性中可用，以供搜索、自动完成和相关匹配。
aor9mmx14#
和往常一样，这取决于你的具体用例。你简单地描述了它，但你实际上打算如何使用数据呢？
如果只是简单的检查客户是否存在，然后创建一个新客户，那么就使用RDMS选项。（因此Elasticsearch被指定为BigData），但是您有事务并且数据完整性很重要，那么RDMS将是合适的选择。或财务报告系统。
然而，如果您有一个大型数据集，您需要广泛的查询功能，如模糊搜索或搜索，其中用户可以选择多个过滤器的数据或您想做一些预测分析的数据，那么ElasticSearch是明确的选择。
例如，我曾在一个基于Web的应用程序与一个大的客户群：1100万，在高峰时间每秒有200多次点击。客户可以选择一些复选框来确定，专业，口语，评级，医院等，所有这些都是按照用户位置的距离排序的，响应时间为2秒或更短。RDMS很难匹配这些。