为什么要学习架构?

Elasticsearch的一些架构设计，对我们做性能调优、故障处理，具有非常重要的影响。下面将从Elasticsearch的准实时索引的实现、自动发现、rounting和replica的读写过程，shard的allocate控制

使文本可以被搜索？

在传统的数据库中，一个字段存一个值，但是这对于全文搜索是不足的。想要让文本中的而每个单词都可以被搜索，这意味着数据库需要多个值。

支持一个字段多个值的最佳数据结构是倒排索引。倒排索引包含了出现在所有文档中唯一的值或或词的有序列表，以及每个词所属的文档列表。

<iframe id="iframe_0.3615271924114711" style="border: medium; border-image: none; width: 638px; height: 190px;" src="data:text/html;charset=utf8,%3Cstyle%3Ebody%7Bmargin:0;padding:0%7D%3C/style%3E%3Cimg%20id=%22img%22%20src=%22http://www.th7.cn/d/file/p/2015/12/30/218a13de1bbcae055a6d574d2f6b2de1.jpg?_=6096072%22%20style=%22border:none;max-width:1850px%22%3E%3Cscript%3Ewindow.onload%20=%20function%20()%20%7Bvar%20img%20=%20document.getElementById('img');%20window.parent.postMessage(%7BiframeId:'iframe_0.3615271924114711',width:img.width,height:img.height%7D,%20'http://www.cnblogs.com');%7D%3C/script%3E" frameborder="0" scrolling="no"></iframe>

倒排索引存储了比包含一个term的文档列表多地多的信息，它可能包含每一个term的文档数量，一个term出现在制定文档中的频次，每个文档中term的顺序，每个文档的长度，所有文档的平均长度等等。这些统计信息让Elasticsearch知道哪些term更重要，哪些文档更重要，也就是相关性。

在全文搜索的早些时候，会为整个文档集合建立一个大索引，并且写入磁盘。只有新索引准备好了它就会替代旧肚饿索引，最近的修改可以被检索。

不可变性

写入磁盘的倒排索引是不可变的，它有如下好处：

• 不需要锁。如果从来不需要跟新一个索引，就不必担心多个程序见同时尝试修改。
• 一旦索引被读入文件系统的缓存，它就一直在那儿，因为不会改变。只要文件系统缓存有足够的空间，大部分的读会直接访问内存而不是磁盘。这有助于性能的提升。
• 在索引的声明周期内，所有的其他缓存都可用。他们不需要再每次数据变化了都重建，因此数据不会变。
• 写入单个大的倒排索引，可以压缩数据，较少的磁盘IO和需要缓存索引的大小。

当然，不可变的索引有它的缺点，首先是它不可变。如果想要搜索一个新文档，必须重建整个索引。这不仅限制了一个索引所能装下的数据，还有一个索引可以被更新的频次。

准实时索引的实现？

本文主要介绍Elasticsearch的准实时索引的实现，至于基于Lucene的倒排索引将不在这里介绍，有兴趣的读者可以去Lucene的相关文章，或者阅读《Lucene in Action》等书籍。下面将介绍Elasticsearch索引流程中发生的具体操作，重点在于其中的segment、buffer和translog三部分对性能方面的影响。

1、动态更新的Lucnee索引

要做到实时跟新条件下数据的可用和可靠，就需要在倒排索引的基础上，再做一系列更高级的处理。总结一下Lucene的处理办法：新收到的数据写入新的索引文件里。Lucene把每次生成的倒排索引，叫做一个段(segment)。然后另外使用一个commit文件，记录索引内的所有segment。而生成segment的数据来源，则是内存中的buffer,也就是说，动态跟新过后过程如下：1）当前磁盘上有三个segement可用，同时有一个commit文件记录当前的segment2）新收到的数据进入内存buffer,索引状态如下所示。3）buffer刷到磁盘，生成一个新的segment,commit文件同步跟新。这样可以完成跟新，也产生了几个问题:1、每次一有数据就刷新到磁盘，会增大对磁盘的操作2、刷新到磁盘的时间占据很大一部分时间3、如果刷新的过程中刷新失败应该怎么控制呢？<iframe id="iframe_0.9985394181617475" style="border: medium; border-image: none; width: 503px; height: 380px;" src="data:text/html;charset=utf8,%3Cstyle%3Ebody%7Bmargin:0;padding:0%7D%3C/style%3E%3Cimg%20id=%22img%22%20src=%22http://www.th7.cn/d/file/p/2015/12/30/15c3acfd45d0dbcb84a26e6c5512b1aa.jpg?_=6096072%22%20style=%22border:none;max-width:1850px%22%3E%3Cscript%3Ewindow.onload%20=%20function%20()%20%7Bvar%20img%20=%20document.getElementById('img');%20window.parent.postMessage(%7BiframeId:'iframe_0.9985394181617475',width:img.width,height:img.height%7D,%20'http://www.cnblogs.com');%7D%3C/script%3E" frameborder="0" scrolling="no"></iframe><iframe id="iframe_0.7457630472138725" style="border: medium; border-image: none; width: 748px; height: 492px;" src="data:text/html;charset=utf8,%3Cstyle%3Ebody%7Bmargin:0;padding:0%7D%3C/style%3E%3Cimg%20id=%22img%22%20src=%22http://www.th7.cn/d/file/p/2015/12/30/176ad9e6c5968cff438c251bedaa4bed.jpg?_=6096072%22%20style=%22border:none;max-width:1850px%22%3E%3Cscript%3Ewindow.onload%20=%20function%20()%20%7Bvar%20img%20=%20document.getElementById('img');%20window.parent.postMessage(%7BiframeId:'iframe_0.7457630472138725',width:img.width,height:img.height%7D,%20'http://www.cnblogs.com');%7D%3C/script%3E" frameborder="0" scrolling="no"></iframe>
<iframe id="iframe_0.930191672992274" style="border: medium; border-image: none; width: 746px; height: 493px;" src="data:text/html;charset=utf8,%3Cstyle%3Ebody%7Bmargin:0;padding:0%7D%3C/style%3E%3Cimg%20id=%22img%22%20src=%22http://www.th7.cn/d/file/p/2015/12/30/9cea8a905ceded50467ca2b99564cde7.jpg?_=6096072%22%20style=%22border:none;max-width:1850px%22%3E%3Cscript%3Ewindow.onload%20=%20function%20()%20%7Bvar%20img%20=%20document.getElementById('img');%20window.parent.postMessage(%7BiframeId:'iframe_0.930191672992274',width:img.width,height:img.height%7D,%20'http://www.cnblogs.com');%7D%3C/script%3E" frameborder="0" scrolling="no"></iframe>

2、删除和更新

segment是不可变的，所以文档即不能从旧的段中删除，旧的段也不能更新以反映文档最新的文本。相反，每一个提交点包括一个.del文件，包含了段上已经被删除的文档当一个文档被删除，它是实际上只是在.del文件中被标记删除，亦然可以匹配查询，但最终返回之前会被从结果中删除。文档的跟新操作是类似的：当一个文档被更新，旧版本的文档被标记为删除，新版本的文档在新的段中索引。也许该文档的不同版本都会匹配一个查询，但是老版本会从结果中删除。

3、利用磁盘缓存实现的准实时检索

既然涉及到磁盘，那么一个不可避免的问题就来了：磁盘太慢了！对我们要求的实时性很高的服务来说，这种处理还不够。所以，在刚刚第3步的处理中，还有一个中间状态:1）内存buffer生成一个新的segment，刷到文件系统缓存中，Lucene即可检索到这个新的segment,索引状态如图所示。2）文件系统缓存真正同步到磁盘上，commit文件跟新。刷到文件系统缓存中这个步骤，Elasticsearch默认1s的时间间隔，这也就是说相当于是实时搜索的，Elasticsearch也提供了单独的/_reflush接口，用户如果对1s间隔还是不太满意，可以主动调用接口来保证搜索可见。

POST /_refresh <1>POST /blogs/_refresh <2>

• <1> refresh所有索引
• <2> 只refresh 索引blogs

一般来说我们会通过/_settings接口或者定制template的方式，加大refresh_interval参数：

PUT /my_logs/_settings{ "refresh_interval": -1 } <1>PUT /my_logs/_settings{ "refresh_interval": "1s" } <2>

• <1> 禁用所有自动refresh
• <2> 每秒自动refresh

4、translog提供的磁盘同步控制

既然refresh只是写到文件系统缓存中，那么最后一步写到实际磁盘又是由什么来控制的呢？如果这期间发生主机错误、硬盘故障等异常情况，数据会不会丢失？这里，其实Elasticsearch提供了另一个机制来控制。Elasticsearch也把数据写入到内存buffer的同时，其实还另外记录了一个treanslog的日志。也就是说，在内存数据进入到buffer这一步骤时，其实还另外记录了一个translog记录。