是时候用 ES 拯救发际线啦

es与传统数据库界限

Elasticsearch | 作者 cleverxiao | 发布于2019年11月26日 | 阅读数:7520

现在几乎网上所有资料都说数据存储在传统数据库,再在es中同步一份数据作为检索使用,但是也都没有很详细的说明为什么要这么做,而且在es本身可以存储数据的情况下,存储两份数据是不是没有必要?还会引起别的问题。
虽然收费而且支持的语法不完全,但是在现在es已经支持sql的情况下,我越来越搞不清楚es和数据库之间的界限。
es不支持事务但是能够确保单条数据的写入,这样事务可以通过代码实现。很难进行联合查询可以像其他nosql一样用宽表实现。实时性可以通过配置调整,而在扩展性能和复杂统计上肯定es更优。
基于以上疑问,请问现阶段es与数据库的区别或者说界限到底在哪?
已邀请:

core_wzw - 某AILab搜索技术负责人

赞同来自: everything wayne

https://db-engines.com/en/ranking
本质上都可以做数据存储使用,但各有优劣。OLTP有事务、数据一致性保证,同时保证高并发,异地多活等特性,拿ES怎么做,自己做?那不就变成自研OLTP数据库了吗?同理OLAP有高性能数据分析特性,用列存实现才行,ES用聚合做不来复杂计算,耗时也不能满足需求。他们都有特定使用场景,反过来ES做搜索引擎,提供快速的倒排求交召回甚至ltr精排功能,传统数据库除了用个like还能做啥?
如果站在只使用简单的小数据场景做key-value哈希表使用,随便用吧,数据再小点代码里map实现都行。
匿名用户

匿名用户

赞同来自: wayne

ES 全文检索引擎lu实现的搜索框架。请不要把ES 当成关系型数据库使用。ES 存储大数据量的数据是没问题的,但是对大数据量的数据落地后进行各种操作,那就是问题了。消耗非常大的资源,但是收获非常的少。
 
ES 只适合做小数据量的聚合查询,全文检索查询等业务。不适合对超大数据量操作。
 
硬件无论多么强大,都没有用。我们曾经使用过100台40核心,64gb内存,10tb硬盘,存储几百TB的数据,进行聚合查询等业务。
最后发现,无论如何都是不现实的,聚合数据是非常缓慢的,缓慢的无法忍受。
 
ES是非常消耗硬件资源的,做大数据不适合。
 
ES 最应该考虑是是,对一些数据进行搜索,比如商品搜索,比如设备搜索。这些业务是很相似的,比如人员搜索(身份证),比如登录用户,会员信息的搜索等等。

laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自: mushao999

1,适用场景不同。关系型数据库更适合oltp的业务场景;而es的确如楼上所说,不能当做数据库来使用(原因1:不支持事务,原因2:近实时而非准实时,由refresh_interval控制,最快1s数据写入后可检索)。
es适合olap的场景(侧重分析),举例:海量日志分析和检索、海量大文本的全文检索等。
2,存储类型不同。关系型数据库一般只支持存储结构化数据(pgsql支持json);而es支持关系型和非结构化数据,如:json由object或者nested类型存储。
3,可扩展性不同。关系型数据库通病,如:mysql单表支持数据量有限,数据量大了就得分库分表,再大了考虑分布式,原生分布式的瓶颈催生了很多第三方公司如:TIDB(开源+解决方案付费)。而:es支持横向扩展,天生支持多节点集群部署,扩展能力强,甚至支持跨集群检索;能支持PB+的数据,国内的:滴滴、携程、顺丰、今日头条、bat等很多核心数据业务都已经通过es实现。
4,解决问题不同。关系型数据库针对核心:增删改查的业务场景,对于全文检索会慢的要死(很多客户迁移es就是这个原因,早期用lucene后用solr,但发现es更好用);而es的倒排索引机制更适合全文检索。
5,数据模型不同。
关系型数据库通常针对复杂业务会多表设计、不同表不同模型,多表通过join关联或者视图查询。
而es支持复杂业务数据,通常不建议多表关联,确切说es倒排索引机制决定了它天然不适合多表关联。复杂业务数据通常解决方案:1,宽表(空间换时间);2,nested 3,父子关联join(针对频繁更新场景)。
对于聚合业务场景,的确大数据量(千万级以上)多重嵌套全量聚合es会很慢,业务选型可以考虑其他辅助方案。
其他欢迎补充。
所以,适合自己业务场景的才是最好的!

mobikarl

赞同来自:

一个是数据库,一个是搜索引擎,根据场景选产品

要回复问题请先登录注册