Elasticsearch 版本控制version
Elasticsearch版本控制
1、为什么要进行版本控制
日常生产环境中，会频繁的对数据进行相关的操作，那么如何保证数据在多线程操作（有两个或两个以上的人在操作修改同一个数据）情况下的准确性，所以就引入了一个版本控制的概念
并发访问
2、悲观锁和乐观锁
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
理解：多线程操作数据的可能性非常大，当一个线程去修改某个数据库的时候，先锁定数据库，只有给这个数据库加了锁的线程，才有权修改数据，等修改完成，解锁，然后其他线程才能进行相关的操作，这种锁机制比较安全，保证数据是准确实时的，悲观锁一般是在并发量很小的情况下使用，如果并发量非常大，使用悲观锁，会造成性能问题，加锁，解锁，会造成性能阻塞
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性（Elasticsearch使用的是乐观锁）
理解：如果有多个线程正在修改同一条数据，使用乐观锁的结果就是，后面更改数据的线程会更改失败，并且会得到一个错误的返回，后面的这个线程需要再次校验数据，获取数据的最新状态才能更改成功。所以使用乐观锁，会增加大量线程读取数据对象的次数（因为需要不停的刷新、获取数据对象的最新状态，也就是查询会比较多，并且存在读取数据不实时的情况（脏读））
3、内部版本控制和外部版本控制
内部版本控制：
_version自增长，修改数据后，_version会自动加1
# Version版本控制
PUT /library/books/1
{
"title": "Elasticsearch": The Definitive Guide",
"name": {
"first": "Zachary",
"last": "Tong"
},
"publish_date":"2015-02-06",
"price":"59.99"
}
GET /library/books/1
POST /library/books/1/_update
{
"doc": {
"price": 10
}
}
#如果你想通过如下方式更新数据，必须保证参数中的version是和document的版本一致，否则报错。
POST /library/books/1/_update?version=3
{
"doc":{
"price": 15
}
}
外部版本控制：
为了保持_version与外部版本控制的数值一致，使用version_type=external检查数据当前的version值是否小于请求中的version值
何时使用外部版本控制机制：Elasticsearch的查询非常强大，因此很多系统应用的查询都是交给Elasticsearch的，但是它的主体数据库可能还是传统的关系型数据库，比如oracle，mysql，因此系统开发者，会把oracle或者mysql的数据同步到Elasticsearch当中，而oracle这样的数据库有自己的版本控制机制，比如带有时间戳的字段，数据同步到Elasticsearch之后，希望Elasticsearch也可以使用时间戳的字段进行版本控制，所以就出现了外部版本控制机制。
#外部版本控制
#
PUT /library/books/1?version=5&version_type=external
{
"title": " Elasticsearch": The Definitive Guide ",
"name": {
"first": "Zachary",
"last": "Tong"
},
"publish_date":"2015-02-06",
"price":"20"
}
PUT /library/books/1?version=6&version_type=external
{
"title": "Elasticsearch:The Definitive Guide",
"name": {
"first": "Zachary",
"last":"Tong"
},
"publish_date":"2015-02-06",
"price":"25"
}
GET /library/books/1
