Elasticsearch不支持事务有什么好的弥补方案_elasticsearch 事务-优快云博客

Elasticsearch不支持事务有什么好的弥补方案

事务的核心概念
Elasticsearh不支持事务
Elasticsearch支持的场景
Elasticsearch不支持的场景
系统设计数据库选型考量
数据库如何与Elasticsearch结合使用？

事务的核心概念

如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下ACID四个特性：

原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，
一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

Elasticsearh不支持事务

一些支持ACID数据存储的数据库包括：Postgres, SQLite, Oracle, MySQL (with InnoDB), and MongoDB (4.0+)，不包括Elasticsearch。

Elasticsearch的底层技术是Lucene，Lucene是追求速度而非冗余的信息检索技术。Lucene具有完全不同的体系结构，可以提供极快的性能，但代价是更容易受到数据丢失的影响。

丢失数据有很多种方式，如果需要的话，你需要重新创建数据。没错，Elasticsearch有一个快照/恢复功能，但是这个过程只会在数据丢失的情况下部分恢复。除非您在其他系统对数据有额外的备份存储，否则最新快照和中断之间的更新将会丢失。快照/恢复在分裂大脑的情况下也无济于事，因为没有用于协调每个分区的更新的机制。更新将会丢失。

Elasticsearch支持的场景

数据安全性场景：ElasticSearch的shard支持replication，一份数据可以保存多份，如果某一台机器挂掉了，数据在其他机器上还有，不用担心丢失。
访问安全性场景：随着x-pack开源，ElasticSearch支持验证，不用担心未授权的访问。或者借助第三方search-guard等。
迁移特性：ElasticSearch支持众多的插件，在和其他开源系统之间导入，导出数据都很简单。
数据完整性：ElasticSearch支持保存数据原文。

Elasticsearch不支持的场景

不支持事务，如前所述。

类似数据库中通过外键的复杂的多表关联操作，Elasticsearch天生支持不足。

读写有一定延时，写入的数据，最快1s中能被检索到。
实时性的官网解读：

In Elasticsearch, this lightweight process of writing and opening a
new segment is called a refresh. By default, every shard is refreshed
automatically once every second. This is why we say that Elasticsearch
has near real-time search: document changes are not visible to search
immediately, but will become visible within 1 second.
默认的刷新频率设置是1秒，也就是说文档从Index请求到对外可见能够被搜到，最少要1秒钟，强制的，你的网络和CPU再快也不行。这么做是Lucene为了提高写操作的吞吐量而做出的延迟牺牲，当然这个设置是可以手动调整的，但是并不建议你去动它，会极大地影响搜索性能。不同的应用对实时性的定义并不一样，这取决于你的需求。

ES不是关系数据库，因此如果您的数据会受益于外键等等，那么ES不是您主要数据存储的好选择。