ElasticSearch使用总结（二）

前面简单描述了Elasticsearch的相关内容，本文主要讲讲Es的倒排索引和近实时搜索。
  首先最重要的一点是倒排索引的不可变性。我们用惯了mysql，postgeresql等数据库的可能会觉得一个数据保存在数据库可以增删查改是天经地义的事，当第一次接触Es时，相信很多人都无法理解为什么Es只支持增和查，这意味着当我们想要搜索一个新文档时，必须重建整个索引。但Es这样做也是有它的考虑的，倒排索引不可变就不需要锁来保证一致性，可以将索引一直保存在缓存中避免对硬盘的大量访问，创建和查询之间不会相互干扰。其实仔细想想，对于一个全文检索的功能来说，数据字段改动的可能性很小，而全文检索对性能的要求却很高，所以开发者才会做出这样的决定。
  既然实现了倒排索引，那当我们新添加一个索引时，怎么样才能把索引最终变得可搜索呢，答案就是建多个索引，elasticsearch使用了底层lucene的per-segment search的概念，也就是说索引在硬盘中是以段的形式存在的，当我们新建索引时，es首先作为一个段把它保存在内存中，之后该段就会作为一个新的段保存到硬盘中，之后这些文档就可以被搜索到了。因为数据保存在内存中的性能往往比保存在硬盘中高得多，要一次性把整个段保存到硬盘中，当数据量大时对性能的影响是极大的。还好es为我们提供了一种更高效的方式，通过它底层的lucene写入打开功能，es默认每隔一秒，就会把内存段中的内容保存到硬盘的相应段中，这些数据就可以检索到了（当初写测试的时候老跑不过，花了好长时间排错，其实只需要强制刷新段到硬盘就可以了），在查询的时候，es会遍历每个段来找到需要的记录。
  当然，如果每秒都创建一个新的段，那es中段的数据会多到不可想象，不用说，对性能和硬盘空间也有极大的影响。es在后台会自动的合并选择小的段来合并成大的段，生成大的段后，小的段就会被删除。
  综上可以看出，es为了实现一个高性能，高可扩展的搜索引擎，它内部做了很多的权衡和优化，上面所说的只是其中的一小部分，但从中可以看到我们在软件开发过程中，总是会面临许多选择，大到使用什么数据库，小到循环是用for还是while，我们都应遵循开发目标是什么，需求是什么，而不是盲目的追逐新的技术。
在下一篇中我会简单介绍我在开发过程中遇到的问题和相应的解决思路。