1. DBLE 启动时,读取用户在 rule.xml 配置的 sBeginDate 来确定起始时间
2. 读取用户在 rule.xml 配置的 sPartionDay 来确定每个 MySQL 分片承载多少天内的数据
3. 读取用户在 rule.xml 配置的 dateFormat 来确定分片索引的日期格式
4. 在 DBLE 的运行过程中,用户访问使用这个算法的表时,WHERE 子句中的分片索引值(字符串),会被提取出来尝试转换成 Java 内部的时间类型
5. 然后求分片索引值与起始时间的差,除以 MySQL 分片承载的天数,确定所属分片
1. DBLE 启动时,读取用户在 rule.xml 配置的起始时间 sBeginDate、终止时间 sEndDate 和每个 MySQL 分片承载多少天数据 sPartionDay
2. 根据用户设置,建立起以 sBeginDate 开始,每 sPartionDay 天一个分片,直到 sEndDate 为止的一个环,把分片串联串联起来
3. 读取用户在 rule.xml 配置的 defaultNode
4. 在 DBLE 的运行过程中,用户访问使用这个算法的表时,WHERE 子句中的分片索引值(字符串),会被提取出来尝试转换成 Java 内部的日期类型
5. 然后求分片索引值与起始日期的差:如果分片索引值不早于 sBeginDate(哪怕晚于 sEndDate),就以 MySQL 分片承载的天数为模数,对分片索引值求模得到所属分片;如果分片索引值早于 sBeginDate,就会被放到 defaultNode 分片上
与MyCat的类似分片算法对比
中间件
DBLE
MyCat
分片算法种类date 分区算法按日期(天)分片
两种中间件的取模范围分片算法使用上无差别
开发注意点
【分片索引】1. 必须是字符串,而且 java.text.SimpleDateFormat 能基于用户指定的 dateFormat 来转换成 java.util.Date
【分片索引】2. 提供带状模式和环状模式两种模式
【分片索引】3. 带状模式以 sBeginDate(含)起,以 86400000 毫秒(24 小时整)为一份,每 sPartionDay 份为一个分片,理论上分片数量可以无限增长,但是出现 sBeginDate 之前的数据而且没有设定 defaultNode 的话,会路由失败(如果有 defaultNode,则路由至 defaultNode)
【分片索引】4. 环状模式以 86400000 毫秒(24 小时整)为一份,每 sPartionDay 份为一个分片,以 sBeginDate(含)到 sEndDate(含)的时间长度除以单个分片长度得到恒定的分片数量,但是出现 sBeginDate 之前的数据而且没有设定 defaultNode 的话,会路由失败(如果有 defaultNode,则路由至 defaultNode)
【分片索引】5. 无论哪种模式,分片索引字段的格式化字符串 dateFormat 由用户指定
【分片索引】6. 无论哪种模式,划分不是以日历时间为准,无法对应自然月和自然年,且会受闰秒问题影响
运维注意点
【扩容】1. 带状模式中,随着 sBeginDate 之后的数据出现,分片数量的增加无需再平衡
【扩容】2. 带状模式没有自动增添分片的能力,需要运维手工提前增加分片;如果路由策略计算出的分片并不存在时,会导致失败
【扩容】3. 环状模式中,如果新旧 [sBeginDate,sEndDate] 之间有重叠,需要进行部分数据迁移;如果新旧 [sBeginDate,sEndDate] 之间没有重叠,需要数据再平衡
配置注意点
【配置项】1. 在 rule.xml 中,可配置项为 <propertyname="sBeginDate">、 <propertyname="sPartionDay">、 <propertyname="dateFormat">、 <propertyname="sEndDate">和 <propertyname="defaultNode">
【配置项】2.在 rule.xml 中配置 <propertyname="dateFormat">,符合 java.text.SimpleDateFormat 规范的字符串,用于告知 DBLE 如何解析sBeginDate和sEndDate
【配置项】3.在 rule.xml 中配置 <propertyname="sBeginDate">,必须是符合 dateFormat 的日期字符串
【配置项】4.在 rule.xml 中配置 <propertyname="sEndDate">,必须是符合 dateFormat 的日期字符串;配置了该项使用的是环状模式,若没有配置该项则使用的是带状模式
【配置项】5.在 rule.xml 中配置 <propertyname="sPartionDay">,非负整数,该分片策略以 86400000 毫秒(24 小时整)作为一份,而 sPartionDay 告诉 DBLE 把每多少份放在同一个分片
【配置项】6.在 rule.xml 中配置 <propertyname="defaultNode">标签,非必须配置项,不配置该项的话,用户的分片索引值没落在 mapFile 定义
前提:Windows系统、elasticsearch某版本、curl(windows有curl.exe可以下载,在cmd下输入
curl --version显示了版本信息说明安装好curl了)。MAC、LINUX同理。
启动elasticsearch(在elasticsearch安装目录的bin目录下有elasticsearch.bat,将cmd定位到这个bin目录,输入elasticsearch,可以启动服务,服务端口默认9200)
再打开一个cmd,定位到你想要压入elasticsearch的json格式数据所在的目录,然后执行类似于下面的命令:
curl (-u elastic) -XPOST "localhost:9200/aaa/bbb/_bulk?pretty" --data-binary @abc.json
解释一下:
(1) 如果你设置了elasticsearch的访问权限,那么你需要输入括号里的内容,其中elastic是默认的管理账户名,此时会提示你输入密码。如果你没设置,忽略括号里的内容不用输入,直接curl -XPOST...
(2) -XPOST表示用post方式提交给elasticsearch
(3) localhost可以换成一个IP地址,如果你想要访问某台服务器特定的elasticsearch,前提是那边的elasticsearch的yml配置文件的跨域访问已经被允许了。即在elasticsearch\config\elasticsearch.yml中设置了network.host: 0.0.0.0之类的。
(4) aaa表示elasticsearch的某个“数据库”的名字,bbb表示这个数据库中“某个表”的名字。follow your heart随便改。
(5) _bulk表示批量导入数据。pretty表示用格式化过的json显示结果。--data-binary表示后边的数据要来了要来了,是二进制格式来的。后边@abc.json就是你的json文件名。
成功以后cmd会显示所有压入数据的对应json反馈,很通俗易懂。明明白白的说了哪些是成功压入的,哪些失败了。
我最帅
ElasticSearch的文档写入是以不可修改的形式写入的,一条文档记录一旦被写入其本身就不能被修改了。然而,现实中存在修改这些数据的需求,那怎么办呢?当上帝给你关上一扇门的时候,他一定给你留了一个窗口。虽然我们不能直接修改这个文档本身,但是我们可以通过更新一条 _id 一样的文档,并更新版本号的方式来修改这条记录。我们可以通过三种姿势进行更新。
按顺序执行上面的三条put *** 作,然后查询,我们可以看到相应的查询结果是:
可以看到每次put之后,版本号都会递增1位,同时后面的数据会覆盖之前的数据。
如果我并不想每次都通过这样把全部文档内容再输入一次的形式来,而是希望基于前一个版本的文档进行增减或者修改,那又应该怎么做呢。ES为我们提供了update API。
ES 提供了update API,使我们可以针对某个id的文档,进行局部更新。我们可以使用painless脚本或者直接在update中设置doc字段的参数的形式进行。
考虑以下文档。
如果我想修改年龄的话,可以有两种方法来进行:
两种方法都可以将age修改为14。
如果我们想增加一个属性”weight“该怎么做呢?
如果我们想移除”sex“字段,这种情况下,只能用painless脚本了。
这三种情况是最基本的,还有一些其他用法,可以参考update的官方文档。
https://www.elastic.co/guide/en/elasticsearch/reference/7.2/docs-update.html
需要注意,使用update api只能使用ES索引的内置版本号,如果强行指定版本号,update *** 作会发生错误。
上面两种方法需要指定文档id,ES还提供了基于search的update API,及update_by_query API。
update_by_query API的第一种使用方式是什么都不指定,直接使用。
我一开始看到这种用法,觉得特别疑惑,因为这样做除了更新了版本号,似乎也没有什么变化。后来读了官方文档才了解到这种用法的含义。
在设置索引配置的时候,有一个 dynamic 属性,如果设置成false的话,如果碰到没有事先映射过的字段,是不会做索引,搜索不到的。需要注意,是搜索不到,但不是没有存储,这个数据还是在的。那怎样能使得这个数据能够被索引到呢,这个时候update_by_query就能排上用场了。我们先更新这个索引的mapping,然后调用update_by_query API。对应的文档会重新索引一次,之前不能搜索的字段就变得能够被搜索到了。
和query API一样,update_by_query也可以拥有一个query块,作为update的条件出现:
同样也可以使用painless进行update *** 作。
在进行update_by_query的时候,还可以指定pipeline,使用pipeline的处理器处理文档。
还有一些其他用法,可以参考官方文档:
https://www.elastic.co/guide/en/elasticsearch/reference/7.2/docs-update-by-query.html
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)