排序可以說是很多日誌系統的硬指標（如按照時間逆序排序），如果一個大數據系統不能進行排序，基本上是這個系統屬於不可用狀態，排序算得上是大數據系統的一個“剛需”,無論大數據採用的是hadoop,還是spark，還是impala,hive，總之排序是必不可少的，排序的性能測試也是必不可少的。
有着計算奧運會之稱的Sort Benchmark全球排序每年都會舉行一次，每年巨頭都會在排序上進行巨大的投入，可見排序速度的高低有多麼重要！但是對於大多數企業來說，動輒上億的硬件投入，實在划不來、甚至遠遠超出了企業的項目預算。相比大數據領域的暴力排序有沒有一種更廉價的實現方式？
在這裏，我們爲大家介紹一種新的廉價排序方法，我們稱爲blockSort。
500G的數據300億條數據，只使用4臺 16核，32G內存，千兆網卡的虛擬機即可實現 2~15秒的 排序 （可以全表排序，也可以與任意篩選條件篩選後排序）。
一、基本的思想是這樣的，如下圖所示：
1.將數據按照大小預先劃分好，如劃分成 大、中、小三個塊(block)。
2.如果想找最大的數據，那麼只需要在最大的那個塊裏去找就可以了。
3.這個快還是有層級結構的，如果每個塊內的數據量很多，可以到下面的子快內進行繼續查找，可以分多個層進行排序。
4.採用這種方法，一個億萬億級別的數據（如long類型），最壞最壞的極端情況也就進行2048次文件seek就可以篩選到結果。
怎麼樣，原理是不是非常簡單，這樣數據量即使特別多，那麼排序與查找的次數是固定的。
二、這個是我們之前基於spark做的性能測試，供大家參考
在排序上，YDB具有絕對優勢，無論是全表，還是基於任意條件組合過濾，基本秒殺Spark任何格式。
測試結果(時間單位爲秒)
測試過程視頻地址
https://v.qq.com/x/page/q0371wjj8fb.html
https://v.qq.com/x/page/n0371l0ytji.html
感興趣的讀者也可以閱讀YDB編程指南 http://url.cn/42R4CG8 。也可以參考該書自己安裝延雲YDB進行測試。
三、當然除了排序上，我們的其他性能也是遠遠高於spark，這塊大家也可以瞭解一下
1、與Spark txt在檢索上的性能對比測試。
註釋：備忘。下圖的這塊，其實沒什麼特別的，只不過由於YDB本身索引的特性，不想spark那樣暴力，纔會導致在掃描上的性能遠高於spark，性能高百倍不足爲奇。
下圖爲ydb相對於spark txt提升的倍數
2、這些是與 Parquet 格式對比（單位爲秒） 
3、與ORACLE性能對比
跟傳統數據庫的對比，已經沒啥意義，Oracle不適合大數據，任意一個大數據工具都遠超oracle 性能。
 |
4.稽查布控場景性能測試
四、YDB是怎麼樣讓spark加速的？
基於Hadoop分佈式架構下的實時的、多維的、交互式的查詢、統計、分析引擎，具有萬億數據規模下的秒級性能表現，並具備企業級的穩定可靠表現。
YDB是一個細粒度的索引，精確粒度的索引。數據即時導入，索引即時生成，通過索引高效定位到相關數據。YDB與Spark深度集成，Spark對YDB檢索結果集直接分析計算，同樣場景讓Spark性能加快百倍。
五、哪些用戶適合使用YDB？
1.傳統關係型數據，已經無法容納更多的數據，查詢效率嚴重受到影響的用戶。
2.目前在使用SOLR、ES做全文檢索，覺得solr與ES提供的分析功能太少，無法完成複雜的業務邏輯，或者數據量變多後SOLR與ES變得不穩定，在掉片與均衡中不斷惡性循環，不能自動恢復服務，運維人員需經常半夜起來重啓集羣的情況。
3.基於對海量數據的分析，但是苦於現有的離線計算平臺的速度和響應時間無滿足業務要求的用戶。
4.需要對用戶畫像行爲類數據做多維定向分析的用戶。
5.需要對大量的UGC（User Generate Content）數據進行檢索的用戶。
6.當你需要在大數據集上面進行快速的，交互式的查詢時。
7.當你需要進行數據分析，而不只是簡單的鍵值對存儲時。
8.當你想要分析實時產生的數據時。
視頻地址 （看不清的同學可以進入騰訊視頻 高清播放）
https://v.qq.com/x/page/q0371wjj8fb.html
https://v.qq.com/x/page/n0371l0ytji.html
感興趣的讀者也可以閱讀YDB編程指南 http://ycloud.net.cn/download 。也可以參考該書自己安裝延雲YDB進行測試。