一、分詞

solr/ES：

對於郵箱、手機號、車牌號碼、網址、IP地址、程式類名、含有字母與數字的組合之類的資料會匹配不完整，導致資料查不全，因分詞導致漏查以及缺失資料，對於模糊檢索有精確匹配要求的場景下，業務存在較大的風險。

YDB：

內建的分詞型別會確保查詢準確度，不會出現漏查，內建的分詞型別，很好的解決了lucene預設分詞導致的查詢資料缺失的問題。另外YDB可以自定義拓展任意的luene分詞型別。如詞庫分詞，語義分詞，拼音分詞等。

二、排序

solr/ES：

採用lucene的Sort介面實現，本質是藉助docvalues的暴力掃描，如果資料量很大排序過程耗費非常多的記憶體與IO，並且排序耗時很高。

YDB：

按照時間逆序排序可以說是很多日誌系統的硬指標。在延雲YDB系統中，我們改變了傳統的暴力排序方式，通過索引技術，可以超快對資料進行單列排序，不需要全表暴力掃描，這個技術我們稱之為blockSort，目前支援tlong,tdouble,tint,tfloat四種資料型別。

由於blockSort是藉助搜尋的索引來實現的，所以,採用blockSort的排序，不需要暴力掃描，效能有大幅度的提升。
詳細測試請參考 http://blog.csdn.net/qq_33160722/article/details/54447022

三、模糊匹配

solr/ES：

基於lucene的分詞來實現，但並不考慮單詞的匹配順序，也不保證匹配詞語的連續性，中間可以穿插其他單詞。

YDB：

1.除了常規lucene的分詞匹配外，YDB還支援類似SQL中的like匹配。

即考慮到了單詞之間的匹配順序，也保證了匹配詞語的連續性，也可以通過*進行模糊查詢。

這個like也使用了lucene倒排索引，並非採用暴力掃描實現，故like效能比常規實現高很多，

2.除了常規匹配外，YDB也提供了額外的近似文字匹配與近似特徵匹配。

近似文字匹配適合對長文字（如文章）進行匹配，可能中間相差幾個字不或者區域性的字順序前後顛倒都沒關係，只要大部分相似就可以匹配上。
近似特徵匹配適合我指定一系列的特徵，如高矮，胖瘦，年齡段，性別，時間等一系列目擊者看到的嫌疑人特徵，但是有可能有些目擊者描述的不準確，所以不能進行精確匹配，如果能與大部分的匹配條件都相似，一兩個條件沒匹配上，但已經足以相似了，那麼也要返回匹配結果。

四、使用者介面

solr/es：

採用java API的方式，使用者學習成本高。

因不是通用的通訊協議，與其他大資料系統整合對接麻煩。

YDB：

採用SQL的方式，使用者學習陳本低。

支援HIVE的JDBC接入（程式設計），可以命令列接入（定時任務），http方式接入。

Hive的JDBC協議，已經是大資料的事實標準。

與常規大資料系統可無縫對接（如hive,spark,kafka等），也提供了拓展介面。

海量資料匯入匯出靈活方便，也可與常見的支援jdbc的報表工具、SQL視覺化工具整合。

五、函式與功能

solr/es：

只支援簡單的檢索過濾,sum,max,min,avg等統計函式，單列group by

YDB：

除了solr/ES的簡單功能外，內建了HIVE上百個函式，支援複雜的SQL，可以巢狀，多表關聯，自定義udf,udaf,udtf，開源界已經有的函式庫如Hivemall等也可以直接整合進來使用。
相對於solr/ES除了基本的資料檢索外，還能做更復雜的分析。如：資料碰撞分析\同行車輛分析\陌生車輛分析\晝伏夜出、落腳點分析\ OLAP之多維分析\指數分析\人群畫像\嫌疑車輛分析等。

六、資料匯出

solr/es：

資料如若想匯出到其他系統很難，大資料量原始資料的匯出基本是不可行的，更別提還要將原始資料經過各種複雜計算後的清洗後的匯出了。

YDB：

支援原始資料的任意維度匯出
可以全表，也可以通過過濾篩選區域性匯出
支援資料經過各種組合計算過濾後的匯出
可以將YDB中的多個表與其他系統的多個表，進行組合篩選過濾計算後在匯出

可以將多個數據從ydb的一張表匯入到YDB的另外一張表
可以將YDB裡面的資料匯出到別的系統裡面（如hive，hbase，資料庫等）
也可以將其他系統的資料匯入到YDB裡面。
可以從匯出成檔案，也可以從檔案匯入。
可以從kafka流式匯入，也可以寫外掛，匯出到kafka。

七、資料匯入

solr/es：

採用API的方式匯入資料

1.支援實時匯入，在千萬資料規模下匯入效能較好。

2.資料過億後，生產系統實時匯入經常會出現OOM，以及CPU負載太高的問題，故過億資料無法實時匯入資料，一般過百億的系統均採用離線建立索引的方式，即資料時效性延遲一天。

3.沒有良好的合併控制策略，系統會發生階段性（幾分鐘）的負載極高的情況（索引合併），此時系統資源佔用特別高，前臺查詢響應速度極慢。

YDB：

採用SQL方式的批量匯入，也支援kafka的流式匯入

1.索引的設計實現，不會想solr與es那樣將資料全部載入到內種記憶體中進行對映，這無論是在匯入還是在查詢過程中均大幅的減少了OOM的風險。

2.在記憶體與磁碟多個區域不同合併策略，在結合控速邏輯，讓匯入佔用的效能控制在一定範圍之內，讓系統更平穩，儘量減少索引合併瞬間產生的幾分鐘佔據了大量的資源的情況，分散資源的佔用，讓前臺使用者的查詢更平穩。

3.結合了storm流式處理的優點，採用對接訊息佇列（如kafka）的方式，資料匯入kafka後大約1~2分鐘即可在ydb中查到。

八、資料儲存與恢復

solr/es：

索引儲存在本地硬碟，恢復難

1.磁碟讀寫沒有很好的控速機制，匯入資料沒有良好的流量控制機制，無法控制流量，而生產系統，磁碟控速與流量控速是必須的，不能因為業務高峰對系統造成較大的衝擊，導致磁碟都hang住或掛掉。
2.本地硬碟區域性壞點，造成區域性資料損壞對於lucene來說無法識別，但是對於索引來說哪怕是僅僅一個byte資料的讀異常，就會造成索引指標的錯亂，導致檢索結果資料丟失，甚至整個索引廢掉，但是solr與es不能及時的發現並修正這些錯誤。
3.資料儲存在本地磁碟，一旦本地將近20T的儲存盤損壞，需要從副本恢復後才能繼續服務，恢復時間太長。

YDB：

將資料儲存在HDFS之上

1.YDB基於HDFS做了磁碟與網路做了讀寫控速邏輯。

2.磁碟區域性壞點hdfs配有crc32校驗，有壞點會立即發現，並不影響服務，會自動切換到沒有壞點的資料繼續讀取。

3.本地磁碟損壞，HDFS自動恢復資料，不會中斷讀寫，不會有服務中斷。

九、資料遷移

solr/es：

1.如若誇機房搬遷機器，需要運維人員細心的進行索引1對1複製，搬遷方案往往要數星期，且非常容易出錯。

2.遷移過程中為了保證資料的一致性，需要中斷服務或者中斷資料的實時匯入，讓資料靜態化落地後不允許在變化後，才能進行遷移。

YDB：

1.hdfs通過balance自動遷移資料。

2.可以控制遷移過程中的頻寬流量。
2.遷移過程中不中斷服務，hdfs擴容與移除機器也對服務沒影響。

十、穩定性

solr/es：

1.資料規模一旦過百億，就會頻繁的出現OOM，節點調片的情況。

2.一旦調片後無法自動恢復服務，需要運維人員去重啟相關服務。

3.系統無過載保護，經常是一個人員做了一個複雜的查詢，導致叢集整體宕機，系統崩潰。
lucene在索引合併過程中，每進行一次commit都要進行一次全範圍的ord關係的重新對映，資料規模小的時候整個索引檔案的對映還沒什麼，但是當資料量達到億級別，甚至百億級別後，這種對映關係會佔用超多的CPU、記憶體、硬碟資源，所以當資料量過億後，solr與Es在資料比較大的情況下，實時索引幾乎是不可能的，頻繁的ord關係對映，會讓整個系統不可用。

YDB：

YDB相對於solr/es底層做了大幅度的改動，更適合海量資料。

1.優化或修正LUCENE的BUG大幅度的縮減了OOM，頻繁調片的風險。

2.服務自動遷移與恢復的特性，大幅減少運維人員駐場的工作量。

3.提供了匯入與查詢的限流控制，也提供了過載保護控制，甚至在極端場景提供了有損查詢與有損服務。