探究 | Elasticsearch 与传统数据库界限

0、引言

现在几乎网上所有资料都说数据存储在传统数据库,再在 es 中同步一份数据作为检索使用,但是也都没有很详细的说明为什么要这么做,而且在 es 本身可以存储数据的情况下,存储两份数据是不是没有必要?还会引起别的问题。

虽然收费而且支持的语法不完全,但是在现在 es 已经支持 sql 的情况下,我越来越搞不清楚 es 和数据库之间的界限。

es 不支持事务但是能够确保单条数据的写入,这样事务可以通过代码实现。很难进行联合查询可以像其他 nosql 一样用宽表实现。实时性可以通过配置调整,而在扩展性能和复杂统计上肯定 es 更优。

基于以上疑问,请问现阶段 es 与数据库的区别或者说界限到底在哪?

https://elasticsearch.cn/question/8885

—— 来自社区的提问

其实拿传统关系型数据库和 Elasticsearch 直接来对比有些牵强,毕竟一个是数据库,一个是搜索引擎。

如果硬要对比,我们剥茧抽丝,一点点探究一下 Elasticsearch 与传统数据库的不同。

1、使命不同

Oracle 对关系型数据库的定义:

关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行(包含唯一 key 的记录)和列(存储了属性)被称为表,一组表组成了数据库。

Elasticsearch 的官方定义:

Elasticsearch是一个分布式的开源搜索和分析引擎,适用于所有类型的数据,包括文本、数字、地理空间、结构化和非结构化数据。Elasticsearch 在 Apache Lucene 的基础上开发而成,由 Elasticsearch N.V.(即现在的 Elastic)于 2010 年首次发布。Elasticsearch 以其简单的 REST 风格 API、分布式特性、速度和可扩展性而闻名,是 Elastic Stack 的核心组件;Elastic Stack 是适用于数据采集、充实、存储、分析和可视化的一组开源工具。人们通常将 Elastic Stack 称为 ELK Stack(代指 Elasticsearch、Logstash 和 Kibana),目前 Elastic Stack 包括一系列丰富的轻量型数据采集代理,这些代理统称为 Beats,可用来向 Elasticsearch 发送数据。

A relational database can store data and also index it.

A search engine can index data but also store it.

如上可通俗解读为:

  • 关系数据库可以存储数据并为其建立索引。

  • 搜索引擎可以索引数据,但也可以存储数据。

2、适用场景不同

关系型数据库更适合 OLTP (是一种以事务元作为数据处理的单位、人机交互的计算机应用系统,最大优点:最大优点是可以即时地处理输入的数据,及时地回答)的业务场景;而 Elasticsearch不能当做纯数据库来使用。

  • 原因 1:不支持事务,

  • 原因 2:近实时而非准实时,由 refresh_interval 控制,最快 1s 数据写入后可检索。

Elasticsearch 适合 OLAP 的场景(它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。侧重分析)。

举例:

  • 海量日志分析和检索、

  • 海量大文本的全文检索等。

3,存储类型不同

关系型数据库一般只支持存储结构化数据(pgsql 支持 json)。

结构化数据的特点:

  • 由二维表结构来逻辑表达和实现的数据

  • 严格地遵循数据格式与长度规范。

举例:银行交易数据、个人信息数据等。

而 Elasticsearch 支持关系型和非结构化数据,如:json 由 object 或者 nested 类型或者父子 Join 存储。

非结构化数据的特点:

  • 数据结构不规则或不完整;

  • 没有预定义的数据模型,不方便用数据库二维逻辑表来表现的数据。

举例: 包括所有格式的办公文档、文本、图片、XML, HTML、各类报表、图像和音频/视频信息等等。

脑海中想一下: 是不是实战中遇到:数据结构不定、字段个数不定、字段类型不定、是否动态添加不定等多变的业务场景?

4,可扩展性不同

关系型数据库通病, 如:mysql 单表支持数据量有限,数据量大了就得分库分表,再大了考虑分布式,原生分布式的瓶颈如下:

  • 分库分表非常麻烦,

  • 业务依赖性高,

  • 复杂查询会出现错误,

  • 更重要的是分布式事务无法有效处理。

催生了很多第三方 NewSql 公司如:TIDB(开源+解决方案付费)。

而 Elasticsearh 支持横向扩展,天生支持多节点集群部署,扩展能力强,甚至支持跨集群检索;能支持 PB+的数据。

国内的:滴滴、携程、顺丰、今日头条、bat 等很多核心数据业务都已经通过 Elasticsearch 实现。

5,解决问题不同

关系型数据库针对核心:增删改查的业务场景,对于全文检索会慢的要死(很多客户迁移 Elasticsearch 就是这个原因,早期用 lucene 后用 solr,但发现 Elasticsearch 更好用);而 Elasticsearch 的倒排索引机制更适合全文检索。

实际业务中:

  • 如果数据量不大,建议使用简单的关系数据库结合简单的 SQL 查询就能解决问题。

  • 如果您对性能没有问题,请保持架构简单并使用单个数据库存储,必要时加些缓存(如 redis)。

  • 如果您在搜索中遇到性能问题,则可以将关系型数据库和 Elasticsearch 结合使用。

6,数据模型不同

关系型数据库通常针对复杂业务会多表设计、不同表不同模型,多表通过 join 关联或者视图查询。

而 Elasticsearch 支持复杂业务数据,通常不建议多表关联,确切说 Elasticsearch 倒排索引机制决定了它 天然不适合多表关联 。复杂业务数据通常解决方案:

  • 1, 宽表(空间换时间);

  • 2, nested

  • 3, 父子关联 join(针对频繁更新场景)。

对于聚合业务场景,的确大数据量(千万级以上)多重嵌套全量聚合 es 会很慢,业务选型可以考虑其他辅助方案。

7、底层逻辑不同

传统数据库的存储引擎为 B+树,包括 ES 的很多 NOSQL 数据库使用的 LSM Tree,对写操作支持更高效。

为什么 Elasticsearch/Lucene 检索可以比 mysql 快?

Mysq 的分词词典(term dictionary)是以 b-tree 排序的方式存储在磁盘上的。检索一个 term 需要若干次的随机访问磁盘操作。

而 Lucene 在分词词典的基础上添加了 term index(以 FST(finite state transducers)形式保存,非常节省内存)来加速检索,term index 以树的形式缓存在内存中。从 term index 查到对应的 term dictionary 的 block 位置之后,再去磁盘上找 term,大大减少了磁盘的随机访问次数。

8、小结

所以,没有最牛逼“一招先,吃遍天”的方案,只有最适合的方案。

适合自己业务场景的才是最好的!

其他欢迎补充。

参考:

[1] https://stackoverflow.com/questions/51639166/elasticsearch-vs-relational-database 

[2] https://zhuanlan.zhihu.com/p/73585202 

[3] https://www.elastic.co/cn/what-is/elasticsearch 

[4] https://www.oracle.com/database/what-is-a-relational-database/ 

[5] https://zhuanlan.zhihu.com/p/33671444

推荐:
我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章