elasticsearch读写文档概述

data replication model定义 (该model基于primary-backup model )
ES的每个index都被分成多个shards 每个shard可能含有多个copies(备份) 这些copies被称为一个 replication group当文件发生增加或删除操作时,replication group必须同步保存,否则再读取不同的copies是会得到不同的结果.

**primary-backup model定义 **
这个模式下,将replication group中的一个单独的copy当做primary shard.其他copies 被称为replica shards;primary shard 是所有索引操作的主记录点. primary shard负责验证操作的有效性和正确性.一旦一个操作在primary shard上生效了,那么这个primary shard就要负责将这个有效的操作复制到其他replica shards上.
Basic write model
Elasticsearch中的每个索引操作首先基于document ID通过routing定位到replication group .一旦replication group 被确定,这个操作就会发送到这个group的primary shard.而primary shard 负责验证这个操作并将其传送给其他replicas.由于replicas 可能不在线, primary不一定要传送给所有的replicas. 而是由Elasticsearch维护一个需要接受这个操作的shard copies清单. 这个清单被称为in-sync copies 并且由master node维护.

primary shard遵循如下流程:

1. 验证操作,如果操作无效则拒绝
2. 执行该操作. 这步中胡对field的内容进行验证,并在条件不满足时拒绝该操作(Example: a keyword value is too long for indexing in Lucene).
3. 发送该操作到当前in-sync copies set的每个replica.如果存在多个 replicas,会平行进行.
4. 一旦所有replicas 都成功执行了该操作并响应给了primary,primary 会通知client这个请求成功了.

操作失败处理
case1: 如果primary无法处理这个操作,那么拥有该primary的节点会给master发送消息,这个索引操作会等待一段时间默认一分钟,以便master去任命一个replica成为新的primary.然后这个操作会有新的primary来处理.(这种情况主要发生在拥有primary的节点与集群因为网络原因而孤立的情况下)

case2: 如果primary成功的处理了index操作,in-sync replica set中的一个replica 没有成功接收改操作. 那么primary会给master发送一个消息,请求将有问题的replica从in-sync replica set中删除.

elasticsearch中常用的API分类如下：

• 文档API: 提供对文档的增删改查操作
• 搜索API: 提供对文档进行某个字段的查询
• 索引API: 提供对索引进行操作，查看索引信息等
• 查看API: 按照更直观的形式返回数据，更适用于控制台请求展示

文档类API

Index API

通过index API 可以添加获更新某种类型的JSON文档到特定的index ,并使之可搜索. 例如在 "twitter" index, type "tweet" , id =1 下新增一个JSON文档

PUT twitter/tweet/1
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}

以上操作的结果为:

{
    "_shards" : {
        "total" : 2,
        "failed" : 0,
        "successful" : 2
    },
    "_index" : "twitter",
    "_type" : "tweet",
    "_id" : "1",
    "_version" : 1,
    "created" : true,
    "result" : created
}

_shards展示有关索引操作的replication process 信息.
total表示shard copies (primary and replica shards)的数量
successful表示执行该操作成功的shard数量
failed 一个包含replication 相关错误的数组
successful至少1才能任务改index操作是成功了的.

注意:当一个 index 操作成功返回时,并不是所有replica shard都开始了该操作,(默认情况下只有primary是必须的,但是这个可以设置)也就是说,total 会等于 设置的number_of_replicas值,successful 会等于开始该操作的shards数.

当一个index不存在的时候,默认自动创建相应的index和type 相应的mapping也会自动添加到特定type的mapping definition下.

如果不想自动添加则进行如下设置:
取消自动创建index: setting action.auto_create_index to false
取消自动创建mapping: setting index.mapper.dynamic to false

自动创建index还可以自定义配置,如:

action.auto_create_index to +aaa*,-bbb*,+ccc*,-*
(+ 表示允许创建, - 表示不允许).

版本号会作为index API请求响应的一部分