前言:
学习路径:https://www.bilibili.com/video/av45584656 码家学院的视频
这次是记录ElasticSearch6 与kibana的结合的简单使用
也就是增删改查
目录
1.新增索引
2.新增内容
3.修改数据
4.删除数据
5.版本控制
###创建索引
PUT /guodagou
说明是创建成功了
可以查询一下
GET /guodagou
可以看到的得到索引guodagou的一些参数 比如 映射,创建时间 分页 uuid 以及名称等
顺序是 /索引/类型/id
比如在guodagou里添加一个叫guosangou的用户
PUT /guodagou/user/1
{
"name":"guosangou",
"sex":"1",
"age":"12"
}
这个是说 在 索引guodagou的文档 user 中添加一个id为1的数据
可以看到右边是id为1 _version是指修改次数 这个和乐观锁机制 也是 es 的版本控制 有关
和新增是一样的 只不过是 如果有但当前数据的话就是修改已有的数据
PUT /guodagou/user/1
{
"name":"guosangou",
"sex":"2",
"age":"22"
}
这里可以看到 版本控制变化了成为2了 说明进行了修改
DELETE /guodagou/user/1
看到版本控制也改了 然后结果是 删除的
1.为什么要进行版本控制
为了保证数据再多线程操作下的准确性
2.悲观锁和乐观锁
悲观锁:假设会发生并发冲突,屏蔽一切可能违反数据准确性的操作
乐观锁:假设不会发生并发冲突,只在提交操作是检查是否违反数据完整性。
3.内部版本控制和外部版本控制
内部版本控制:_version自增长,修改数据后,_version会自动的加1
外部版本控制:为了保持_version与外部版本控制的数值一致
使用version_type=external检查数据当前的version值是否小于请求中的version值
关于版本控制举个例子:
版本号机制
一般是在数据表中加上一个数据版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读取到的version值为当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。
举一个简单的例子(原文链接):
假设数据库中帐户信息表中有一个 version 字段,当前值为 1 ;而当前帐户余额字段( balance )为 $100 。
操作员 A 此时将其读出( version=1 ),并从其帐户余额中扣除 $50( $100-$50 )。
在操作员 A 操作的过程中,操作员B 也读入此用户信息( version=1 ),并从其帐户余额中扣除 $20 ( $100-$20 )。
操作员 A 完成了修改工作,将数据版本号加一( version=2 ),连同帐户扣除后余额( balance=$50 ),提交至数据库更新,此时由于提交数据版本大于数据库记录当前版本,数据被更新,数据库记录 version 更新为 2 。
操作员 B 完成了操作,也将版本号加一( version=2 )试图向数据库提交数据( balance=$80 ),但此时比对数据库记录版本时发现,操作员 B 提交的数据版本号为 2 ,数据库记录当前版本也为 2 ,不满足 “ 当前最后更新的version与操作员第一次的版本号相等 “ 的乐观锁策略,因此,操作员 B 的提交被驳回。
这样,就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
直接操作一下就知道了:
我先新建一个
id=2 叫guoergou的人
接着我们去修改一下年龄和性别 然后加上版本控制
模拟这个时候又一个人也操作当前的数据 但是后台版本已经为2了 就抱错了说版本不一致 会驳回
我们来查询下 看是哪个存进去了
很明显第一个存对了 第二个没成功
暂时记录到这 这是通过kibana简单操作 elasticsearch