可否完全使用ElasticSearch代替数据库存储

 我来答
百度网友10a24bf
2017-05-19 · TA获得超过1.3万个赞
知道大有可为答主
回答量:1.3万
采纳率:95%
帮助的人:2853万
展开全部
我们使用Elasticsearch存储的文档数量接近50亿(算上1份复制,接近
100亿文档),总共10个数据节点和2个元数据节点(48GB内存,8核心CPU,ES使用内存达到70%),每天的文档增量大概是3000W条(速度
持续增加中)。目前来看,单个文档的查询效率基本处于实时状态;对于1到2周的数据的聚合统计操作也可以在10秒之内返回结果。

但是,还有提升的空间:
1. 对于查询单条数据的应用场景来说,我们可以使用ES的路由机制,将同一索引内的具有相同特征(比如具有相同的userid)的文档全部存储于一个节点上,这样我们之后的查询都可以直接定位到这个节点上,而不用将查询广播道所有的节点上;

2. 随着数据节点的增加,适当增加分片数量,提升系统的分布水平,也可以通过分而治之的方式优化查询性能;

个人以为Elasticsearch作为内部存储来说还是不错的,效率也基本能够满足,在某些方面替代传统DB也是可以的,前提是你的业务不对操作的事
性务有特殊要求;而权限管理也不用那么细,因为ES的权限这块还不完善。由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作,没有大量的单文
档请求(比如通过userid来找到一个用户的文档,类似于NoSQL的应用场景),所以能否替代NoSQL还需要各位自己的测试。如果让我选择的话,我
会尝试使用ES来替代传统的NoSQL,因为它的横向扩展机制太方便了。
推荐律师服务: 若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询

为你推荐:

下载百度知道APP,抢鲜体验
使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。
扫描二维码下载
×

类别

我们会通过消息、邮箱等方式尽快将举报结果通知您。

说明

0/200

提交
取消

辅 助

模 式