现在几乎网上所有资料都说数据存储在传统数据库，再在es中同步一份数据作为检索使用，但是也都没有很详细的说明为什么要这么做，而且在es本身可以存储数据的情况下，存储两份数据是不是没有必要？还会引起别的问题。
虽然收费而且支持的语法不完全，但是在现在es已经支持sql的情况下，我越来越搞不清楚es和数据库之间的界限。
es不支持事务但是能够确保单条数据的写入，这样事务可以通过代码实现。很难进行联合查询可以像其他nosql一样用宽表实现。实时性可以通过配置调整，而在扩展性能和复杂统计上肯定es更优。
基于以上疑问，请问现阶段es与数据库的区别或者说界限到底在哪？
虽然收费而且支持的语法不完全，但是在现在es已经支持sql的情况下，我越来越搞不清楚es和数据库之间的界限。
es不支持事务但是能够确保单条数据的写入，这样事务可以通过代码实现。很难进行联合查询可以像其他nosql一样用宽表实现。实时性可以通过配置调整，而在扩展性能和复杂统计上肯定es更优。
基于以上疑问，请问现阶段es与数据库的区别或者说界限到底在哪？
4 个回复
core_wzw - 某AILab搜索技术负责人
赞同来自: everything 、wayne
本质上都可以做数据存储使用，但各有优劣。OLTP有事务、数据一致性保证，同时保证高并发，异地多活等特性，拿ES怎么做，自己做？那不就变成自研OLTP数据库了吗？同理OLAP有高性能数据分析特性，用列存实现才行，ES用聚合做不来复杂计算，耗时也不能满足需求。他们都有特定使用场景，反过来ES做搜索引擎，提供快速的倒排求交召回甚至ltr精排功能，传统数据库除了用个like还能做啥？
如果站在只使用简单的小数据场景做key-value哈希表使用，随便用吧，数据再小点代码里map实现都行。
匿名用户
赞同来自: wayne
ES 只适合做小数据量的聚合查询，全文检索查询等业务。不适合对超大数据量操作。
硬件无论多么强大，都没有用。我们曾经使用过100台40核心，64gb内存，10tb硬盘，存储几百TB的数据，进行聚合查询等业务。
最后发现，无论如何都是不现实的，聚合数据是非常缓慢的，缓慢的无法忍受。
ES是非常消耗硬件资源的，做大数据不适合。
ES 最应该考虑是是，对一些数据进行搜索，比如商品搜索，比如设备搜索。这些业务是很相似的，比如人员搜索（身份证），比如登录用户，会员信息的搜索等等。
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自: mushao999
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
赞同来自: