2.與周邊系統的集成非常方便，數據導入導出靈活。

3.支持JDBC方式，可以與常見的報表系統無縫集成

基本無并發性可言。單并發就需要數小時。

的導入導出

1.從一開始設計之初，Hadoop即假設所有的硬件均不可靠，一旦硬件損壞，數據不會丟失，有多份副本可以自動恢復數據。

2.數據遷移以及機器擴容有比較完備的方案，中間不停服務，動態擴容。

2.預計算完畢的結果集存儲在HBase或傳統數據庫里，因數據規模并不大故并發性比較好。

的導入導出

2.本身系統內存的限定，百億以上將會是巨大的挑戰-除非是512G內存的機器，弄個20~30臺左右，且是數據總量百億，而不是每天百億。

2.與周邊系統的集成麻煩，數據導入導出太麻煩，甚至不可行，第三方有SQL引擎插件，但均是簡單SQL，且由于Merger server是單節點的問題，很多SQL的查詢性能很低，不具備通用性。

3.無法與常見的支持jdbc標準的報表系統集成，定制開發代價較大。

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

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

6.solr與es中不支持多列的group by與統計（原因為無法交叉），所謂的實現是通過單列group by后 進行的笛卡爾及，按照每個單元格重新進行的查詢。

2.在千萬級別以下，并且給予較多內存的情況下，并發情況很好。

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

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

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

3.系統無過載保護，經常是一個人員做了一個復雜的查詢，導致集群整體宕機，系統崩潰。

lucene在索引合并過程中，每進行一次commit都要進行一次全范圍的ord關系的重新映射，數據規模小的時候整個索引文件的映射還沒什么，但是當數據量達到億級別，甚至百億級別后，這種映射關系會占用超多的CPU、內存、硬盤資源，所以當數據量過億后，solr與Es在數據比較大的情況下，實時索引幾乎是不可能的，頻繁的ord關系映射，會讓整個系統不可用。

采用lucene的Sort接口實現，本質是借助docvalues的暴力掃描，如果數據量很大排序過程耗費非常多的內存與IO，并且排序耗時很高。

因不是通用的通訊協議，與其他大數據系統集成對接麻煩。

的導入導出

數據如若想導出到其他系統很難，超過百萬級別的導出基本是不可行的,沒有成型的高可用的導出方案。

全量數據導出基本是不可能的，更別談經過多表復雜運算后的導出了

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

2.本地硬盤局部壞點，造成局部數據損壞對于lucene來說無法識別，但是對于索引來說哪怕是僅僅一個byte數據的讀異常，就會造成索引指針的錯亂，導致檢索結果數據丟失，甚至整個索引廢掉，但是solr與es不能及時的發現并修正這些錯誤。

3.數據存儲在本地磁盤，一旦本地將近20T的存儲盤損壞，需要從副本恢復后才能繼續服務，恢復時間太長。

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

2.在延云推薦的普通機器

以給的示例數據預估，每個節點每天實時處理30~50億的數據比較適合。

處理的數據規模以及查詢響應速度，根據節點數線性增長。

2. 內置的分詞類型會確保查詢準確度，不會出現漏查，內置的分詞類型，很好的解決了lucene默認分詞導致的查詢數據缺失的問題。另外YDB可以自定義拓展任意的luene分詞類型。如詞庫分詞，語義分詞，拼音分詞等。

3.能支持任意維度的多維查詢，多維統計，與分析。

但是目前我的真實生產系統，確實沒有很大的并發，最大的并發系統也就是每5分鐘由系統觸發的100并發的檢索查詢，但是查詢完畢后會有5分鐘的休息時間。

每天千億增量，總量可達萬億

2.有守護進程，一旦發現服務異常，自動重啟服務，不需要運維人員親自去機房重啟機器。

3.延云YDB只需要部署在一臺機器上，由Yarn自動分發，不需要維護一堆機器的配置,改參數很方便。易于部署，易于擴容，易于數據遷移；

4.多數據副本保護，硬件不怕硬件損壞；

5.服務異常能自動檢測及恢復，減輕運維人員經常需要半夜起床的痛苦；

系統不能存在任何單點故障，當某個服務器存在問題時不能影響線上業務。

數據過百億后，不能頻繁的OOM，也不能出現節點調片的情況。

系統出現異常后，可以自動偵探服務異常，并自動重啟恢復服務，不能每次調片都要運維   人員半夜去機房重啟。需要服務有自動遷移與恢復的特性，大幅減少運維人員駐場的工作量。

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

7.我們修正了大量的spark的bug，讓系統比開源系統更穩定。

http://blog.csdn.net/qq_33160722/article/details/60583286

技術原理請參考

http://blog.csdn.net/muyannian/article/details/60755273

支持HIVE的JDBC接入（編程），可以命令行接入（定時任務），http方式接入。

Hive的JDBC協議，已經是大數據的事實標準。

與常規大數據系統可無縫對接（如hive,spark,kafka等），也提供了拓展接口。

海量數據導入導出靈活方便，也可與常見的支持jdbc的報表工具、SQL可視化工具集成。

的導入導出

支持原始數據的任意維度導出

可以全表，也可以通過過濾篩選局部導出

支持數據經過各種組合計算過濾后的導出

可以將YDB中的多個表與其他系統的多個表，進行組合篩選過濾計算后在導出

可以將多個數據從ydb的一張表導入到YDB的另外一張表

可以將YDB里面的數據導出到別的系統里面（如hive，hbase，數據庫等）

也可以將其他系統的數據導入到YDB里面。

可以導出成文件，也可以從文件導入。

導入

采用SQL方式的批量導入，也支持kafka的流式導入

1.索引的設計實現，不會想solr與es那樣將數據全部加載到內種內存中進行映射，這無論是在導入還是在查詢過程中均大幅的減少了OOM的風險。

2.在內存與磁盤多個區域不同合并策略，在結合控速邏輯，讓導入占用的性能控制在一定范圍之內，讓系統更平穩，盡量減少索引合并瞬間產生的幾分鐘占據了大量的資源的情況，分散資源的占用，讓前臺用戶的查詢更平穩。

3.結合了storm流式處理的優點，采用對接消息隊列（如kafka）的方式，數據導入kafka后大約1~2分鐘即可在ydb中查到。

1.YDB基于HDFS做了磁盤與網絡做了讀寫控速邏輯。

2.磁盤局部壞點hdfs配有crc32校驗，有壞點會立即發現，并不影響服務，會自動切換到沒有壞點的數據繼續讀取。

3.本地磁盤損壞，HDFS自動恢復數據，不會中斷讀寫，不會有服務中斷。

2.可以控制遷移過程中的帶寬流量。

2.遷移過程中不中斷服務，hdfs擴容與移除機器也對服務沒影響。

內置支持直接將ydb的計算結果導出到oracle,不需要在單獨寫etl程序。

聚焦性能跟命中的記錄條數以及機器磁盤數有很大關系。如果是100量車從3000億條原始數據數據中篩選1.5億條記錄進行統計匯總，6臺集群sata盤的磁盤的iops達不到這個性能，需要ssd磁盤才行。

2.對于kafka消費延遲，節點宕掉，均有預警機制，可以在moniter頁面看到。

2.基于有存儲的預警系統，出現問題后會發出通知報警。

3.如果機器異常頁面也會顯示出warning報警

4.可以自定義報警邏輯

select hphm,kkbh,jgsj,jgsk,quyu from ydb_jiaotong where hphm=”云NEW336″ order by jgsj desc limit 10

/*(‘<-‘)pushdown.ydb*/

from (

/*ydb.pushdown(‘->’)*/

select hphm,jgsj,kkbh from ydb_oribit where ydbpartion = ‘20160619’ and ( (jgsj like ‘([201604290000 to 201604290200] )’ and kkbh=’10000000′) or ( jgsj like ‘([201604290001 to 201604290301] )’ and kkbh=’10000001′) or (jgsj like ‘([201604290002 to 201604290202] )’  and kkbh=’10000002′)  )

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm order by dist_kkbh desc

tmp.hphm,

count(*) as rows,

size(collect_set(tmp.quyu)) as dist_quyu,

concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.quyu)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select hphm,jgsj,quyu from ydb_jiaotong where ( (jgsj like ‘([201604111454 TO 201604131554] )’ and quyu=’安義路閣馨’) or (jgsj like ‘([201609041043 TO 201609041050] )’ and quyu=’恒仁路太陽星城’) or (jgsj like ‘([201609040909 TO 201609040914] )’ and quyu=’環江路大有恬園’

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm order by dist_quyu desc limit 10

給出一個時間范圍【A TO B】,搜尋出一個區域內的所有車輛.

如果在這個時間范圍出現過，并且在之前的 C天內出現次數少于N次的車輛

select

tmp.hphm,

count(*) as rows,

max(tmp.jgsk) as max_jgsj,

size(collect_set(tmp.jgsk)) as dist_jgsj,

size(collect_set(case when ((tmp.jgsk>=’20161201153315′ and tmp.jgsk<=’20161202153315′) or (tmp.jgsk>=’20161203153315′ and tmp.jgsk<=’20161204153315′)) then 0 else tmp.jgsk end  )) as dist_before,

concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsk,tmp.kkbh)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select hphm,jgsk,kkbh from t_kk_clxx where

jgsk like ‘([20161201153315 TO 20161204153315] )’

and kkbh IN(‘320600170000089780′,’320600170000000239′,’320600170000000016′,’320600170000000018′,’320600170000002278′,’320600170000092977′,’320600170000092097′,’320600170000092117’)

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm

) tmp2 where tmp2.dist_before<=’1’ order by tmp2.dist_jgsj asc limit 10

tmp.jgsk,

count(*) as rows,

size(collect_set(tmp.quyu)) as dist_quyu,

concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.quyu)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select jgsk,jgsj,quyu from ydb_jiaotong where hphm=’黑NET458′

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.jgsk order by dist_quyu desc limit 10

注意下面的hphm_search為charlike類型，可以進行號牌號碼的模糊檢索

/*ydb.pushdown(‘->’)*/

select hphm,kkbh from ydb_jiaotong where hphm_search=’NEW33′

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm order by dist_kkbh desc limit 10