我假设 Elasticsearch 中的每个分片都是一个索引。但我在某处读到每个段都是一个 Lucene 索引。
究竟什么是段？它如何影响搜索性能？使用默认的 Elasticsearch 设置，我每天都有大约 450GB 的索引（我每天创建一个新的）。
当我执行curl -XPOST "http://localhost:9200/logstash-2013.03.0$i_optimize?max_num_segments=1"时，我得到
num_committed_segments=11and num_search_segments=11。
上面的值不应该是 1 吗？也许是因为index.merge.policy.segments_per_tier价值？这层到底是什么？
“索引”这个词在 Elasticsearch 中被滥用了一点——适用于太多的东西。
解释：
Elasticsearch 中的“索引”有点像关系数据库中的数据库。这是您存储/索引数据的地方。但实际上，这正是您的应用程序所看到的。在内部，索引是指向一个或多个分片的逻辑命名空间。
此外，“索引”意味着将您的数据“放入”Elasticsearch。您的数据既被存储（用于检索）又被“索引”用于搜索。
“倒排索引”是 Lucene 用来使数据可搜索的数据结构。它处理数据，提取唯一的术语或标记，然后记录哪些文档包含这些标记。有关更多信息，请参见http://en.wikipedia.org/wiki/Inverted_index。
“分片”是 Lucene 的一个实例。它本身就是一个功能齐全的搜索引擎。“索引”可以由单个分片组成，但通常由多个分片组成，以允许索引增长并拆分到多台机器上。
“主分片”是文档的主要家。“副本分片”是主分片的副本，它提供 (1) 故障转移以防主分片死亡和 (2) 增加读取吞吐量
每个分片包含多个“段”，其中一个段是倒排索引。分片中的搜索将依次搜索每个段，然后将它们的结果组合到该分片的最终结果中。
当您为文档编制索引时，Elasticsearch 将它们收集在内存中（为了安全起见，在事务日志中）然后每隔一秒左右，将一个新的小段写入磁盘，并“刷新”搜索。
这使得新段中的数据对搜索可见（即它们是“可搜索的”），但该段尚未同步到磁盘，因此仍有数据丢失的风险。
每隔一段时间，Elasticsearch 就会“刷新”，这意味着对段进行 fsync（它们现在“已提交”）并清除事务日志，这不再需要，因为我们知道新数据已写入磁盘.
分段越多，每次搜索所需的时间就越长。因此，Elasticsearch 将通过后台合并过程将许多大小相似的段（“层”）合并为一个更大的段。一旦写入新的更大的段，旧的段就会被删除。当有太多相同大小的片段时，这个过程会在更大的片段上重复。
段是不可变的。当一个文档被更新时，它实际上只是将旧文档标记为已删除，并索引一个新文档。合并过程还会删除这些旧的已删除文档。