在分布式集群中，介绍了瓷砖，将其作为下级的工作单位进行了记述。 但是，瓷砖是什么，它是如何工作的？ 本章回答这些问题。
为什么搜索接近实时？ 为什么文档的CRUD操作是实时的？ ESS如何使更新持久化，确保即使断电也不会丢失？ 为什么删除文档不会立即释放空间？ 什么是刷新、闪存和优化API？ 另外，我应该什么时候使用它们？ 要了解瓷砖是如何工作的，最简单的方法是从历史课开始。 我们将看到需要解决哪些问题才能提供具有几乎实时搜索和分析功能的分布式、持续的搜索引擎。
1 .为了能够搜索文本，首先需要解决的问题是能够搜索文本。 传统的数据库在一个字段中存储一个值，但不足以进行全文搜索。 为了能够搜索文本中的所有单词，必须在数据库中存储多个值。
支持单个字段中多个值的最佳数据结构是索引倒置。 倒排索引包含显示在所有文档中的唯一值或单词的有序列表，以及每个单词所属文档的列表。
倒排索引包含的信息比包含特定term的文档列表多。 可以存储包含每个term的文档数、一个term在指定文档中出现的频率、每个文档中的term顺序、每个文档的长度以及所有文档的平均长度等。 这些统计信息使Elasticsearch能够了解哪些term更重要，哪些文档更重要，也就是相关性。
请注意，为了实现倒排索引期望的功能，您必须知道集合中的所有文档。
在全文检索的早期，会在整个文档集合中创建大索引并写入磁盘。 如果提供了新索引，则会搜索最近的修改，而不是旧索引。
2 .写入不变性磁盘的倒排索引不变，具有以下优点：
不需要锁。 如果不需要更新索引，则不必担心多个程序会同时尝试修改。 当索引被读取到文件系统缓存中时，翻译者：位于内存中。 因为不会更改，所以一直在那里。 有限的
文件系统缓存有足够的空间，大多数读取操作直接访问内存而不是磁盘。 这有助于提高性能。 在索引声明期间，所有其他缓存都可用。 不需要在每次数据发生变化时重新构建。 因为数据不会变。 通过写入单个较大的倒排索引，可以压缩数据，减少磁盘I/o，并减少需要缓存索引的内存大小。 当然，不变的索引有缺点。 首先，那是不变的。 我不能改变那个。 要搜索新文档，必须重新浏览整个索引。 这大大限制了一个索引可以存储的数据以及一个索引可以更新的频率。
3 .动态索引下一个需要解决的问题是如何更新倒排索引，同时保留不变的好处。 答案是使用多个索引。
添加额外的索引以反映最近的变化，而不是重写整个倒排索引。 每个倒排索引可以按顺序查询，从最旧的开始，最后聚合结果。
电子搜索基础所依赖的Lucene引入了间隔搜索的概念。 分段是一个功能完整的倒排索引，但当前Lucene索引指向分段集合和提交点(commit point，包括所有分段的文件)。 新文档在写入磁盘段之前，首先写入内存空间的索引缓存，如图2和图3所示。
索引vs分片
为了避免混淆，必须说明Lucene索引是Elasticsearch的分片，而Elasticsearch的索引是分片的集合。 Elasticsearch在搜索索引时，会向该索引下的所有片发送查询请求，过滤这些结果并将其聚合为全局结果。
一个人的间隔搜索如下：项工作
新文档首先写入内存空间的索引缓存。 有时会提交这些缓冲区：
)1)将新段——的额外倒排索引——写入磁盘。
)2)新提交点将写入磁盘，包括新段的名称。
)3)磁盘或fsync’ed (文件同步) ——所有写入操作都是在等待文件系统缓存同步到磁盘后验证是否可以物理写入。 等待新段打开，从可用内存的缓存中清除文档，并接受新文档。
一个请求被接受后，所有段依次查询。 聚合所有段的Term统计信息，以确保正确计算每个Term与文档的相关性。 这样，新文档将以较小的成本添加到索引中。
4 .由于段的删除和更新是不变的，因此不能从旧段中删除文档，也不能更新旧段以反映文档的最新版本。 相反，每个提交点都包含一个. del文件，其中包含在段上删除的文档。
当文档被删除时，它实际上只是在. del文件中标记为删除，可以与查询匹配，但在最终返回之前会从结果中删除。
的更新操作也是如此。 文档更新后，旧版本的文档将标记为删除，而新版本的文档将索引到新部分。 文档的不同版本可能与查询匹配，但旧版本将从结果中删除。
“合并”部分显示了如何从文件系统中清除已删除的文件。
5 .由于实时搜索per-segment search机制，索引和文档搜索之间存在延迟。 新文档几分钟内就可以搜索到，但还不够。
磁盘是瓶颈。 要将新段提交到磁盘，需要进行fsync操作。 这样可以确保段物理写入磁盘，并且即使发生电源故障，数据也不会丢失。 但是，fsync成本很高，并且不能在索引每个文档时触发。
所
以需要一种更轻量级的方式使新的文档可以被搜索，这意味这移除 fsync 。位于Elasticsearch和磁盘间的是文件系统缓存。如前所说，在内存索引缓存中的文档（图1） 被写入新的段（图2），但是新的段首先写入文件系统缓存，这代价很低，之后会被同步到磁 盘，这个代价很大。但是一旦一个文件被缓存，它也可以被打开和读取，就像其他文件一 样。
Lucene允许新段写入打开，好让它们包括的文档可搜索，而不用执行一次全量提交。这是比 提交更轻量的过程，可以经常操作，而不会影响性能。
在Elesticsearch中，这种写入打开一个新段的轻量级过程，叫做refresh。默认情况下，每个 分片每秒自动刷新一次。这就是为什么说Elasticsearch是近实时的搜索了：文档的改动不会 立即被搜索，但是会在一秒内可见。
这会困扰新用户：他们索引了个文档，尝试搜索它，但是搜不到。解决办法就是执行一次手 动刷新，通过API:
POST /_refresh <1> POST /blogs/_refresh <2>虽然刷新比提交更轻量，但是它依然有消耗。人工刷新在测试写的时有用，但是不要在 生产环境中每写一次就执行刷新，这会影响性能。相反，你的应用需要意识到ES近实时 搜索的本质，并且容忍它。
不是所有的用户都需要每秒刷新一次。也许你使用ES索引百万日志文件，你更想要优化索引 的速度，而不是进实时搜索。你可以通过修改配置项 refresh_interval 减少刷新的频率：
PUT /my_logs { "settings": { "refresh_interval": "30s" <1> } }<1> 每30s refresh一次 my_logs
refresh_interval 可以在存在的索引上动态更新。你在创建大索引的时候可以关闭自动刷 新，在要使用索引的时候再打开它。
PUT /my_logs/_settings { "refresh_interval": -1 } <1> PUT /my_logs/_settings { "refresh_interval": "1s" } <2> <1> 禁用所有自动refresh<2> 每秒自动refresh 6.持久化变更没用 fsync 同步文件系统缓存到磁盘，我们不能确保电源失效，甚至正常退出应用后，数据 的安全。为了ES的可靠性，需要确保变更持久化到磁盘。
我们说过一次全提交同步段到磁盘，写提交点，这会列出所有的已知的段。在重启，或重新 打开索引时，ES使用这次提交点决定哪些段属于当前的分片。
当我们通过每秒的刷新获得近实时的搜索，我们依然需要定时地执行全提交确保能从失败中 恢复。但是提交之间的文档怎么办？我们也不想丢失它们。
ES增加了事务日志（ translog ），来记录每次操作。有了事务日志，过程现在如下：
当一个文档被索引，它被加入到内存缓存，同时加到事务日志。2.refresh使得分片的进入如下图描述的状态。每秒分片都进行refeash：内存缓冲区的文档写入到段中，但没有fsync。段被打开，使得新的文档可以搜索。缓存被清除
3.随着更多的文档加入到缓存区，写入日志，这个过程会继续
4. 不时地，比如日志很大了，新的日志会创建，会进行一次全提交：
事务日志记录了没有flush到硬盘的所有操作。当故障重启后，ES会用最近一次提交点从硬盘 恢复所有已知的段，并且从日志里恢复所有的操作。
事务日志还用来提供实时的CRUD操作。brdlc尝试用ID进行CRUD时，它在检索相关段内的文 档前会首先检查日志最新的改动。这意味着ES可以实时地获取文档的最新版本。
7.合并段通过每秒自动刷新创建新的段，用不了多久段的数量就爆炸了。有太多的段是一个问题。每 个段消费文件句柄，内存，cpu资源。更重要的是，每次搜索请求都需要依次检查每个段。baddr，查询越慢。
ES通过后台合并段解决这个问题。小段被合并成大段，再合并成更大的段。
这是旧的文档从文件系统删除的时候。旧的段不会再复制到更大的新段中。
这个过程你不必做什么。brdlc在索引和搜索时ES会自动处理。这个过程如图：两个提交的段 和一个未提交的段合并为了一个更大的段所示：
索引过程中，refresh会创建新的段，并打开它。合并过程会在后台选择一些小的段合并成大的段，这个过程不会中断索引和搜索。下图描述了合并后的操作：
新的段flush到了硬盘。新的提交点写入新的段，排除旧的段。新的段打开供搜索。旧的段被删除。合并大的段会消耗很多IO和CPU，如果不检查会影响到搜索性能。默认情况下，ES会限制合 并过程，这样搜索就可以有足够的资源进行。