ElasticSearch第四节分布式文档存储.docVIP

第四章 在上一章，我们看完了所有的存数据和获取数据的方法，但是我们掩饰了很多技术细节，包括这个数据是怎么从集群中分布和抓取的。这样的分离是告诉你，你不需要关注Elasticsearch是如何工作的. 在这一章，我们将潜入这些技术内部，技术细节将帮你理解在一个分布式系统中数据时如何存储的. 内容警告： 这些下面的内容都取决于你的兴趣，不要求你必须理解和记住所有细节，这些主要对哪些更高级应用者服务的.读取这个部分，了解Elasticsearch如何工作，知道一些信息，以便将来更好的应用。如果看不懂,也不要被这些细节所压制。 将文档路由到从库中 当你index一个文档的时候，它被存到一个单一的分片中。Elasticsearch如何知道这个文档属于哪个节点？当我们create一个新的文档，Elastic如何知道它该存到分片1还是分片2上？ 这个过程不能随机，因为我们可能需要在将来重新获取这个文档。实际上，它决定于一个简单的规则。 shard = hash(routing) % number_of_primary_shards 分析上式， routing值是一个任意string，默认为文档的_id但是也可以手动给一个值进去。这个routing值通过hash函数传递进去，用它来对当前文档中所有基本的分片的总数求余，这个余数将在0-(number_of_primary_shards-1)之间，并且给我们返回一个可用的分片。 这就解释了为什么number_of_primary_shards值永远都在文档库建立的时候设置，并且还不能变化，假如number_of_primary_shards在将来发生变化，所有的原先的routing值都将失效，文档也将找不到。(有点不懂) 所有的文档API(get, index, delete, bulk, update and mget)同意一个routing值被用来设置一个文档-分片映射。一个自定义的routing值 可以被用来保证所有的相关文档，例如所有的文档都属于同一个用户，并且被存储到相同的分片中。接下来将要讨论我们为什么要这么做。 主从库之间是如何通信的： 方便解释，我们假设有一个集群有3个节点。它包含一个blogs文档，里面有两个初始分片。每个分片都有两个备份，每个分片的备份永远都不会被 分配到同一个节点。所以我们的集群看起来像（此处插图） 一个集群有3个节点，并且一个index(此处插图) 我们可以发送我们的请求到集群的任意一个节点。每个节点都完全有能力处理任何请求，每个节点都知道文档在集群中的具体位置。所以可以转发请求到 对应的节点，在下面的例子中我们将发送所有的请求到Node1,我们把它称作requesting node 建议：当发送请求时，可以循环集群中所有节点，从而达到初始化的目的。 创建、索引、删除文档 创建，索引和删除都是写操作，都必须一次性全部成功在当前分片上当它可以被copy到别的分配的分片上时。 （此处插图）下面，将列举如何成功完成create,index,delete一个文档并实现备份的完整必要步骤 1.客户端发送一个create, index or delete请求到Node_1 2.节点通过它的文档的_id(shard = hash(routing) % number_of_primary_shards)来决定文档属于分片0，然后转发请求到节点3，节点3上包含着分片0（备份） 3.Node3自行请求在分片0上，假如成功它会转发请求到平行的备份节点和节点2上。当备份节点2和1都返回成功标识，Node3返回成功标识给请求它的那个节点1上，然后由节点1返回成功信息给客户端。这时，客户端接收到成功的信息响应。这个文档的变化发生在原始的和用于备份的节点上，并且是安全的. 当然也有一些参数可以让你来设置请求的一些具体信息从而影响该请求过程，有可能提高了它的安全性能。这些选项都很少使用，因为Elasticsearch本身就很快，但是它们在这里解释了完整性。 +++replication 这个备份缺省值为sync,它导致原始的分片必须等待直到所有的备份分片返回成功标识时才能给客户响应。 假如你把replication(备份)设置为async，只要请求在原始分片上执行它将迅速返回成功，当然它也会转发请求到备份分片上，但你不知道是否成功执行。 建议设为缺省sync，因为它有可能使Elasticsearch加载过多的请求却不去等待它的响应。 +++completion 一致性 默认情况下，在进行一个写操作之前，原始分片需要保证一定数量的备份分片可用，备份分片可以是另一个原始分片或者专门的备份分片，这是为了防止写入数据到错误地方