
es一般用来存一些流式数据,比如应用日志,这也是目前es应用最广的方面,这些数据有个特点就是往往结构不固定,比如应用日志,不同的程序员写得模块打出来的日志字段数量都不一样,这种数据就不太方便用数据库来处理。
最后,一般传统数据库,全文检索都实现的很鸡肋,因为一般也没人用数据库存文本字段。
上面从使用场景上说明了两者的区别,从技术上两者全文检索的实现都差不多,无非是倒排索引,但是lucene毕竟是专业的,做了十几年了,索引效率,存储空间等都比传统数据库快很多,技术也迭代的非常快。
以上就是我总结的不同之处,希望能解答楼主的疑惑。
作者:Razzit
链接:https://www.zhihu.com/question/53063256/answer/151074607
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
1.结构名称不同2.ES分布式搜索,传统数据库遍历式搜索
3.ES采用倒排索引,传统数据库采用B+树索引
4.ES没有用户验证和权限控制
5.ES没有事务的概念,不支持回滚,误删不能恢复
6.ES免费,完全开源;传统数据库部分免费
有关更详细的比较内容,可以到黑马程序员官网找到社区技术文章,找不到可以对话框问一下。里面还有结合工作的举例。
我们使用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,因为它的横向扩展机制太方便了。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)