主从模式
主节点有单点故障问题：没有主从自动切换，没有failover，主机down掉了的话，整个数据变成只读。并且需要一台机单独做索引，浪费资源，所有数据都需要在这台机器上单独存在一份，索引变化较大的时候同步会占用很大的带宽和资源。
配置文件改动：改动了solrconfig.xml最终还是要手动上传至从机，而且没有做xml相关的有效性验证，上传后有可能配置出错就直接覆盖原来的配置了，而且也没有提示。
1.索引
一条数据到分发到哪个shard-》具体的replica-》shard大到一定程度之后如何扩容
1.1路由规则
SolrCloud中对于文档分布在哪个shard上
提供了两种路由算法：compositeId和implicit
在创建Collection时，需要通过router.name指定路由策略，默认为compositeId路由。
compositeId
该路由为一致性哈希路由，shards的哈希范围从80000000~7fffffff。初始创建collection是必须指定numShards个数，compositeId路由算法根据numShards的个数，计算出每个shard的哈希范围，因此路由策略不可以扩展shard。
implicit
该路由方式指定索引具体落在路由到哪个Shard，这与compositeId路由方式索引可均匀分布在每个shard上不同。同时只有在implicit路由策略下才可创建shard。
利用solrJ新建索引时，需要在代码中指定索引具体落在哪个shard上，添加代码：
doc.addField("_route_", "shard_X");
同时在schema.xml添加字段
1.2索引过程
整体逻辑：路由规则定位所属shard->所属shard的leader->replica
具体表现：文档->任意replica->不是leader的话，转发至同shard的leader->转发给本shard的replica->基于路由规则不是本shard，会转发到对应shard的leader->对应shard的replica
1.3分片(纵向扩容还有：升级硬件)
shard-》shard1、shard2
整体逻辑：旧shard此时继续提供服务并把旧索引转到新的shard上
旧shard同时继续索引新文档
旧shard同时把新文档转发给新shard，新shard索引新文档
旧索引全部迁移到新shard之后，旧shard关闭，新文档直接转发到新的shard上了
implicit路由：只要创建Shard即可: 新建索引时，将索引建到新建Shard上，查询操作，指定collection名称，得到的仍是整个集群返回的结果。
compositeId路由：实现上述需求稍微麻烦一下，通过分裂（SPLITSHARD）操作实现。如下图，对Shard1进行分裂，分裂URL为：
http://10.21.17.200:9580/solr-4.10.0-web/admin/collections?action=SPLITSHARD&collection=log4j201503&shard=shard1此时Shard1的数据会平均分布到shard1_0和shard1_1上，在利用DELETESHARD API删除Shard1，即可保证数据不冗余
1.4增加机器(横向扩容)
1.5索引速度
1.一致性哈希
SolrCloud对于单条document的Hash值的获取提出了以下两个要求：
1、hash计算速度必须快，因为hash计算是分布式建索引的第一步。
2、hash值必须能均匀的分布于每一个shard，如果有一个shard的document数量大于另一个shard，那么在查询的时候前一个shard所花的时间就会大于后一个，SolrCloud的查询是先分后汇总的过程，也就是说最后每一个shard查询完毕才算完毕，所以SolrCloud的查询速度是由最慢的shard的查询速度决定的。
基于以上两点，SolrCloud采用了MurmurHash 算法以提高hash计算速度和hash值的均匀分布。
CloudSolrServer，SolrCloud批量添加索引的时候，建议在客户端提前做好document的路由，内部进行文档路由，开销较大。
2.提交频率
commit越频繁越会生成小且多的segment，于是merge出现的更频繁，越耗资源，目前互联网中很多项目中采用缓存机制来弥补这个实时性。
2.查询
含有该collection的任意机器-》任意replica-》基于shard个数，启动一个shard对应一个replica的分布式查询-》由最初的replica合并后面启动的多个子查询的结果-》返回给客户
查询速度
1.跟业务相结合，数据量不大并发不大时就采用非hash路由，数据量集中，一次查询也不用后面多个节点，多个十几个shard去合并查询，浪费时间和资源！
配置文件：schema
positionIncrementGap用于短语检索控制
positionIncrementGap is used for phrase query of multi-value fields e.g. doc1 has two titles.
> title1: ab cd
> title2: xy zz
if your positionIncrementGap is 0, then the position of the 4 terms are 0,1,2,3. if you search phrase "cd xy", it will hit. But you may think it should not match so you can adjust positionIncrementGap to a larger one. e.g. 100. Then the positions now are 0,1,100,101. the phrase query will not match it.
positionIncrementGap：0
ab cd xy zz
positionIncrementGap：100
ab cd xy zz
ab cd在第一种情况能命中，第二种情况不能命中
precisionStep：
precisionStep 数值类型的值转换成字符串类型的值时，影响切分之后term的个数！
precisionStep 越小那么被“切”成的的字符串就会多。precisionStep 越小则value被“切”成的term就越多，也就是说索引体积将会增大。被“切”分的term越多则可能在NumericRangeQuery中被细分 的小区间中存在的可能性也就越高，那么查询遍历的次数也就越少，性能也就越好。因此，理想的precisionStep只能依据自己的测试而获取。同时请注意如果只是对其进行sort而不需要范围查询可以将precisionStep=Integer.MAX_VALUE。这样只会生成一个term，从而不会增大索引体积。
普通检索类型：
key:value
key:"term"
k1:v1 AND k2:v2
k2:v2
k2:v2
+k2:v2 AND
全文检索框架
阿里妈妈：mdrill
腾讯：Hermes
google：Dremel
Facebook：Presto
阿里巴巴：Druid
parquet：Twitter和Cloudera
CarbonData:华为
实时处理框架：
Twitter替代Storm的方案：Heron
大数据可视化框架：
Nanocubes
查询客户端：
Airpal