所有您需要了解的关于Elasticsearch 5.0：索引管理
所有您需要了解的关于Elasticsearch 5.0：索引管理
我们看到两种主要的Elasticsearch索引使用模式 - 全局索引和滚动索引。多年来，Elasticsearch增加了一些功能，可以极大地改善这些模式的工作体验。Elasticsearch 5引入了几项新功能，进一步构建了这些功能，并产生了一个非常好的索引管理故事。
在这篇博客文章中，我们将讨论这两种模式，并展示新的Elasticsearch 5功能（即Shrink和Rollover API）如何能够极大地帮助您有效地维护您的生产索引。
请务必查看本系列中的上一篇文章，如果您尚未阅读（请点击链接），您需要了解Elasticsearch 5.0：Search。在本系列之后的博客文章中，我们将讨论更多主题，如数据摄取策略等。
全局索引
Elasticsearch用于搜索时最常见的一种模式是索引到全局索引中。通常这是驻留在别处的数据的副本，并且索引到Elasticsearch进行搜索和执行聚合操作。然后通过分片和复制将此索引扩展到群集中的多个节点，以适应成规模的搜索请求。
这个的目的通常是针对该索引的搜索速度进行优化，并且索引到其中通常是偶然的。但有一个例外 - 全局索引通常会定期重新创建或批量更新，以保持最新的真实来源，或者映射更改是必要的。一旦需要这样的索引操作，您可能想要扩大索引以使其更快完成，并且有更多的节点参与索引过程 - 有时比通常可用于搜索的节点更多。
分片有助于减轻索引和搜索速度问题。分片就是我们所说的将一个索引分解成许多小块，由Elasticsearch作为一个大型索引进行管理。由于每个节点每秒可处理一定数量的写入请求，因此假定分片分散功能（这是默认值），分割索引可允许多个节点参与群集索引。所有这一切，在保持尺寸不太大或太小的碎片的同时，对于优化搜索性能非常重要（我通常建议在磁盘上安装一百万个文档碎片和最大5-10GB的大小）。
尽管有一个问题 - 创建索引后无法更改碎片的数量。直到现在（仍然还是这样）。
新的Index Shrink特性允许将具有X碎片的索引“收缩”为具有较少碎片的索引。请求的主要碎片数量必须是原始索引中碎片数量的一个因素。例如，一个具有8个主碎片的索引可以缩小成4, 2个或1个主碎片，或者15个主碎片的索引可以缩小成5, 3或1。
虽然这本身不是“重新利用”，但它是解决实际需求的一个很好的功能。现在，您可以创建包含许多分片的索引，以支持密集的数据提取，然后将其缩小为较小的分片以节省资源并优化搜索速度。收缩索引不会重新索引，它只会重新链接底层索引段，因此这是一种高效的操作。但是，它确实需要索引在收缩之前是只读的 - 并且大多数巨型索引可以确实允许这样做。
值得一提的是，相对较新的Reindex API在这种使用模式中非常有用 - 无论何时重建索引操作不是由于数据更改，而是索引映射更改，您都可以利用Elasticsearch从旧索引发出重新索引一个新的映射定义了新的映射。在这种情况下，不需要复杂的并行ETL过程，因为旧的索引已经包含了所有需要的数据。
滚动索引
现在更常见的模式是“滚动索引”情况。通常是以时间索引为索引的时间序列数据，例如名称类似logstash-2016.11.16的日常索引- 并且您将主要通过日志查看此模式，这是当今ELK堆栈的主要用法。在这种模式下，新的索引正在不断创建，并且在一段时间之后，它们不再被写入。通常，这些索引会在一段时间后从集群中删除，复制到备份位置，然后删除或删除，如果数据不够重要，永远不会保留。
时间序列数据案例通常涉及24/7高吞吐率 - 认为活动系统的日志或“物联网”案例。这意味着您希望在任何给定时间优化写入活动索引，这意味着您的节点可以支持的碎片数量很多。超分割将帮助您实时获取更多数据，并避免由于大量索引请求而导致Elasticsearch在索引编制方面推迟或落后。
但是这种方法有几个问题：
- 过去未被写入但被搜索的索引将被过度分割，这意味着搜索的搜索性能下降，因为分片数量越少越好，并且分片大小最可能小于高效的搜索。
- 并非所有索引都是相同的。虽然Elasticsearch对待它们都是一样的，但世界可能不会。在正常运营期间，有些日子可能比其他日子忙，产生两倍的事件，而可能有几周的停机时间会导致实际上为空的索引。
- 当然，加班时间你在任何一天收录的文件数量将增加，这将导致臃肿的索引和碎片 - 再次损害搜索性能。目前，将指标从日常变为每小时是一个严格的过程，需要在太多地方进行太多改变。
正如你所猜测的，＃1可以通过Shrink API轻松修复。正如我们刚刚看到的，一旦索引停止写入，您可以将其缩小为具有较少数量的碎片，从而针对搜索和聚合进行优化。此外，因为在滚动索引用例中，这个索引永远不会被再次写入，所以您可以强制合并它（但要确保不会以分片太大为结束！），压缩并将其标记为只读。这将确保对这些索引的高效搜索。
该Index Rollover API解决了其余的问题。这是一个很好的新功能，它利用别名根据索引中的文档数量或基于第一个索引文档的时间为索引提供配额。可以设置索引的别名，例如，一旦索引达到配额，别名将切换到索引到新索引，同时仍启用对此索引和所有先前索引的搜索。这对于在滚动索引用例中也可以平衡索引大小有很长的路要走。
Curator长期以来一直是一个管理索引的好工具，特别是在滚动指标情景中。通过将Curator与索引模板结合使用，Rollup API现在可以为您提供滚动索引的非常好的索引管理体验。
您可以在这里的官方博客文章中了解关于这个新API的更多信息。Shrink和rollover API现在允许使用多个分片在索引过程中充分利用硬件资源，然后将索引缩减为单个分片（或几个分片），以便进行高效的存储和搜索。