Elasticsearch 局部更新

就像在 Updating a whole document 中所说的一样 更新 document 的步骤就是检索 修改 插入整个 document 然而使用 update 就能局部更新 就像在一个请求里增加一个计数器一样 以前说过 document 是不可变的 不能被修改 只能被替换 update 也必须遵守这个规则 在外部看来是局部更 新的 在内部 update 依然执行了检索 修改 重新插入这个流程 不同的是这个过程是发生在 shard 中 因 此避免了多次网络请求的开销 通过减少检索和重新插入的时间 降低了来自于其他线程的访问导致的数据冲突的可 能性 最简单的 update 格式就是请求体中接受部分的 document 作为 doc 的参数 这个参数的值会和已经存在的 document 合并 已经存在的 field 将会被重写 新的 field 将会被添加 例如 增加一个 tags 字段和一个 views 字 段到 blog 中 POST website blog 1 update doc tags testing views 0 如果成功将会相应如下数据 index website id 1 type blog version 3 检索这个 document 注意一下 source 字段 index website type blog id 1 version 3 found true source title My first blog entry text Starting to get the hang of this tags testing views 0 标注 1 和 2 表示就是局部更新的内容 使用 script 进行局部更新 我们会在 Scripting when you need more TODO 更详细的介绍 script 但是现在 来说我们已经足够了解 script 在 ES 中的几个合适的用武之地 已满足某些不被 API 直接支持的但是用户需要的动作 默认的 script 语言是 MVEL 但是 ES 也是支持 JavaScript Groovy 和 Python 的 MVEL 是简单的 快速的 基 于 jiava 的动态脚本语言 语法类似于 JavaScript 你可以在 Elasticsearch scripting docs 和 MVEL website 了 解更过关于 MVEL 的内容 script 能用作 update API 用来修改 source 的内容 这被称为一个更新的脚本 ctx source 例如 可以使用 script 增加这个 views 的数目 POST website blog 1 update script ctx source views 1 我们也能使用 script 给 tags 数组增加一个元素 在这个例子中我们指定新的 tag 作为参数而不是在 scritp 中硬编码 这个方式允许 ES 在以后可以重用这个参数 并且不需要每次从新编译这个 script POST website blog 1 update script ctx source tags new tag params new tag search 最后两个的请求相应如下 index website type blog id 1 version 5 found true source title My first blog entry text Starting to get the hang of this tags testing search views 1 标记 1 表示 search 这个元素已经追加到 tags 的数组中 标记 2 表示 views 的数量已经增加了 通过设置 ctx op 为 delete 我们甚至能通过 script 删除一个 document POST website blog 1 update script ctx op ctx source views count delete none params count 1 注 以上执行在 curl 下失败 在 head 中成功 更新一个或许不存在的 document 如果我们需要在 ES 中存储一个页面访问量的计数器 conter 每次用户访问这个页面 我们都对这个页面增加一个数 但是增加这个 counter 之前要确定这个 counter 是已经存在的哦 如果要更新一个不存在的 document update 将 会出错 可以使用 upsert 参数来解决这个问题 如果指定的 document 不存在 就创建一个 POST website pageviews 1 update script ctx source views 1 upsert views 1 首次执行这个请求 这个 upsert 数值做为一个新的 document 被插入 被初始化为 1 接下来的执行将会对 views 直接增加 1 更新和冲突 在本章节的说明部分 在检索和重新插入的间隔越小 冲突的机会就越小 但并不是完全没有冲突 依然有可能一个 线程在另外一个线程执行 update 之前执行了 reindex 的动作 为了防止这个事情的发生 updateAPI 在执行检索的时候会检查记录 document 的 version 的数量 并且在执行重 新插入之间把 version 传递给其他线程的 index 的请求 如果另外的线程在检索 重新插入之间修改了 document 这个 version 就不会和 update 记录的 version 匹配导致 update 失败 对于很多情况下的局部 update 来说 update 并不关心一个 document 是否已经被修改 例如 两个线程同时增加 页面的访问数量 以什么样的顺序发生 update 都是无所谓的 即使冲突发生了 唯一要做的事情就是重新执行 update 就行了 如果你在请求时候设置了retry on conflict参数并设定重复执行的次数 默认是0 这个重新执 行就会自动进行 POST website pageviews 1 update retry on conflict 5 script ctx source views 1 upsert views 0 标记 1 表示在成功更新之前尝试五次 update 这个设置对不强调顺序的多个线程无序的增加也个页面访问数量的值是很有效的 但是有另外的情况 就是更新的次