课件及 Demo 下载地址

作者回复: 这是一个很好的问题。我贴一段es文档里的描述，希望对你有一定的帮助 Why doesn’t Elasticsearch support incremental resharding?edit Going from N shards to N+1 shards, aka. incremental resharding, is indeed a feature that is supported by many key-value stores. Adding a new shard and pushing new data to this new shard only is not an option: this would likely be an indexing bottleneck, and figuring out which shard a document belongs to given its _id, which is necessary for get, delete and update requests, would become quite complex. This means that we need to rebalance existing data using a different hashing scheme. The most common way that key-value stores do this efficiently is by using consistent hashing. Consistent hashing only requires 1/N-th of the keys to be relocated when growing the number of shards from N to N+1. However Elasticsearch’s unit of storage, shards, are Lucene indices. Because of their search-oriented data structure, taking a significant portion of a Lucene index, be it only 5% of documents, deleting them and indexing them on another shard typically comes with a much higher cost than with a key-value store. This cost is kept reasonable when growing the number of shards by a multiplicative factor as described in the above section: this allows Elasticsearch to perform the split locally, which in-turn allows to perform the split at the index level rather than reindexing documents that need to move, as well as using hard links for efficient file copying. In the case of append-only data, it is possible to get more flexibility by creating a new index and pushing new data to it, while adding an alias that covers both the old and the new index for read operations. Assuming that the old and new indices have respectively M and N shards, this has no overhead compared to searching an index that would have M+N shards.

作者回复: 视频中发送到9200，我也没在开发环境中指定dedicated的节点。所以这个节点既是master也是data，当然肯定也是coordinating节点。 在生产环境，你可以设置dedicate的 coordinate节点，发查询到这些节点。不建议直接发送请求到master节点，虽然也会工作，但是大量请求发送到master，会有潜在的性能问题

作者回复: 你的理解没错，视频里要是体现出来，会使得表达更为严谨

作者回复: 对。所以过多的副本会降低索引的速度

作者回复: 会到主分片或者副本分片上查询，所以，不排除副本分片没有完全同步完成导致数据的不完全一致

作者回复: 你可以一个个启动，先看第一个是否启动，再启动第二个，看 _cat/nodes里面能否看到新加入的节点

作者回复: 你尝试着docker-compose down -v 再启动一下吧