主從模式
主節點有單點故障問題：沒有主從自動切換，沒有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添加字段
<field name="_route_" type="string"/>
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