國產數據庫，計算性能太強了！
隨著大數據時代的來臨，數據量不斷增長，傳統小機上跑數據庫的模式擴容困難且成本高昂，難以支撐業務發展。很多用戶開始轉向分布式計算路線，用多臺廉價的 PC 服務器組成集群來完成大數據計算任務。Hadoop/Spark 就是其中重要的軟件技術，由于開源免費而廣受歡迎。經過多年的應用和發展，Hadoop 已經被廣泛接受，不僅直接應用于數據計算，還發展出很多基于它的新數據庫，比如 Hive、Impala 等。
對于數據量更大的情況，SPL 實現了輕量級集群計算功能。這一功能的設計目標是幾臺到十幾臺節點的集群，采用了與 Hadoop 完全不同的實現方法。SPL 集群不提供復雜沉重的自動化管理功能，而是允許對每個節點進行個性化配置。程序員可以根據數據特征和計算目標來決定各節點存儲什么樣的數據，完成哪些計算。這樣做，不僅大大降低了架構復雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過產品號字段與較小的產品表主鍵做關聯，再按照產品供應商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個節點的硬盤上，再將較小的產品表讀入每個節點的內存中。計算時，每個節點僅對本機上的訂單分段和產品數據做關聯、分組匯總，可以縮短總計算時間；再將結果傳輸到一個節點上做二次匯總。由于傳輸的是第一次匯總的結果，數據量小、網絡傳輸時間較短。總體來說，這個方案可以獲得最佳性能，雖然程序員需要做一些更細致的工作，但對于小規模集群來說，增加的工作量并不大。SPL 也不提供超強的容錯能力，不會像 Hadoop 那樣，在有節點故障的情況下，還要保證任何一個任務都會執行成功。實際上，大多數計算任務的執行時間都在幾個小時以內，而幾臺、十幾臺機器的集群一般都能做到較長時間正常運行，不會這么頻繁的出故障。即使偶爾出現節點故障導致任務執行失敗，再重新計算一遍也可以接受，畢竟這種情況不會經常發生。所以，SPL 的容錯能力只是保證有少數節點故障的時候，整個集群還能繼續工作并接受新任務（包括重算的任務），這就大大降低了 SPL 集群的復雜度。在內存計算方面，SPL 沒有使用 Spark RDD 的 immutable 機制，而是采用了指針式復用機制，利用地址（指針）訪問內存，在數據結構沒有改變的情況下，直接用原數據的地址形成結果集，不必每個計算都將數據復制一遍，僅僅多保存一個地址（指針），可以同時減少 CPU 和內存的消耗，運行起來要比 Spark 輕很多了。并且，SPL 改進了當前的外存計算算法體系，降低了復雜度并擴大了適應范圍，可以做到內外存計算結合，充分提升計算性能的同時，還不像 Spark 那樣依賴大內存。使用簡單SPL 采用輕量級技術，自然更容易安裝、配置和運行維護。SPL 不僅可以作為獨立服務器使用，還很容易集成到需要高性能計算的應用中，比如即時查詢系統，只要引入幾個 jar 包即可。Hadoop 則很難集成，只能在邊上作為一個數據源運行。有些臨時性數據需要隨時進行處理，則可使用 SPL 的桌面集成開發環境可視化地計算，快速得到結果。如果要安裝部署 Hadoop，那么等環境搭建好時臨時數據任務已經過期了。前面展示的眾多 SPL 高性能算法，也能讓大數據計算編程變得簡單。程序員可以在較短時間內掌握這些算法函數，學習成本相對較低。而且，使用這些現成的函數很容易實現各種復雜的計算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。比如，以電商網站常見的漏斗分析為例，用 SQL 實現三步漏斗的代碼大致如下：
Hadoop/Spark 之重
Hadoop 的設計目標是成百上千臺節點的集群，為此，開發者實現了很多復雜、沉重的功能模塊。但是，除了一些互聯網巨頭企業、國家級通信運營商和大型銀行外，大多數場景的數據量并沒有那么巨大。結果，經常能看到只有幾個到十幾個節點的 Hadoop 集群。由于目標和現實的錯位，對很多用戶來講，Hadoop 成了一個在技術、應用和成本上都很沉重的產品。技術之重如果真的有幾千臺計算機組成的集群，是不可能依靠手工個性化管理的。試想，將這些計算機羅列出來，運維人員看都看不過來，更別說管理和分配任務了。再說，這么多機器，難免會不斷出現各種故障，怎么保證計算任務順利執行？Hadoop/Spark 的開發者為了解決這些問題，編寫了大量代碼，用于實現自動化節點管理、任務分配和強容錯功能。但是，這些功能本身就要占用很多計算資源（CPU、內存和硬盤等），如果用到幾臺到十幾臺節點的集群上，就太過沉重了。集群本來就不大，Hadoop 還要占用相當一部分的資源，非常不劃算。不僅如此，Hadoop 產品線很長，要把這些模塊都放在一個平臺上運行，還要梳理好各個產品之間的相互依賴性，就不得不實現一個包羅萬象的復雜架構。雖然大多數場景只用其中一兩個產品，也必須接受這個復雜、沉重的平臺。后來出現的 Spark 彌補了 Hadoop 對內存利用的不足，技術上是不是可以變輕呢？很遺憾，Spark 走向了另一個極端，從理論模型上就只考慮內存計算了。特別是 Spark 中的 RDD 采用了 immutable 機制，在每個計算步驟后都會復制出新的 RDD，造成內存和 CPU 的大量占用和浪費，離開大內存甚至無法運行，所以技術上還是很重。使用之重Hadoop 技術上太過復雜，也就意味著安裝和運維會很麻煩。集群只有幾臺計算機時，卻不得不使用為幾千臺節點集群設計的節點管理、任務分配和容錯功能。可想而知，安裝、配置、調試都很困難，日常運行的維護、管理工作也不容易。即使克服這些困難讓 Hadoop 運行起來了，編寫大數據計算代碼時還會面臨更大的麻煩。Hadoop 編程的核心框架是 MapReduce，程序員要編寫并行程序，只要寫 Map 和 Reduce 動作即可，用來解決求和、計數等簡單問題也確實有效。但是，遇到復雜一些的業務邏輯，用 MapReduce 編程就會變得非常困難。例如，業務計算中很常見的 JOIN 計算，就很難用 MapReduce 實現。再比如，很多和次序有關的運算實現起來也很困難。Spark 的 Scala 語言具備一定的結構化數據計算能力，是不是能簡單一些呢？很可惜，Scala 使用難度很大，難學更難精。遇到復雜一些的運算邏輯，Scala 也很難寫出來。MapReduce、Scala 都這么難，所以 Hadoop/Spark 計算語法開始回歸 SQL 語言。Hive 可以將 SQL 轉化為 MapReduce 所以很受歡迎，Spark SQL 的應用也比 Scala 廣泛的多。但是，用 SQL 做一些常規查詢還算簡單，用于處理多步驟過程計算或次序相關運算還是非常麻煩，要寫很復雜的 UDF。而且，許多計算場景雖然勉強能用 SQL 實現，但是計算速度卻很不理想，也很難進行性能調優。成本之重雖然 Hadoop 軟件本身開源免費，但它技術復雜、使用困難，會帶來高昂的綜合成本。前面說過，Hadoop 自身會占用過多的 CPU、內存和硬盤，而 Spark 需要大內存支撐才能正常運行。所以不得不為 Hadoop/Spark 采購更高配置的服務器，要增加硬件支出。Hadoop/Spark 使用困難，就需要投入更多的人力去完成安裝、運維，保證 Hadoop/Spark 的正常運轉；還要投入更多的開發人員，編程實現各種復雜的業務計算，要增加人力資源成本。由于使用過于困難，很多用戶不得不采購商業公司的收費版本 Hadoop/Spark，價格相當可觀，會大幅增加軟件采購成本。既然 Hadoop 如此沉重，為什么還有很多用戶會選擇它呢？答案很簡單：暫時找不到別的選擇，也只有 Hadoop 勉強可用，好歹知名度高一些。如此一來，用戶就只能安裝、配置 Hadoop 的重型應用，并忍受 Hadoop 本身對計算資源的大量消耗。小規模集群的服務器數量本來就不多，Hadoop 又浪費了不少，小馬拉大車，最后運行的效果可想而知。花了大價錢采購、費事費力的使用 Hadoop，實際計算的性能卻不理想。就沒有別的選擇了？輕量級的選擇
開源的 esProc SPL 是輕量級大數據計算引擎，采用了全新的實現技術，可以做到技術輕、使用簡單、成本低。技術輕本文開頭說過，越來越大的數據量讓傳統數據庫撐不住，所以用戶只能轉向分布式計算技術。而數據庫之所以撐不住，是因為 SQL 難以實現高速算法，大數據運算性能只能指望數據庫的優化引擎，遇到復雜計算時，優化引擎又常常無能為力。所以，我們應該想辦法設計更高效的算法，而不是一味地追求分布式計算。按照這個思路，SPL 提供了眾多高性能算法（有許多是業界首創）以及高效的存儲方案，同等硬件環境下可以獲得遠超過數據庫的運算性能。安裝在單機上的 SPL 就可以完成很多大數據計算任務，架構比集群簡單很多，從技術上自然就輕的多了。SPL 的高性能算法有下面這些：對于數據量更大的情況，SPL 實現了輕量級集群計算功能。這一功能的設計目標是幾臺到十幾臺節點的集群，采用了與 Hadoop 完全不同的實現方法。SPL 集群不提供復雜沉重的自動化管理功能，而是允許對每個節點進行個性化配置。程序員可以根據數據特征和計算目標來決定各節點存儲什么樣的數據，完成哪些計算。這樣做，不僅大大降低了架構復雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過產品號字段與較小的產品表主鍵做關聯，再按照產品供應商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個節點的硬盤上，再將較小的產品表讀入每個節點的內存中。計算時，每個節點僅對本機上的訂單分段和產品數據做關聯、分組匯總，可以縮短總計算時間；再將結果傳輸到一個節點上做二次匯總。由于傳輸的是第一次匯總的結果，數據量小、網絡傳輸時間較短。總體來說，這個方案可以獲得最佳性能，雖然程序員需要做一些更細致的工作，但對于小規模集群來說，增加的工作量并不大。SPL 也不提供超強的容錯能力，不會像 Hadoop 那樣，在有節點故障的情況下，還要保證任何一個任務都會執行成功。實際上，大多數計算任務的執行時間都在幾個小時以內，而幾臺、十幾臺機器的集群一般都能做到較長時間正常運行，不會這么頻繁的出故障。即使偶爾出現節點故障導致任務執行失敗，再重新計算一遍也可以接受，畢竟這種情況不會經常發生。所以，SPL 的容錯能力只是保證有少數節點故障的時候，整個集群還能繼續工作并接受新任務（包括重算的任務），這就大大降低了 SPL 集群的復雜度。在內存計算方面，SPL 沒有使用 Spark RDD 的 immutable 機制，而是采用了指針式復用機制，利用地址（指針）訪問內存，在數據結構沒有改變的情況下，直接用原數據的地址形成結果集，不必每個計算都將數據復制一遍，僅僅多保存一個地址（指針），可以同時減少 CPU 和內存的消耗，運行起來要比 Spark 輕很多了。并且，SPL 改進了當前的外存計算算法體系，降低了復雜度并擴大了適應范圍，可以做到內外存計算結合，充分提升計算性能的同時，還不像 Spark 那樣依賴大內存。使用簡單SPL 采用輕量級技術，自然更容易安裝、配置和運行維護。SPL 不僅可以作為獨立服務器使用，還很容易集成到需要高性能計算的應用中，比如即時查詢系統，只要引入幾個 jar 包即可。Hadoop 則很難集成，只能在邊上作為一個數據源運行。有些臨時性數據需要隨時進行處理，則可使用 SPL 的桌面集成開發環境可視化地計算，快速得到結果。如果要安裝部署 Hadoop，那么等環境搭建好時臨時數據任務已經過期了。前面展示的眾多 SPL 高性能算法，也能讓大數據計算編程變得簡單。程序員可以在較短時間內掌握這些算法函數，學習成本相對較低。而且，使用這些現成的函數很容易實現各種復雜的計算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。比如，以電商網站常見的漏斗分析為例，用 SQL 實現三步漏斗的代碼大致如下：
with e1 as (
select gid,1 as step1,min(etime) as t1
fromT
whereetime>=to_date('2021-01-10','yyyy-MM-dd')andetime<to_date('2021-01-25','yyyy-MM-dd')
andeventtype='eventtype1'and…
groupby1
),
withe2as(
selectgid,1asstep2,min(e1.t1)ast1,min(e2.etime)ast2
fromTase2
innerjoine1one2.gid=e1.gidwheree2.etime>=to_date('2021-01-10','yyyy-MM-dd')ande2.etime<to_date('2021-01-25','yyyy-MM-dd')
and e2.etime > t1
and e2.etime < t1 + 7
and eventtype='eventtype2' and …
group by 1
),
withe3as(
selectgid,1asstep3,min(e2.t1)ast1,min(e3.etime)ast3
fromTase3
innerjoine2one3.gid=e2.gid
wheree3.etime>=to_date('2021-01-10','yyyy-MM-dd')ande3.etime<to_date('2021-01-25','yyyy-MM-dd')
and e3.etime > t2
and e3.etime < t1 + 7
and eventtype='eventtype3' and …
groupby1
)
select
sum(step1) as step1,
sum(step2) as step2,
sum(step3) as step3
from
e1
left join e2 on e1.gid = e2.gid
left join e3 on e2.gid = e3.gid
SQL 寫出來要三十多行，理解起來有相當的難度。如果用 MapReduce/Scala 來寫，會更加困難。即使是用 SQL 實現，寫出來的這段代碼和漏斗的步驟數量相關，每增加一步就要再增加一段子查詢。相比之下，SPL 就簡單得多，處理任意步驟數都是下面這樣簡潔的代碼：| A | B | |
| 1 | =["etype1","etype2","etype3"] | =file("event.ctx").open() |
| 2 |
=B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime |
|
| 3 | =A2.group(id).(~.sort(etime)) | =A3.new(~.select@1(etype==A1(1)):first,~:all).select(first) |
| 4 |
=B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime |
|
| 5 | =A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3) | |
SPL 集群計算的代碼也非常簡單，比如前面提到的訂單分析計算，具體要求是：大訂單表分段存儲在 4 個節點上，小產品表則加載到每個節點的內存中，兩表關聯之后要按照產品供應商分組匯總訂單金額。用 SPL 寫出來大致是下面這樣：
|
A |
B |
|
|
1 |
["192.168.0.101:8281","192.168.0.102:8281",…, "192.168.0.104:8281"] |
|
|
2 |
fork to(4);A1 |
=file("product.ctx").open().import() |
|
3 |
>env(PRODUCT,B2) |
|
|
4 |
=memory(A1,PRODUCT) |
|
|
5 |
=file("orders.ctx":to(4),A1).open().cursor(p_id,quantity) |
|
|
6 |
=A5.switch(p_id,A4) |
|
|
7 |
=A7.groups(p_id.vendor;sum(p_id.price*quantity)) |
|
這段代碼執行時，任務管理（內存加載、任務拆分、合并等）所需要的計算資源，遠遠小于關聯和分組匯總計算的消耗。如此輕便的任務管理功能，可以在任意節點、甚至是集成開發環境 IDE 上執行。
成本低與 Hadoop 相同，SPL 也是開源軟件，不同的是 SPL 不僅軟件免費，綜合成本也非常低。SPL 安裝、配置、運維很容易，可以大大降低支持人員的人力資源成本。同時，由于 SPL 降低了大數據計算編程的難度，程序員很容易實現各種復雜的計算，開發效率顯著提高，也就節省了程序員的人力資源成本。而且，由于 SPL 技術體系非常輕，平臺自身占用的 CPU、內存和硬盤很少，可以讓更多的資源用于業務計算，能大幅提高硬件利用率。SPL 也不像 Spark 那樣依賴大內存，總體來說，大大減少了硬件采購成本。SPL 既輕且快
SPL 技術輕、自身消耗小，而且還提供了眾多高性能算法，所以，在幾個到幾十個節點的集群，甚至單機的情況下，比 Hadoop/Spark 有更好的性能表現。案例 1：某電商漏斗分析計算。Spark：6 節點，每節點 4CPU 核，平均計算時間：25 秒。SPL：單機，8 線程計算，平均計算時間可達 10 秒。代碼量僅有 Spark Scala 的一半。案例 2：某大型銀行用戶畫像分析。Hadoop 上某 OLAP 服務器：虛擬機 100CPU 核，計算時間：120 秒。SPL：虛擬機 12CPU 核，計算時間：僅 4 秒。性能提高 250 倍。 案例 3：某商業銀行的手機銀行 APP，活期明細查詢，數據量大且高并發。基于 Hadoop 的某商用數據倉庫：高并發時無法達到秒級的響應速度，只好換用 6 臺 ES 集群。SPL 單機：達到 6 臺 ES 集群同樣的并發和響應能力。總結來說，Hadoop/Spark 是源自頭部互聯網企業的重型解決方案，適合需要有超大規模集群的巨大企業。很多場景的數據雖然也不少，但小集群甚至無集群就足夠處理，遠沒多到這些巨大企業的規模，也沒有那么多的硬件設備和維護人員。這種情況下，輕量級的大數據計算引擎 SPL 是首選，投入很低的成本，就可以做到技術輕、使用簡便，而且還能提高開發效率、達到更高的性能。GitHub：https://github.com/SPLWare/esProc
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。
舉報投訴
-
cpu
+關注
關注
68文章
10854瀏覽量
211589 -
數據庫
+關注
關注
7文章
3794瀏覽量
64362 -
大數據
+關注
關注
64文章
8882瀏覽量
137403
原文標題：國產數據庫，計算性能太強了！
文章出處：【微信號：芋道源碼，微信公眾號：芋道源碼】歡迎添加關注！文章轉載請注明出處。
發布評論請先 登錄
相關推薦
數據庫廠商都怕低價競爭？阿里云說并不可懼
，我們來看看云原生數據庫由內而外有哪些具體的與眾不同?經過優化的計算和存儲引擎使得POLARDB讀性能可達百萬QPS，寫性能超過13萬QPS;采用計
發表于 05-11 11:02
數據庫性能評測指標及其測試方法
近些年來，國產數據庫得到了快速的發展，但是針對其性能的測試方法和測試指標卻參差不齊。針對上述問題，中國軟件評測中心在大量數據庫測試的基礎之上，參考國際
發表于 03-17 15:22
?79次下載
提高Oracle的數據庫性能
在Oracle數據庫設計中長期受到設計人員重視的是如何更好更快地提高Oracle數據庫性能的問題。其中對數據庫表現有較大關聯的是兩個因素，一是執行SQL語句的速度問題；二是
發表于 11-11 18:16
?4次下載
數據庫教程之如何進行數據庫設計
本文檔的主要內容詳細介紹的是數據庫教程之如何進行數據庫設計內容包括了：1 數據庫設計概述 ，2 數據庫需求分析 ，3 數據庫結構設計 ，4
發表于 10-19 10:41
?21次下載
Serverless 解惑—函數計算如何訪問 MySQL 數據庫
任務，并提供日志查詢、性能監控和報警等功能。借助函數計算，您可以快速構建任何類型的應用和服務，并且只需為任務實際消耗的資源付費。 訪問 MySQL 數據庫是指在函數計算中通過編寫代碼調
發表于 03-09 16:52
?715次閱讀
國產數據庫真的迎來轉折點了嗎？
下一步，永遠比這一步更難。 數據庫與操作系統、中間件是計算機基礎的三大軟件。 “缺芯少魂”之痛常讓人為國產操作系統的不足捏一把汗，而數據庫卻更像藏在水面之下的冰山，甚少有人關注。現在，
華為云數據庫\-GaussDB for MySQL數據庫
華為云更可靠，技術強、創新快、資源多的特點。華為云采用了最新的DFV分布式存儲技術，架構方面使用了計算存儲分離架構，存儲還最高支持128TB的海量存儲，可以實現超百萬級QPS吞吐，還支持跨AZ部署，故障秒級切換，既擁有商業數據庫的性能
國產自研數據庫是更新換代首選
了極為重要的轉型升級。特別是在自主創新的時代背景下，國產數據庫的快速崛起更是令人側目。那么作為國產數據庫的代表之一，華為云數據庫對此有著怎樣
python讀取數據庫數據 python查詢數據庫 python數據庫連接
python讀取數據庫數據 python查詢數據庫 python數據庫連接 Python是一門高級編程語言，廣泛應用于各種領域。其中，Python在
星瑞格國產數據庫SinoDB“的進階之路”
人民幣），占全球的7.2%。預計到2027年，中國數據庫市場總規模將達到1286.8億元。在不斷加劇的行業競爭和不斷變換的市場格局中，國產數據庫的加速發展，已成為時代的必然。
星火夜話，論道國產數據庫
”活動，希望能夠傳承薩師煊先生研究中國數據庫之初心，共話國產數據庫技術創新，共釋填補福建省基礎軟件領域空白的技術路線，共謀福建省信創新質生產力發展之道，照亮我國數據庫技術、產業傳承奮進
工商網監
評論