对于只读api来说,elasticsearch是一个好的数据存储吗?

f1tvaqid  于 2021-06-10  发布在  ElasticSearch
关注(0)|答案(2)|浏览(447)

我们计划创建一个通过只读api公开的报告数据库。它将为我们的客户和内部流程(如发票)包含与报告相关的读取API。
此外,我们认为让kibana来分析我们的内部团队也会很有用。
ElasticSearch适合这个用例吗?

mcdcgff0

mcdcgff01#

除了opster的回答外,我还想提到两件事,它们可能有助于你做出决定:
e.s是如何为我们提供实时报告用例的服务的,该用例在生产中具有广泛的数据集
e.s与mongo的报告绩效(我们测量)
e.s是如何在具有广泛数据集的生产中为实时报告用例服务的
e、 s为我们的以下案例提供实时结果(1秒以下):
通过在数百万个数据点上运行多组过滤器(日期等)和聚合生成的报告
基于时间的报告(按天、周、月、季度、年分组数据)-由datehistogram提供支持
e.s与mongo的报告绩效(我们测量)
在e.s中聚合500万个数据点花费<1秒,而在类似的情况下,mongo花费>10秒。
除此之外,还提供了对脚本的支持,这提供了很大的灵活性。

eufgjt7s

eufgjt7s2#

是的,为什么不呢?elasticsearch将是非常适合您的用例的选择,原因如下:
您可以将数据反规范化并存储在单个索引中,这将使获取和搜索速度非常快,这通常是nosql的主要用例,es可以这样工作。
基本的x-pack安全性在es中是免费的,这将为您的用户提供只读访问,而无需花费太多精力和成本。
除了搜索之外,elasticsearch在分析用例方面也非常流行,您可以很容易地为您的用例运行聚合,并且可以使用kibana dashboard进行可视化,它与es有很好的集成,因为两者都是同一公司(elastic)的产品。
最重要的是,es是一个横向可扩展的分布式系统,可以轻松地扩展到数百个节点,以支持任何人不断增长的需求。

相关问题