這裡談一下筆者多年使用Solr/ES的所總結出的Solr/ES十點不足：

1、Solr/ES分詞的不足之處

對於郵箱、手機號、車牌號碼、網址、IP地址、程式類名、含有字母與數字的組合之類的資料會匹配不完整，導致資料查不全，因分詞導致漏查以及缺失資料，對於模糊檢索有精確匹配要求的場景下，業務存在較大的風險。如何玩轉Solr/ES，能夠自定義拓展任意的分詞型別，如詞庫分詞，語義分詞，拼音分詞等

2、Solr/ES在模糊匹配中的實際問題

Solr/ES的模糊匹配是基於Lucene的分詞來實現，但並不考慮單詞的匹配順序，也不保證匹配詞語的連續性，中間可以穿插其他單詞。為什麼不能支援類似SQL中的like匹配，既考慮到了單詞之間的匹配順序，也保證了匹配詞語的連續性，也可以通過*進行模糊查詢，並能實現較高的like效能

3、Solr/ES的使用者介面為何不能豐富些?

除了Java API，能不能支援標準SQL的方式，支援JDBC/ODBC接入，能否與大資料生態中其他標準組件無縫對接如Hive，Spark，Kafka等，也可與常見的報表工具、SQL視覺化工具整合。

4、對函式的支援

 Solr/ES只支援簡單的檢索過濾，sum，max，min，avg等統計函式，單列groupby。是否能支援更多的函式，支援複雜的SQL，可以巢狀，多表關聯，甚至自定義udf，udaf，udtf

5、資料匯出如何實現？

Solr/ES中的資料如若想匯出到其他系統是比較難，海量原始資料的匯出基本是不可行的，更不要說將原始資料經過各種複雜計算清洗後的匯出了。比如：支援原始資料的任意維度匯出，可以全表，也可以通過過濾篩選區域性匯出，支援資料經過各種組合計算過濾後的匯出。

6、如何解決高效能排序？

按照時間逆序排序是很系統的硬指標。Solr/ES是採用Lucene的Sort介面實現，本質是藉助DocValues的暴力掃描，如果資料量很大的情況下，排序過程會耗費大量的記憶體與IO資源，排序效能很低。

7、冷熱索引處理機制問題

Solr/ES中預設是開啟全部的索引，每個索引都會獨佔一些資源，如記憶體、檔案描述符等。但是一臺機器的記憶體與檔案描述符始終是有限的，從而也限制了Solrs/ES能夠裝載的資料規模，在機器資源有限的情況下，制約了資料規模。

8、穩定性難題

1．筆者在實際環境中，在資料規模超過千萬或過億後，生產系統實時匯入經常會出現OOM，以及CPU負載太高的問題，過億資料事實上無法實時匯入資料，一般過百億的系統均採用離線建立索引的方式，即資料時效性延遲一天。

2．Solr/ES中資料規模一旦過百億，就會頻繁的出現OOM，節點調片的情況。一旦調片後無法自動恢復服務，需要運維人員去重啟相關服務。系統缺少過載保護，經常是一個人員做了一個複雜的查詢，導致叢集整體宕機，系統崩潰。這導致當資料量過億後，Solr/ES在資料量比較大的情況下，實時索引幾乎是不可能的，頻繁的ord關係對映，會讓整個系統不可用。

9、資料儲存與恢復

Solr/ES索引儲存在本地硬碟，資料恢復比較難：

1．磁碟讀寫沒有很好的控速機制，匯入資料沒有良好的流量控制機制，無法控制流量，而生產系統，磁碟控速與流量控速是必須的，不能因為業務高峰對系統造成較大的衝擊，導致磁碟都hang住或掛掉。

2．本地硬碟區域性壞點，對於Solr/ES來說哪怕是僅僅一個byte資料的讀異常，就會造成索引指標的錯亂，導致檢索結果資料丟失，甚至整個索引廢掉，但是Solr與ES如何及時的發現並修正這些錯誤呢？

3．資料儲存在本地磁碟，一旦本地將近20T的儲存盤損壞，需要從副本恢復後才能繼續服務，恢復時間太長。

10、資料遷移之難

Solr/ES上如何實現跨機房資料遷移，需要運維人員細心的進行索引1對1複製，搬遷方案往往要數星期，且非常容易出錯。而且遷移過程中為了保證資料的一致性，需要中斷服務或者中斷資料的實時匯入，讓資料靜態化落地後不允許在變化後，才能進行遷移。

以上是筆者多年來使用Solr/ES所總結出的十點不足之處，這裡用於拋磚引玉，與各位同學一起探討，共同進步。說到底，Solr/ES並不是全能型的平臺，其早在大資料概念未被提出之前，就已然是全文檢索方面的首選元件了，我們確實不能對他們奢求太高，只是如果以上問題都得以解決，那可謂是一個近乎全能的產品，尤其在OLAP領域面向海量資料分析來講，解決了高效能全文檢索、即席互動式多維分析、企業級特性等多個難題，必將產生深遠影響，感興趣的同學，請加QQ群交流：171465049（驗證口令為vv8086的csdn部落格）或在此給我評論留言。