您当前的位置: es里的文档是不可改变的，我们不能改变它们。如果你想更新一个已经存在的文档，我们重新索引或者替换它，可以使用同样的API。PUT /website/blog/123{ "title": "My first blog entry",
"text": "I am starting to get the hang of this...",
"date": "2014/01/02"
}响应如下：可以看到已经修改了_version字段。{ "_index" : "website",
"_type" : "blog",
"_id" : "123",
"_version" : 2,
"created": false
}created标识为false,表明已经有这么一个index,type,ID的组合存在过。es已经标记了老的文档为删除，并且增加了一个全新的文档。老版本的文档不会立刻消失，尽管你已经不能再访问它。es会后台删除标记为删除的文档。后面将讨论更新API,可以部分更新文档。看起来像是更新部分文档，实际上仍然是执行了一样的操作。1 从老的文档中检索JSON2 改变它。3 删除老文档4 索引新的文档。也就是说依靠老的文档来获得新的文档，然后删除老文档，索引新文档。唯一的不同在于：更新API在一次请求内完成。而不需要用户get一次加上index一次。http://my.oschina.net/qiangzigege/blog/264292
我们怎么能够保证，当索引一个文档，我们创建了一个全新的新文档而不是覆盖一个已经存在的文档。记得组合(_index,_type,_id)唯一标示了一个文档，最容易的方式来检验我们的文档是新的，就是让es自己增加一个id.使用post.POST /website/blog/{ ... }尽管如此，如果我们已经有了一个_id想使用，我们需要告诉es：它应该接受我们的请求当这个 ID没有被使用时，有两种方法，自己视方便而定。1)PUT /website/blog/123?op_type=create{ ... }2)PUT /website/blog/123/_create{ ... }如果请求成功的创建了新的文档，es将会返回之前一样的信息，http返回码为201 Created.另外一方面，如果一个文档已经用了这个ID，es返回409码表明冲突。可能的错误信息如下：{ "error" : "DocumentAlreadyExistsException[[website][4] [blog][123]:
document already exists]",
"status" : 409
}
|
http://my.oschina.net/qiangzigege/blog/264299
删除文档：DELETE /website/blog/123如果文档找到了，es返回一个200 OK码，如下：注意，_version数字已经改变。{ "found" : true,
"_index" : "website",
"_type" : "blog",
"_id" : "123",
"_version" : 3
}如果文档没找到，返回404.{ "found" : false,
"_index" : "website",
"_type" : "blog",
"_id" : "123",
"_version" : 4
}尽管文档不存在，没有找到它，_version仍然增加。这是内部机制，保证多节点的变动按照顺序执行。如更新文档时所说，删除一个文档不会立刻从磁盘删除文档，仅仅标记为删除。es将在你索引别的文档时后台删除标记为删除的文档。http://my.oschina.net/qiangzigege/blog/264305
当使用index API来更新文档时，我们读取原始文档，做出修改，重新索引整个文档，一口气完成。最后一次的索引请求胜出，如果某人之前做出了文档改变，它的改变将会丢失。通常，这不是一个问题，也许我们的主数据存储时一个关系型数据库，我们只是把数据复制到了ES来让它可以搜索，也许基本不可能有两个人同一时间改变了同一个文档，或者文档改变的丢失对业务来说无关紧要。但是，有的时候，丢失改变非常关键，想象一下，我们正在使用es来存储在线商店里的库存的物品数量，每次我们卖出了一个，我们减少数量。有一天，管理者决定卖，突然，我们每秒钟卖出一些物品，想象两个web进程，同时运行，都在处理同一个物品。图7：没有并发控制的结果。web_1做出的数量改变已经丢失，因为web_2不知道它的数据失效了，结果就是：我认为我们有更多的物品，实际上不然，这会让客户失望。操作越频繁，或者读和更新操作之间的时长越大，丢失越会发生。有两种方法来保证并发的正确性。悲观并发控制策略：作为已经被关系型数据库广泛使用的策略，假设冲突很容易发生，锁住相关资源来预防竞争，典型的例子就是：在读数据之前，锁住一行，保证当前线程可以做出改变。乐观并发控制策略这是es使用的策略，假设冲突不太可能发生，不阻止操作。尽管如此，如果在读和写之间，数据已经改变，更新将会失败。这得由应用自己决定如何解决这个问题，比如：可以使用新的数据重新更新，或者报告失败给用户。http://my.oschina.net/qiangzigege/blog/264322
es是一个分布式的系统，当文档创建，更新或者删除，新版本的文档必须复制到其它节点，es同时也是异步和并发的，这意味着这些备份请求同时发送，并且可能乱序到达目的地，这就需要一种策略来保证旧版本的文档不会覆盖新版本的文档。当我们讨论索引，get/delete请求，我们指出：每个文档有一个_version字段，当文档改变时
这个字段自增，es使用这个数字来保证改变的应用按照正确的顺序来做，如果一个旧的文档在新文档之后来到，简单的被丢弃。我们可以通过_version字段来受益，保证冲突不会导致数据丢失。我们通过指定文档的版本号。如果版本号不是最新的，请求将会失败。先创建一个文档。PUT /website/blog/1/_create{ "title": "My first blog entry",
"text": "Just trying this out..."
}响应体告诉我们这是一个新创建的文档，版本号为1现在想象一下，我们需要编辑这个文档，我们下载这个文档，改变，保存。先检索这个文档。GET /website/blog/1响应体如下：{ "_index" : "website",
"_type" : "blog",
"_id" : "1",
"_version" : 1,
"found" : true,
"_source" : {
"title": "My first blog entry",
"text": "Just trying this out..."
}
}当我们尝试修改保存改变，我们指定了版本号。PUT /website/blog/1?version=1 { "title": "My first blog entry",
"text": "Starting to get the hang of this..."
}请求成功，响应体告诉我们版本号变为2.{ "_index": "website",
"_type": "blog",
"_id": "1",
"_version": 2
"created": false
}尽管如此，如果我们再去发同样的请求，也就是version=1,es将返回一个409冲突。响应体如下：{ "error" : "VersionConflictEngineException[[website][2] [blog][1]:
version conflict, current [2], provided [1]]",
"status" : 409
}告诉我们，目前的版本号是2，但是我们想要更新版本号1的文档。我们可以告诉用户某人已经改变了文档，然后应该在重新尝试前看一下改变。我们也可以重新检索最新文档再改变。所有的API(update/delete)接收一个版本号参数，容许我们应用乐观并发控制。
使用外部系统的版本号一个常用的设置是：使用其它数据库作为主数据存储，es让数据可搜索，也就是说，所有对主数据库的改变需要复制到es.如果有多个进程涉及到数据同步，你将会碰到并发问题。如果你的主数据库已经有一个版本号，或者时间戳之类，你可以使用这些值，通过添加version_type=external.版本号必须是整数，大于0，小于9.2e+18 。这种方式跟内部的版本号有点区别：之前是判断es里的版本号和用户提交的参数是否一致，现在是比较目前的版本号是否比参数小，如果请求成功，外部的版本号就成功存储。外部的版本号不仅可以在索引和删除一个文档时指定，创建新文档时也可以指定。比如说，创建一个新的blog文档，带有一个版本号5PUT /website/blog/2?version=5&version_type=external{ "title": "My first external blog entry",
"text": "Starting to get the hang of this..."
}响应体：{ "_index": "website",
"_type": "blog",
"_id": "2",
"_version": 5,
"created": true
}更新PUT /website/blog/2?version=10&version_type=external{ "title": "My first external blog entry",
"text": "This is a piece of cake..."
}响应体：{ "_index": "website",
"_type": "blog",
"_id": "2",
"_version": 10,
"created": false
}如果你重新执行，会失败，因为版本号不够大。http://my.oschina.net/qiangzigege/blog/264346
之前的更新整个文档时，我们说了：
更新文档的方法是检索，修改，然后重新索引。这是对的。尽管如下，使用更新API,我们可以做部分更新操作，比如增加一个计数器的值。我们同时也说，文档不可改变，它们不能被改变，仅仅是替换，更新API必须遵循这个规则。对外显示的是：我们是部分更新文档，内部来说，更新API执行同样的 检索-更新-重新索引 的过程，不同之处在于，这个过程在一个分片内部发生，避免多个请求造成的负载。通过减少检索和重新索引的间隔，也可以减少冲突的可能性。举个例子，POST /website/blog/1/_update{ "doc" : {
"tags" : [ "testing" ],
"views": 0
}
}响应如下：{ "_index" : "website",
"_id" : "1",
"_type" : "blog",
"_version" : 3
}检索结果：{ "_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
}
}新的字段已经被添加。 http://my.oschina.net/qiangzigege/blog/264361