ES

ES是当今最为流行的开源搜索解决方案，对于大部分通用的场景，ES应该都是可以满足的。
并且ES本身架构上就非常优秀，基本上分布式架构的大多数场景，其本身都有涉及，非常值得我们去学习。

关于通用搜索流程

基本上与这篇文章open in new window中谈到的相符合。但很多时候我们也需要添加我们自己的业务逻辑
离线部分的话，数据的入库可以自定义处理脚本。而对于大型系统来说，这种入库必然不是串行的，不然入库就成为瓶颈了，而这种并行的入库，其实就交给使用方来自己实现，怎么同步数据入库

在线部分的话，一般我们需要关注的，一般是召回部分（改写、纠错与分词），因为默认的中文分词在很多情况下无法符合预期，以及因为一些异常情况下的干预，一般在召回部分做干预的成本较低。
检索的话，除了默认的计算相关性的方式之外，也支持我们自定义脚本计算相关性

ES的正排与倒排的存储

数据的分片一般是根据doc_id来进行分片的，正常我们在容量规划的时候就需要进行确认. 而检索的时候都是通过term去检索的，所以一般会全扇出

关于ES的数据更新及平衡过程

其实这个问题就是，ES的数据如何无限横向扩展。
这种扩容一般都是采用一致性hashopen in new window算法来实现，ES也不例外，具体可参考文档open in new window
其实最简单的方式，就是我们在容量规划的时候，就提前规划好ES的容量，否则动态扩容再自平衡的时间成本，一般业务都是无法接受的。即使是采用了一致性 hash 这种增删节点影响面相对已经较小的方案，但在自平衡的过程中，还是会严重影响集群的读写，影响业务的正常使用。

关于集群扩容

可参考腾讯云这篇文章open in new window

海量分片的代价

一个分片的底层就是一个Lucene索引，会消耗一定文件句柄、内存、CPU资源
数据热点问题
计算相关度的词频统计信息是基于分片的
第三点这个代价其实我们一直容易忽略的

关于ES的高可用

大型工业项目不可避免的高可用问题。

数据一致性的问题

单机房不同实例的数据一致性的问题解决多机房的数据一致性问题解决

ES对sql的支持

在官方的最新文档中，sql-getting-startedopen in new window,发现已经支持sql了

POST /_sql?format=txt
{
  "query": "SELECT * FROM library WHERE release_date < '2000-01-01'"
}

关于ES配置的一些最佳实践

其它优化

关于一些其他方面的优化

使用pagecacheopen in new window, 这个一般以硬盘作为主要存储介质的，都会使用这一特性
数据冷热分层open in new window

# ES

# 关于通用搜索流程

# ES的正排与倒排的存储

# 关于ES的数据更新及平衡过程

# 关于集群扩容

# 海量分片的代价

# 关于ES的高可用

# 数据一致性的问题

# ES对sql的支持

# 关于ES配置的一些最佳实践

# 其它优化

# 参考文档

ES