?? 作者簡介：No8g攻城獅，熱衷分享，喜歡原創~ 關注我會給你帶來一些不一樣的認知和成長，專注于研究 Java/Spring/SpringBoot/大資料/計算機底層原理/原始碼，就職于大型物聯網公司后端高級工程師，擅長物聯網領域的高安全/可用/并發/性能的架構設計與演進、系統優化與穩定性建設，??
?? CSDN認證博客專家博主/后端領域優質創作者/內容合伙人、阿里云/華為云/簽約博主、InfoQ/掘金社區/OSCHINA簽約作者，全網7萬多粉絲支持！ ??
?? 如果此文還不錯的話，還請??點贊、關注、收藏三連支持??一下博主~ 十分感謝，發布的博客會不定期送書的福利哈~ ??
我們之前做過一些性能優化的案例，不算很多，還沒有失手過，少則提速數倍，多則數十倍，極端情況還有提速上千倍的，提速一個數量級基本上是常態，下面是一些案例材料：
開源 SPL 提速保險公司團保明細單查詢 2000+ 倍
開源 SPL 提升銀行自助分析從 5 并發到 100 并發
開源 SPL 提速銀行用戶畫像客群交集計算 200+ 倍
開源 SPL 優化銀行預計算固定查詢成實時靈活查詢
開源 SPL 將銀行手機賬戶查詢的預先關聯變成實時關聯
開源 SPL 提速銀行資金頭寸報表 20+ 倍
開源 SPL 提速銀行貸款協議跑批 10+ 倍
開源 SPL 優化保險公司跑批優從 2 小時到 17 分鐘
開源 SPL 提速銀行 POS 機交易報表 30+ 倍
開源 SPL 提速銀行貸款跑批任務 150+ 倍
開源 SPL 提速資產負債表 60 倍
這是怎么做到的呢？
這些被提速的場景都有一個共同點：原先都是用各種資料庫（也有HADOOP/Spark）上的SQL實作的，包括查詢用的幾百行SQL也有跑批用的幾千行存盤程序，然后我們改用集算器的SPL重新實作之后就有了這樣的效果，
集算器SPL有什么神奇之處？是不是能讓各種運算跑得更快？
有點遺憾，并沒有這樣的好事，集算器也是一個軟體，而且是用Java寫的，完成同樣運算通常比C/C++寫的資料庫還要慢一點，
那是怎么回事？
根本原因在于我們用SPL實作了不同的演算法，軟體不能提高硬體的速度，但我們可以設計出更低復雜度的演算法，有效地減少計算量，然后速度自然就上去了，一個運算任務本來要做1億次加法，如果能減到100萬次，那自然就能快100倍，即使每次運算都變得稍慢一點，總體性能仍然會提高，這一點也不神奇，
只要能實作高性能演算法和存盤，用什么技術來做并不重要了，用C/C++、Java當然都能做出來，事實上，集算器是用Java寫的，用Java直接實作這些演算法原則上還會更快一點，用C/C++ 一般還能更快（Java的記憶體分配消耗時間還是有點多），
不過，雖然用Java和C++能寫出比SPL更快的代碼，但要長得多（估計會長出50-100倍），這會導致開發作業量過大，這在實際應用時也是要權衡的一個指標，有時候，跑得快和寫著簡單其實是一回事，就是能高效率地實作高性能演算法，
集算器的SPL中強化了結構化資料的資料型別，并提供了很多基礎的高性能演算法，寫代碼就是組合運用這些演算法，當然會方便得多，要說神奇之處，也就是這一點了，
那么，繼續SQL就不能做到同樣的事嗎？
是的，SQL設計得過于粗線條，關系代數這個理論基礎中缺乏很多資料型別和基礎運算，很多高性能演算法都無法描述，結果只能使用慢演算法，雖然現在很多資料庫和大資料平臺都在工程上有所優化，但也只能針對簡單的場景，情況復雜之后資料庫的優化器都會“暈”掉，所以解決不了根本問題，這是個理論上的問題，無法在工程層面解決，
SPL基于的理論基礎不再是關系代數，而是我們發明的離散資料集，在這個體系下有更多的資料型別和運算，就能寫出更多高性能演算法了，SPL是離散資料集的一種實作，封裝了許多現成的演算法，用Java和C++當然也能從頭來實作這個代數體系，因而都能寫出來高性能代碼，而SQL卻不可以，
舉個簡單的例子，我們想在1億條資料中取出前10名，用SQL寫出來是這樣的：
select top 10 x,y from T order by x desc
這個陳述句中有個order by，嚴格按它執行就會涉及大排序，而排序非常慢，其實我們可以想出一個不用大排序的演算法，但用SQL卻無法描述，只能指望資料庫優化器了，對于這句SQL描述的簡單情況，很多商用資料庫確實都能優化，使用不必大排序的演算法，性能通常很好，但情況復雜一些，比如在每個分組中取前10名，要用視窗函式和子查詢把SQL寫成這樣：
select * from
(select y,*,row_number() over (partition by y order by x desc) rn from T)
where rn<=10
這時候，資料庫優化器就會犯暈了，猜不出這句SQL的目的，只能老老實實地執行排序的邏輯（這個陳述句中還是有order by的字樣），結果性能陡降，
而SPL不一樣，離散資料集中有普遍集合的概念，TopN這種運算被認為是和SUM和COUNT一樣的聚合運算，只不過回傳值是個集合而已，這時候寫出來的取前10名的陳述句中并沒有排序動作：
T.groups(;top(-5;x))
分組后的寫法也很簡單，都不需要執行大排序：
T.groups(y;top(-5;x))
這里 性能優化技巧：TopN 還有關于這個問題的更詳細測驗對比，
所以，我們做性能優化時要重寫代碼，不能繼續使用SQL保持兼容，要讀懂原來的邏輯重新實作，這個作業量還是很大的，不過能換來數倍數十倍的性能提升，常常還是值得的，
另外，存盤也非常重要，好演算法要有合適的存盤機制配合才能生效，所以不能繼續把資料繼續存在資料庫里獲得高性能，需要搬出來換種辦法組織存放，改變存盤后，有可能把原來需要快取的計算程序變成不需要了，原來要遍歷多遍的運算變成只遍歷一次甚至不用遍歷了，減少硬碟訪問量對性能的提升非常有效，
從上面這個原理上看，如果我們不能針對計算目標設計出更好的演算法，那就做不到提速了，比如一個很簡單的大表求和，用SQL要做1億次，用SPL也要做1億次，那就不可能做得更快，一般還會更慢一點（Java趕不上C/C++），但是，當運算任務足夠復雜時，碰到幾百上千行的嵌套N層SQL（慢的SQL通常也不會太簡單），幾乎總能找到足夠多可優化的環節，所以我們經歷過的案子還沒有失手過，結果，在實踐上用Java寫出來集算器大幅度超越了C/C++寫的資料庫，這都是演算法造就的，
我們甚至曾經發過一個廣告 慢得受不了的查詢跑批
尋找用SQL寫的慢程序，我們負責提速一個數量級，
換個角度再看這個提速原理：高性能靠的不是代碼，而是代數，代碼只是個實作手段而已，其中最關鍵的是掌握和運用這些演算法，而不是SPL語法，SPL語法很簡單，比Java容易多了，兩小時就能基本上手，兩三周就能比較熟練了，但演算法卻沒那么簡單，需要認真學習反復練習才能掌握，這些案例直接由沒有經驗的用戶自己做常常效果并不好，主要原因也是對演算法沒有吃透，
反過來，而只要掌握了演算法，用什么語法就是個相對次要的問題了（當然用SQL這種太粗線條的語言還是不行），這就像給病人看病，找出病理原因后，能分析出什么成分的藥能管用，無論直接購買成藥（使用封裝過的SPL），還是上山采藥（使用Java/C++硬寫），都可以治好病，無非就是麻煩程度和支付成本不同，
可能有讀者對SPL提供了哪些與SQL不同的高性能演算法感興趣，推薦一下乾學院上的性能優化圖書 【性能優化】 前言及目錄 和視頻課程 《性能優化》課程
我們已經把這些演算法都整理成有體系的知識了，有些演算法是業界首創的，其它教科書和論文中都找不到，
跟著這些圖書課程學習，掌握這些演算法后，就可以自己寫到快出數量級的高性能代碼，即使自己不寫代碼，也能理解原理，不會再被很多大資料產品喊什么“萬億秒查”的說法忽悠了，
SPL資料
- SPL官網
- SPL下載
- SPL源代碼
**本文首發于CSDN，為博主原創文章，如果需要轉載，請注明出處，謝謝！**
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/539895.html
標籤：其他