solr亿万级索引优化实践（一）

       海量数据的索引，第一个要解决的是数据存储的问题，solr提供数据存储平台有两种，第一个是本地磁盘，另一个是HDFS，我们可以通过solrhome的配置来实现。在本次实践中，我们选择的是本地磁盘，因为采用的solrcloud部署模式，本身就是多节点多机器，在存储上不会有问题，还有另一个重要的原因后面会讲到。下面讲讲具体从哪些方面做了实践。

    solr版本：solr6.0.0；主机：red hat； 网络：千兆网

    性能的具体要求是：

    1、在一台机器上普通硬盘的情况下，索引单个文档大小为200字节左右，需要达到的效率为7WTPS。

    2、具有良好的水平扩展性。

    3、对数据备份和数据丢失情况，要求不严格。

    在对索引速度进行优化之前，有必要先对建立索引的整个流程做个大致的了解，如下图所示：

                                                         

    说明：
    1、 客户端发送HTTP的POST请求到Solr服务器，报文格式一般有xml、json、javabin（只有java才支持，二进制结构）。
    2、 Web服务器将请求派发到Solr的Web应用程序（Servlet）。
    3、 Solr根据请求的URI中的Collection名字在solrConfig.xml找到注册的/update消息处理器；这是单个副本的情况下，如果多个副本的情况下，如果需要判断此副本是否为Leader，如果是非Leader，则需要将此文档发送给此副本的Leader，如果是非直接路由模式，Solr则会根据文档ID进行hash路由，路由到特定的Leader上。
    4、 按照solrConfig.xml配置的请求处理链来处理索引，比如分词处理器等。
    5、 写事务日志，当发送提交后正式将数据写入到存储中，事务日志可以保证在用户未提交的情况下数据不丢失。

    6、 返回写索引的结果。

    提交方式

    solr提供了两种提交方式：硬提交和软提交。硬提交(hard commit)指的是在客户端每提交一批数据都通知服务器把数据刷新到硬盘上，检索的时候数据可以立马可见；软提交(soft commit)是让服务器自己控制在一定的时间范围之内刷新数据。很明显，硬提交是非常损耗性能的操作，并且它还会阻塞其他数据的提交，所以我们选择软提交，具体配置方式如下所示：

 
       ${solr.autoCommit.maxTime:30000} 
       false 
 

 
  ${solr.autoSoftCommit.maxTime:60000} 

    在这份配置文件中，我们指定了服务器每隔60秒对数据做一次软提交，另外推荐opensearch设置为false，否则每次提交都会开启一个opensearch，这个也会损耗性能。

    关闭副本

    solr一个collection会有多个分片（shard），多个shard分别位于不同的节点上，每个节点上可能会有shard的多个复制，其中一个为leader shard，在追求极限速度的情况下，可以将副本数设置为1，这样减去了副本间的数据同步等资源消耗。不过这样做带来的弊端就是数据容灾性降低，和检索性能急剧下降。

    取消分词器

    很显然使用分词器的话会对数据做进一步处理，也是会使得性能大幅度降低的，再不使用全文检索的情况下可以不使用分词器来提高速度。

    增加分片

    在一台物理机上，我们可以部署多个solr实例，在每个实例上可以设置多个shard，这样在索引数据的时候，一个collection会有多个shard在同时入数据，显然速度是可以大幅提升的。不过shard数也不能太多，机器资源是有限的，当太多shard同时写数据，会导致内存和IO压力很大，效果适得其反，应该根据自己得硬件情况进行合理设置。另外，如果是采用的SSD硬盘，设置多个solrhome也会有不错的效果。

    划分collection

    当数据积累的越来越多的时候，哪怕多个shard，每个shard的数量也是巨量的，这个时候，不仅查询性能急剧下降，由于lucene倒排序索引的原理建索引速度也会越来越慢。所以我们尝试控制每个shard数据量不会太大，进行了按业务划分索引库，或者按天按小时建立索引库，这样数据分布到多个collection中，均衡了每个索引库的压力。

    下一篇将会重点从路由模式来介绍如果进行优化。