Elasticsearch中的碎片和副本

索引被分解成碎片，以便分布它们和扩展它们。

副本是分片的副本，在节点丢失时提供可靠性。这个数字经常会引起混淆，因为replica count == 1意味着集群必须有可用的碎片的主副本和复制副本才能处于绿色状态。

为了创建副本，您的集群中必须至少有2个节点。

我将试着用一个真实的例子来解释，因为你得到的答案和回复似乎对你没有帮助。

当您下载并启动elasticsearch时，您将创建一个elasticsearch节点，该节点将尝试加入现有集群(如果可用)或创建一个新集群。假设您用一个节点创建了自己的新集群，就是您刚刚启动的那个节点。我们没有数据，因此需要创建一个索引。

当您创建索引时(当您索引第一个文档时也会自动创建索引)，您可以定义它将由多少个碎片组成。如果您没有指定一个数字，它将有默认的碎片数量:5个主。这是什么意思?

这意味着elasticsearch将创建5个包含你的数据的主分片:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

每次索引一个文档时，elasticsearch将决定哪个主分片应该保存该文档，并在那里索引它。主碎片不是数据的副本，它们就是数据本身!拥有多个分片确实有助于在一台机器上利用并行处理的优势，但关键是，如果我们在同一个集群上启动另一个elasticsearch实例，那么分片将以均匀的方式分布在集群上。

例如，节点1将只保存三个分片:

 ____    ____    ____
| 1  |  | 2  |  | 3  |
|____|  |____|  |____|

由于剩下的两个分片已经移动到新启动的节点:

 ____    ____
| 4  |  | 5  |
|____|  |____|

为什么会发生这种情况?因为elasticsearch是一个分布式搜索引擎，通过这种方式，您可以使用多个节点/机器来管理大量数据。

每个elasticsearch索引至少由一个主分片组成，因为数据存储在主分片中。但是，每个碎片都是有代价的，因此，如果你只有一个节点，而且没有可预见的增长，那就坚持使用一个主碎片。

另一种类型的碎片是副本。默认值为1，这意味着每个主分片将被复制到另一个包含相同数据的分片。副本用于提高搜索性能和故障转移。复制分片永远不会被分配到与相关主数据所在的同一节点上(这很像将备份数据放在与原始数据相同的磁盘上)。

回到我们的例子，对于1个副本，我们将在每个节点上拥有整个索引，因为将在第一个节点上分配2个副本碎片，并且它们将包含与第二个节点上的主碎片完全相同的数据:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4R |  | 5R |
|____|  |____|  |____|  |____|  |____|

第二个节点也一样，它将包含第一个节点上主碎片的副本:

 ____    ____    ____    ____    ____
| 1R |  | 2R |  | 3R |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

使用这样的设置，如果一个节点宕机，您仍然拥有整个索引。复制分片将自动成为主分片，即使节点故障，集群也能正常工作，具体如下:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

既然你有"number_of_replicas":1，副本就不能再被分配了，因为它们永远不会被分配到主节点所在的同一节点上。这就是为什么你会有5个未分配的分片，副本，集群状态将是YELLOW而不是GREEN。没有数据丢失，但它可以更好，因为一些碎片无法分配。

一旦备份了离开的节点，它将再次加入集群，并再次分配副本。第二个节点上的现有分片可以加载，但它们需要与其他分片同步，因为写操作很可能发生在节点关闭时。在此操作结束时，集群状态将变为GREEN。

希望这能为你澄清一些事情。

如果你真的不喜欢看到它变黄。您可以将副本的数量设置为0:

curl -XPUT 'localhost:9200/_settings' -d '
{
"index" : {
"number_of_replicas" : 0
}
}
'

请注意，您应该只在本地开发框上执行此操作。

在ElasticSearch中，在顶层，我们将文档索引为索引。每个索引都有若干个分片，这些分片内部分布数据，而这些分片内部存在Lucene段，这是数据的核心存储。因此，如果索引有5个分片，这意味着数据已经分布在各个分片上，并且分片中存在不同的数据。

观看解释ES核心的视频 https://www.youtube.com/watch?v=PpX7J-G2PEo < / p >

关于多个索引或多个碎片的文章 弹性搜索，多个索引vs不同数据集的一个索引和类型? < / p >

索引被分解成碎片，以便分布它们和扩展它们。

副本是碎片的副本。

节点是弹性搜索的一个运行实例，属于一个集群。

集群由一个或多个具有相同集群名称的节点组成。每个集群都有一个由集群自动选择的主节点，如果当前的主节点发生故障，可以将其替换。

碎片:

作为分布式搜索服务器，ElasticSearch使用名为 . Shard将索引文档分布到所有节点 index可以潜在地存储大量的数据 超出single node的硬件限制 例如，十亿个文档的单个索引占用1TB的空间 磁盘空间可能不适合单个节点的磁盘，也可能太适合 . . 为了解决这个问题，Elasticsearch提供了 将索引细分为多个名为shards的部分 当你创建一个索引时，你可以简单地定义shards的个数
1. Documents存储在shards中，碎片分配给nodes 李你cluster < / > 当你的cluster增大或缩小时，Elasticsearch将自动 在nodes之间迁移碎片，以便cluster保持平衡
2. shard可以是primary shard或replica shard。
索引中的每个文档都属于single primary shard，因此 您拥有的主碎片的数量决定了最大值 索引可以保存的数据量
3. replica shard只是一个主碎片的副本。

副本:

1. Replica shard是primary Shard的副本，防止数据丢失
.硬件故障
2. Elasticsearch允许创建索引的一个或多个副本
index也可以被复制为零(意味着没有副本)或更多 李次。< / > number of shards和replicas可以在 .创建索引
3. 索引创建后，你可以在任何时候动态地改变副本的数量，但是你必须cannot change the number of shards 李事后。< / > 默认情况下，Elasticsearch中的每个索引被分配5个主shard和1 replica，这意味着如果你至少有两个节点 在您的集群中，您的索引将有5个主碎片和另外5个 复制碎片(1个完整的副本)，每个副本共有10个碎片 李指数。< / >

我会用一个真实的词来解释这个。假设你正在经营一家电子商务网站。当你变得更受欢迎，更多的卖家和产品添加到你的网站。您将意识到您可能需要索引的产品数量已经增长，而且它们太大了，无法装入一个节点的一个硬盘中。即使它适合硬盘，在一台机器上对所有文档执行线性搜索也是极其缓慢的。一个节点上的一个索引不会利用elasticsearch工作的分布式集群配置。

因此elasticsearch将索引中的文档拆分到集群中的多个节点。文档的每一个分割都称为一个碎片。每个承载文档碎片的节点将只拥有文档的一个子集。假设你有100个产品和5个碎片，每个碎片将有20个产品。这种数据分片使得elasticsearch中的低延迟搜索成为可能。搜索在多个节点上并行进行。结果被聚合并返回。然而，碎片不提供容错功能。这意味着如果包含该分片的任何节点关闭，集群健康状态将变为黄色。这意味着一些数据是不可用的。

为了增加容错性，复制进入图片。默认情况下，弹性搜索为每个碎片创建一个副本。这些副本总是在主分片不存在的另一个节点上创建。因此，为了使系统容错，您可能必须增加集群中的节点数量，这也取决于索引的碎片数量。根据副本和分片计算所需节点数量的通用公式为“节点数量=碎片数量*(副本数量+ 1)”。标准的实践是至少有一个副本以实现容错。

设置碎片数量是一个静态操作，这意味着您必须在创建索引时指定它。在此之后的任何改变都需要完全重新索引数据，并且需要时间。但是，副本数量的设置是一个动态操作，也可以在索引创建后的任何时间完成。

您可以使用下面的命令为索引设置碎片和副本的数量。

curl -XPUT 'localhost:9200/sampleindex?pretty' -H 'Content-Type: application/json' -d '
{
"settings":{
"number_of_shards":2,
"number_of_replicas":1
}
}'

Elasticsearch具有超强的可扩展性，所有功劳都归功于它的分布式架构。由于分片，这是可能的。现在，在进一步讨论之前，让我们考虑一个简单且非常常见的用例。让我们假设，您有一个包含大量文档的索引，为了简单起见，假设该索引的大小为1tb(即，该索引中每个文档的大小之和为1tb)。另外，假设您有两个节点，每个节点都有512 GB的可用空间来存储数据。可以清楚地看到，我们的整个索引不能存储在两个可用节点中的任何一个中，因此我们需要将索引分布在这些节点中。

在这种情况下，索引的大小超过了单个节点的硬件限制，分片就可以救场了。Sharding通过将索引划分为更小的块来解决这个问题，这些块被命名为Shards。

不是答案，而是核心概念对ElasticSearch的另一个引用，我认为他们非常清楚地赞美了@javanna的答案。

碎片

索引可能存储大量数据，这些数据可能超过单个节点的硬件限制。例如，占用1TB磁盘空间的10亿个文档的单个索引可能无法放在单个节点的磁盘上，或者可能太慢，无法单独为单个节点的搜索请求提供服务。

为了解决这个问题，Elasticsearch提供了将索引细分为多个碎片的功能。在创建索引时，可以简单地定义所需的碎片数量。每个碎片本身就是一个功能齐全、独立的“索引”;可以托管在集群中的任何节点上。

分片之所以重要，主要有两个原因:

• 它允许你水平分割/规模你的内容卷。
• 它允许你在分片上分布和并行操作(可能在多个节点上)，因此提高性能和吞吐量。

副本

在网络/云环境中，任何时候都可能发生故障，因此在分片/节点因某种原因脱机或消失时，强烈建议使用故障转移机制，这是非常有用的。为此，Elasticsearch允许您将索引碎片的一个或多个副本复制到所谓的复制碎片中，或简称为副本。

复制之所以重要，主要有两个原因:

• 它提供高可用性以防碎片/节点失败。因此，重要的是要注意，在同一个节点上，复制碎片永远不会作为复制它的原始/主碎片分配。
• 它允许你扩大搜索范围卷/吞吐量，因为搜索可以并行地在所有副本上执行。

用最简单的术语来说，shard只是存储在磁盘上一个单独文件夹中的索引的一部分:

这个截图显示了整个Elasticsearch目录。

正如你所看到的，所有的数据都进入了data目录。

通过检查索引C-mAfLltQzuas72iMiIXNw，我们看到它有五个碎片(文件夹0到4)。

另一方面，JH_A8PgCRj-GK0GeQ0limw索引只有一个碎片(0文件夹)。

pri显示了碎片的总数。