國產(chǎn)數(shù)據(jù)庫，計算性能太強了！
隨著大數(shù)據(jù)時代的來臨，數(shù)據(jù)量不斷增長，傳統(tǒng)小機上跑數(shù)據(jù)庫的模式擴容困難且成本高昂，難以支撐業(yè)務(wù)發(fā)展。很多用戶開始轉(zhuǎn)向分布式計算路線，用多臺廉價的 PC 服務(wù)器組成集群來完成大數(shù)據(jù)計算任務(wù)。Hadoop/Spark 就是其中重要的軟件技術(shù)，由于開源免費而廣受歡迎。經(jīng)過多年的應(yīng)用和發(fā)展，Hadoop 已經(jīng)被廣泛接受，不僅直接應(yīng)用于數(shù)據(jù)計算，還發(fā)展出很多基于它的新數(shù)據(jù)庫，比如 Hive、Impala 等。
對于數(shù)據(jù)量更大的情況，SPL 實現(xiàn)了輕量級集群計算功能。這一功能的設(shè)計目標(biāo)是幾臺到十幾臺節(jié)點的集群，采用了與 Hadoop 完全不同的實現(xiàn)方法。SPL 集群不提供復(fù)雜沉重的自動化管理功能，而是允許對每個節(jié)點進(jìn)行個性化配置。程序員可以根據(jù)數(shù)據(jù)特征和計算目標(biāo)來決定各節(jié)點存儲什么樣的數(shù)據(jù)，完成哪些計算。這樣做，不僅大大降低了架構(gòu)復(fù)雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過產(chǎn)品號字段與較小的產(chǎn)品表主鍵做關(guān)聯(lián)，再按照產(chǎn)品供應(yīng)商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個節(jié)點的硬盤上，再將較小的產(chǎn)品表讀入每個節(jié)點的內(nèi)存中。計算時，每個節(jié)點僅對本機上的訂單分段和產(chǎn)品數(shù)據(jù)做關(guān)聯(lián)、分組匯總，可以縮短總計算時間；再將結(jié)果傳輸?shù)揭粋€節(jié)點上做二次匯總。由于傳輸?shù)氖堑谝淮螀R總的結(jié)果，數(shù)據(jù)量小、網(wǎng)絡(luò)傳輸時間較短。總體來說，這個方案可以獲得最佳性能，雖然程序員需要做一些更細(xì)致的工作，但對于小規(guī)模集群來說，增加的工作量并不大。SPL 也不提供超強的容錯能力，不會像 Hadoop 那樣，在有節(jié)點故障的情況下，還要保證任何一個任務(wù)都會執(zhí)行成功。實際上，大多數(shù)計算任務(wù)的執(zhí)行時間都在幾個小時以內(nèi)，而幾臺、十幾臺機器的集群一般都能做到較長時間正常運行，不會這么頻繁的出故障。即使偶爾出現(xiàn)節(jié)點故障導(dǎo)致任務(wù)執(zhí)行失敗，再重新計算一遍也可以接受，畢竟這種情況不會經(jīng)常發(fā)生。所以，SPL 的容錯能力只是保證有少數(shù)節(jié)點故障的時候，整個集群還能繼續(xù)工作并接受新任務(wù)（包括重算的任務(wù)），這就大大降低了 SPL 集群的復(fù)雜度。在內(nèi)存計算方面，SPL 沒有使用 Spark RDD 的 immutable 機制，而是采用了指針式復(fù)用機制，利用地址（指針）訪問內(nèi)存，在數(shù)據(jù)結(jié)構(gòu)沒有改變的情況下，直接用原數(shù)據(jù)的地址形成結(jié)果集，不必每個計算都將數(shù)據(jù)復(fù)制一遍，僅僅多保存一個地址（指針），可以同時減少 CPU 和內(nèi)存的消耗，運行起來要比 Spark 輕很多了。并且，SPL 改進(jìn)了當(dāng)前的外存計算算法體系，降低了復(fù)雜度并擴大了適應(yīng)范圍，可以做到內(nèi)外存計算結(jié)合，充分提升計算性能的同時，還不像 Spark 那樣依賴大內(nèi)存。使用簡單SPL 采用輕量級技術(shù)，自然更容易安裝、配置和運行維護(hù)。SPL 不僅可以作為獨立服務(wù)器使用，還很容易集成到需要高性能計算的應(yīng)用中，比如即時查詢系統(tǒng)，只要引入幾個 jar 包即可。Hadoop 則很難集成，只能在邊上作為一個數(shù)據(jù)源運行。有些臨時性數(shù)據(jù)需要隨時進(jìn)行處理，則可使用 SPL 的桌面集成開發(fā)環(huán)境可視化地計算，快速得到結(jié)果。如果要安裝部署 Hadoop，那么等環(huán)境搭建好時臨時數(shù)據(jù)任務(wù)已經(jīng)過期了。前面展示的眾多 SPL 高性能算法，也能讓大數(shù)據(jù)計算編程變得簡單。程序員可以在較短時間內(nèi)掌握這些算法函數(shù)，學(xué)習(xí)成本相對較低。而且，使用這些現(xiàn)成的函數(shù)很容易實現(xiàn)各種復(fù)雜的計算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。比如，以電商網(wǎng)站常見的漏斗分析為例，用 SQL 實現(xiàn)三步漏斗的代碼大致如下：
Hadoop/Spark 之重
Hadoop 的設(shè)計目標(biāo)是成百上千臺節(jié)點的集群，為此，開發(fā)者實現(xiàn)了很多復(fù)雜、沉重的功能模塊。但是，除了一些互聯(lián)網(wǎng)巨頭企業(yè)、國家級通信運營商和大型銀行外，大多數(shù)場景的數(shù)據(jù)量并沒有那么巨大。結(jié)果，經(jīng)常能看到只有幾個到十幾個節(jié)點的 Hadoop 集群。由于目標(biāo)和現(xiàn)實的錯位，對很多用戶來講，Hadoop 成了一個在技術(shù)、應(yīng)用和成本上都很沉重的產(chǎn)品。技術(shù)之重如果真的有幾千臺計算機組成的集群，是不可能依靠手工個性化管理的。試想，將這些計算機羅列出來，運維人員看都看不過來，更別說管理和分配任務(wù)了。再說，這么多機器，難免會不斷出現(xiàn)各種故障，怎么保證計算任務(wù)順利執(zhí)行？Hadoop/Spark 的開發(fā)者為了解決這些問題，編寫了大量代碼，用于實現(xiàn)自動化節(jié)點管理、任務(wù)分配和強容錯功能。但是，這些功能本身就要占用很多計算資源（CPU、內(nèi)存和硬盤等），如果用到幾臺到十幾臺節(jié)點的集群上，就太過沉重了。集群本來就不大，Hadoop 還要占用相當(dāng)一部分的資源，非常不劃算。不僅如此，Hadoop 產(chǎn)品線很長，要把這些模塊都放在一個平臺上運行，還要梳理好各個產(chǎn)品之間的相互依賴性，就不得不實現(xiàn)一個包羅萬象的復(fù)雜架構(gòu)。雖然大多數(shù)場景只用其中一兩個產(chǎn)品，也必須接受這個復(fù)雜、沉重的平臺。后來出現(xiàn)的 Spark 彌補了 Hadoop 對內(nèi)存利用的不足，技術(shù)上是不是可以變輕呢？很遺憾，Spark 走向了另一個極端，從理論模型上就只考慮內(nèi)存計算了。特別是 Spark 中的 RDD 采用了 immutable 機制，在每個計算步驟后都會復(fù)制出新的 RDD，造成內(nèi)存和 CPU 的大量占用和浪費，離開大內(nèi)存甚至無法運行，所以技術(shù)上還是很重。使用之重Hadoop 技術(shù)上太過復(fù)雜，也就意味著安裝和運維會很麻煩。集群只有幾臺計算機時，卻不得不使用為幾千臺節(jié)點集群設(shè)計的節(jié)點管理、任務(wù)分配和容錯功能。可想而知，安裝、配置、調(diào)試都很困難，日常運行的維護(hù)、管理工作也不容易。即使克服這些困難讓 Hadoop 運行起來了，編寫大數(shù)據(jù)計算代碼時還會面臨更大的麻煩。Hadoop 編程的核心框架是 MapReduce，程序員要編寫并行程序，只要寫 Map 和 Reduce 動作即可，用來解決求和、計數(shù)等簡單問題也確實有效。但是，遇到復(fù)雜一些的業(yè)務(wù)邏輯，用 MapReduce 編程就會變得非常困難。例如，業(yè)務(wù)計算中很常見的 JOIN 計算，就很難用 MapReduce 實現(xiàn)。再比如，很多和次序有關(guān)的運算實現(xiàn)起來也很困難。Spark 的 Scala 語言具備一定的結(jié)構(gòu)化數(shù)據(jù)計算能力，是不是能簡單一些呢？很可惜，Scala 使用難度很大，難學(xué)更難精。遇到復(fù)雜一些的運算邏輯，Scala 也很難寫出來。MapReduce、Scala 都這么難，所以 Hadoop/Spark 計算語法開始回歸 SQL 語言。Hive 可以將 SQL 轉(zhuǎn)化為 MapReduce 所以很受歡迎，Spark SQL 的應(yīng)用也比 Scala 廣泛的多。但是，用 SQL 做一些常規(guī)查詢還算簡單，用于處理多步驟過程計算或次序相關(guān)運算還是非常麻煩，要寫很復(fù)雜的 UDF。而且，許多計算場景雖然勉強能用 SQL 實現(xiàn)，但是計算速度卻很不理想，也很難進(jìn)行性能調(diào)優(yōu)。成本之重雖然 Hadoop 軟件本身開源免費，但它技術(shù)復(fù)雜、使用困難，會帶來高昂的綜合成本。前面說過，Hadoop 自身會占用過多的 CPU、內(nèi)存和硬盤，而 Spark 需要大內(nèi)存支撐才能正常運行。所以不得不為 Hadoop/Spark 采購更高配置的服務(wù)器，要增加硬件支出。Hadoop/Spark 使用困難，就需要投入更多的人力去完成安裝、運維，保證 Hadoop/Spark 的正常運轉(zhuǎn)；還要投入更多的開發(fā)人員，編程實現(xiàn)各種復(fù)雜的業(yè)務(wù)計算，要增加人力資源成本。由于使用過于困難，很多用戶不得不采購商業(yè)公司的收費版本 Hadoop/Spark，價格相當(dāng)可觀，會大幅增加軟件采購成本。既然 Hadoop 如此沉重，為什么還有很多用戶會選擇它呢？答案很簡單：暫時找不到別的選擇，也只有 Hadoop 勉強可用，好歹知名度高一些。如此一來，用戶就只能安裝、配置 Hadoop 的重型應(yīng)用，并忍受 Hadoop 本身對計算資源的大量消耗。小規(guī)模集群的服務(wù)器數(shù)量本來就不多，Hadoop 又浪費了不少，小馬拉大車，最后運行的效果可想而知。花了大價錢采購、費事費力的使用 Hadoop，實際計算的性能卻不理想。就沒有別的選擇了？輕量級的選擇
開源的 esProc SPL 是輕量級大數(shù)據(jù)計算引擎，采用了全新的實現(xiàn)技術(shù)，可以做到技術(shù)輕、使用簡單、成本低。技術(shù)輕本文開頭說過，越來越大的數(shù)據(jù)量讓傳統(tǒng)數(shù)據(jù)庫撐不住，所以用戶只能轉(zhuǎn)向分布式計算技術(shù)。而數(shù)據(jù)庫之所以撐不住，是因為 SQL 難以實現(xiàn)高速算法，大數(shù)據(jù)運算性能只能指望數(shù)據(jù)庫的優(yōu)化引擎，遇到復(fù)雜計算時，優(yōu)化引擎又常常無能為力。所以，我們應(yīng)該想辦法設(shè)計更高效的算法，而不是一味地追求分布式計算。按照這個思路，SPL 提供了眾多高性能算法（有許多是業(yè)界首創(chuàng)）以及高效的存儲方案，同等硬件環(huán)境下可以獲得遠(yuǎn)超過數(shù)據(jù)庫的運算性能。安裝在單機上的 SPL 就可以完成很多大數(shù)據(jù)計算任務(wù)，架構(gòu)比集群簡單很多，從技術(shù)上自然就輕的多了。SPL 的高性能算法有下面這些：對于數(shù)據(jù)量更大的情況，SPL 實現(xiàn)了輕量級集群計算功能。這一功能的設(shè)計目標(biāo)是幾臺到十幾臺節(jié)點的集群，采用了與 Hadoop 完全不同的實現(xiàn)方法。SPL 集群不提供復(fù)雜沉重的自動化管理功能，而是允許對每個節(jié)點進(jìn)行個性化配置。程序員可以根據(jù)數(shù)據(jù)特征和計算目標(biāo)來決定各節(jié)點存儲什么樣的數(shù)據(jù)，完成哪些計算。這樣做，不僅大大降低了架構(gòu)復(fù)雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過產(chǎn)品號字段與較小的產(chǎn)品表主鍵做關(guān)聯(lián)，再按照產(chǎn)品供應(yīng)商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個節(jié)點的硬盤上，再將較小的產(chǎn)品表讀入每個節(jié)點的內(nèi)存中。計算時，每個節(jié)點僅對本機上的訂單分段和產(chǎn)品數(shù)據(jù)做關(guān)聯(lián)、分組匯總，可以縮短總計算時間；再將結(jié)果傳輸?shù)揭粋€節(jié)點上做二次匯總。由于傳輸?shù)氖堑谝淮螀R總的結(jié)果，數(shù)據(jù)量小、網(wǎng)絡(luò)傳輸時間較短。總體來說，這個方案可以獲得最佳性能，雖然程序員需要做一些更細(xì)致的工作，但對于小規(guī)模集群來說，增加的工作量并不大。SPL 也不提供超強的容錯能力，不會像 Hadoop 那樣，在有節(jié)點故障的情況下，還要保證任何一個任務(wù)都會執(zhí)行成功。實際上，大多數(shù)計算任務(wù)的執(zhí)行時間都在幾個小時以內(nèi)，而幾臺、十幾臺機器的集群一般都能做到較長時間正常運行，不會這么頻繁的出故障。即使偶爾出現(xiàn)節(jié)點故障導(dǎo)致任務(wù)執(zhí)行失敗，再重新計算一遍也可以接受，畢竟這種情況不會經(jīng)常發(fā)生。所以，SPL 的容錯能力只是保證有少數(shù)節(jié)點故障的時候，整個集群還能繼續(xù)工作并接受新任務(wù)（包括重算的任務(wù)），這就大大降低了 SPL 集群的復(fù)雜度。在內(nèi)存計算方面，SPL 沒有使用 Spark RDD 的 immutable 機制，而是采用了指針式復(fù)用機制，利用地址（指針）訪問內(nèi)存，在數(shù)據(jù)結(jié)構(gòu)沒有改變的情況下，直接用原數(shù)據(jù)的地址形成結(jié)果集，不必每個計算都將數(shù)據(jù)復(fù)制一遍，僅僅多保存一個地址（指針），可以同時減少 CPU 和內(nèi)存的消耗，運行起來要比 Spark 輕很多了。并且，SPL 改進(jìn)了當(dāng)前的外存計算算法體系，降低了復(fù)雜度并擴大了適應(yīng)范圍，可以做到內(nèi)外存計算結(jié)合，充分提升計算性能的同時，還不像 Spark 那樣依賴大內(nèi)存。使用簡單SPL 采用輕量級技術(shù)，自然更容易安裝、配置和運行維護(hù)。SPL 不僅可以作為獨立服務(wù)器使用，還很容易集成到需要高性能計算的應(yīng)用中，比如即時查詢系統(tǒng)，只要引入幾個 jar 包即可。Hadoop 則很難集成，只能在邊上作為一個數(shù)據(jù)源運行。有些臨時性數(shù)據(jù)需要隨時進(jìn)行處理，則可使用 SPL 的桌面集成開發(fā)環(huán)境可視化地計算，快速得到結(jié)果。如果要安裝部署 Hadoop，那么等環(huán)境搭建好時臨時數(shù)據(jù)任務(wù)已經(jīng)過期了。前面展示的眾多 SPL 高性能算法，也能讓大數(shù)據(jù)計算編程變得簡單。程序員可以在較短時間內(nèi)掌握這些算法函數(shù)，學(xué)習(xí)成本相對較低。而且，使用這些現(xiàn)成的函數(shù)很容易實現(xiàn)各種復(fù)雜的計算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。比如，以電商網(wǎng)站常見的漏斗分析為例，用 SQL 實現(xiàn)三步漏斗的代碼大致如下：
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 寫出來要三十多行，理解起來有相當(dāng)?shù)碾y度。如果用 MapReduce/Scala 來寫，會更加困難。即使是用 SQL 實現(xiàn)，寫出來的這段代碼和漏斗的步驟數(shù)量相關(guān)，每增加一步就要再增加一段子查詢。相比之下，SPL 就簡單得多，處理任意步驟數(shù)都是下面這樣簡潔的代碼：| 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 個節(jié)點上，小產(chǎn)品表則加載到每個節(jié)點的內(nèi)存中，兩表關(guān)聯(lián)之后要按照產(chǎn)品供應(yīng)商分組匯總訂單金額。用 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)) |
|
這段代碼執(zhí)行時，任務(wù)管理（內(nèi)存加載、任務(wù)拆分、合并等）所需要的計算資源，遠(yuǎn)遠(yuǎn)小于關(guān)聯(lián)和分組匯總計算的消耗。如此輕便的任務(wù)管理功能，可以在任意節(jié)點、甚至是集成開發(fā)環(huán)境 IDE 上執(zhí)行。
成本低與 Hadoop 相同，SPL 也是開源軟件，不同的是 SPL 不僅軟件免費，綜合成本也非常低。SPL 安裝、配置、運維很容易，可以大大降低支持人員的人力資源成本。同時，由于 SPL 降低了大數(shù)據(jù)計算編程的難度，程序員很容易實現(xiàn)各種復(fù)雜的計算，開發(fā)效率顯著提高，也就節(jié)省了程序員的人力資源成本。而且，由于 SPL 技術(shù)體系非常輕，平臺自身占用的 CPU、內(nèi)存和硬盤很少，可以讓更多的資源用于業(yè)務(wù)計算，能大幅提高硬件利用率。SPL 也不像 Spark 那樣依賴大內(nèi)存，總體來說，大大減少了硬件采購成本。SPL 既輕且快
SPL 技術(shù)輕、自身消耗小，而且還提供了眾多高性能算法，所以，在幾個到幾十個節(jié)點的集群，甚至單機的情況下，比 Hadoop/Spark 有更好的性能表現(xiàn)。案例 1：某電商漏斗分析計算。Spark：6 節(jié)點，每節(jié)點 4CPU 核，平均計算時間：25 秒。SPL：單機，8 線程計算，平均計算時間可達(dá) 10 秒。代碼量僅有 Spark Scala 的一半。案例 2：某大型銀行用戶畫像分析。Hadoop 上某 OLAP 服務(wù)器：虛擬機 100CPU 核，計算時間：120 秒。SPL：虛擬機 12CPU 核，計算時間：僅 4 秒。性能提高 250 倍。 案例 3：某商業(yè)銀行的手機銀行 APP，活期明細(xì)查詢，數(shù)據(jù)量大且高并發(fā)。基于 Hadoop 的某商用數(shù)據(jù)倉庫：高并發(fā)時無法達(dá)到秒級的響應(yīng)速度，只好換用 6 臺 ES 集群。SPL 單機：達(dá)到 6 臺 ES 集群同樣的并發(fā)和響應(yīng)能力。總結(jié)來說，Hadoop/Spark 是源自頭部互聯(lián)網(wǎng)企業(yè)的重型解決方案，適合需要有超大規(guī)模集群的巨大企業(yè)。很多場景的數(shù)據(jù)雖然也不少，但小集群甚至無集群就足夠處理，遠(yuǎn)沒多到這些巨大企業(yè)的規(guī)模，也沒有那么多的硬件設(shè)備和維護(hù)人員。這種情況下，輕量級的大數(shù)據(jù)計算引擎 SPL 是首選，投入很低的成本，就可以做到技術(shù)輕、使用簡便，而且還能提高開發(fā)效率、達(dá)到更高的性能。GitHub：https://github.com/SPLWare/esProc
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報投訴
-
cpu
+關(guān)注
關(guān)注
68文章
11011瀏覽量
215196 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
3884瀏覽量
65579 -
大數(shù)據(jù)
+關(guān)注
關(guān)注
64文章
8941瀏覽量
139126
原文標(biāo)題：國產(chǎn)數(shù)據(jù)庫，計算性能太強了！
文章出處：【微信號：芋道源碼，微信公眾號：芋道源碼】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
數(shù)據(jù)庫廠商都怕低價競爭？阿里云說并不可懼
，我們來看看云原生數(shù)據(jù)庫由內(nèi)而外有哪些具體的與眾不同?經(jīng)過優(yōu)化的計算和存儲引擎使得POLARDB讀性能可達(dá)百萬QPS，寫性能超過13萬QPS;采用計
發(fā)表于 05-11 11:02
最新國產(chǎn)數(shù)據(jù)庫排名
最新國產(chǎn)數(shù)據(jù)庫排名，本篇文章約14000字，包含如下5部分內(nèi)容：1.開篇2.國產(chǎn)數(shù)據(jù)庫產(chǎn)品清單，包括產(chǎn)品名稱，產(chǎn)品類別及廠商名稱；3.國產(chǎn)
發(fā)表于 07-28 08:06
數(shù)據(jù)庫性能評測指標(biāo)及其測試方法
近些年來，國產(chǎn)數(shù)據(jù)庫得到了快速的發(fā)展，但是針對其性能的測試方法和測試指標(biāo)卻參差不齊。針對上述問題，中國軟件評測中心在大量數(shù)據(jù)庫測試的基礎(chǔ)之上，參考國際
發(fā)表于 03-17 15:22
?79次下載
提高Oracle的數(shù)據(jù)庫性能
在Oracle數(shù)據(jù)庫設(shè)計中長期受到設(shè)計人員重視的是如何更好更快地提高Oracle數(shù)據(jù)庫性能的問題。其中對數(shù)據(jù)庫表現(xiàn)有較大關(guān)聯(lián)的是兩個因素，一是執(zhí)行SQL語句的速度問題；二是
發(fā)表于 11-11 18:16
?4次下載
分布式數(shù)據(jù)庫聚合計算性能優(yōu)化
針對分布式數(shù)據(jù)庫在分析應(yīng)用方面的聚合計算性能較低的問題，以MongoDB數(shù)據(jù)庫為研究實例，提出了一種基于片鍵和索引的數(shù)據(jù)庫
發(fā)表于 12-03 11:01
?0次下載
數(shù)據(jù)庫教程之如何進(jìn)行數(shù)據(jù)庫設(shè)計
本文檔的主要內(nèi)容詳細(xì)介紹的是數(shù)據(jù)庫教程之如何進(jìn)行數(shù)據(jù)庫設(shè)計內(nèi)容包括了：1 數(shù)據(jù)庫設(shè)計概述 ，2 數(shù)據(jù)庫需求分析 ，3 數(shù)據(jù)庫結(jié)構(gòu)設(shè)計 ，4
發(fā)表于 10-19 10:41
?21次下載
Serverless 解惑—函數(shù)計算如何訪問 MySQL 數(shù)據(jù)庫
任務(wù)，并提供日志查詢、性能監(jiān)控和報警等功能。借助函數(shù)計算，您可以快速構(gòu)建任何類型的應(yīng)用和服務(wù)，并且只需為任務(wù)實際消耗的資源付費。 訪問 MySQL 數(shù)據(jù)庫是指在函數(shù)計算中通過編寫代碼調(diào)
發(fā)表于 03-09 16:52
?793次閱讀
國產(chǎn)數(shù)據(jù)庫真的迎來轉(zhuǎn)折點了嗎？
下一步，永遠(yuǎn)比這一步更難。 數(shù)據(jù)庫與操作系統(tǒng)、中間件是計算機基礎(chǔ)的三大軟件。 “缺芯少魂”之痛常讓人為國產(chǎn)操作系統(tǒng)的不足捏一把汗，而數(shù)據(jù)庫卻更像藏在水面之下的冰山，甚少有人關(guān)注。現(xiàn)在，
華為云數(shù)據(jù)庫\-GaussDB for MySQL數(shù)據(jù)庫
華為云更可靠，技術(shù)強、創(chuàng)新快、資源多的特點。華為云采用了最新的DFV分布式存儲技術(shù)，架構(gòu)方面使用了計算存儲分離架構(gòu)，存儲還最高支持128TB的海量存儲，可以實現(xiàn)超百萬級QPS吞吐，還支持跨AZ部署，故障秒級切換，既擁有商業(yè)數(shù)據(jù)庫的性能
國產(chǎn)自研數(shù)據(jù)庫是更新?lián)Q代首選
了極為重要的轉(zhuǎn)型升級。特別是在自主創(chuàng)新的時代背景下，國產(chǎn)數(shù)據(jù)庫的快速崛起更是令人側(cè)目。那么作為國產(chǎn)數(shù)據(jù)庫的代表之一，華為云數(shù)據(jù)庫對此有著怎樣
數(shù)據(jù)庫建立|數(shù)據(jù)庫創(chuàng)建的方法？
數(shù)據(jù)庫是一個存儲關(guān)鍵數(shù)據(jù)的文件系統(tǒng)。利用數(shù)據(jù)庫管理系統(tǒng)建立每個人的數(shù)據(jù)庫可以更好地提供安全。 數(shù)據(jù)庫建立|
python讀取數(shù)據(jù)庫數(shù)據(jù) python查詢數(shù)據(jù)庫 python數(shù)據(jù)庫連接
python讀取數(shù)據(jù)庫數(shù)據(jù) python查詢數(shù)據(jù)庫 python數(shù)據(jù)庫連接 Python是一門高級編程語言，廣泛應(yīng)用于各種領(lǐng)域。其中，Python在
數(shù)據(jù)庫應(yīng)用及其特點 數(shù)據(jù)庫數(shù)據(jù)的基本特點
數(shù)據(jù)庫應(yīng)用及其特點 數(shù)據(jù)庫數(shù)據(jù)的基本特點? 數(shù)據(jù)庫應(yīng)用及其特點 隨著計算機技術(shù)的不斷發(fā)展和普及，數(shù)據(jù)
星火夜話，論道國產(chǎn)數(shù)據(jù)庫
”活動，希望能夠傳承薩師煊先生研究中國數(shù)據(jù)庫之初心，共話國產(chǎn)數(shù)據(jù)庫技術(shù)創(chuàng)新，共釋填補福建省基礎(chǔ)軟件領(lǐng)域空白的技術(shù)路線，共謀福建省信創(chuàng)新質(zhì)生產(chǎn)力發(fā)展之道，照亮我國數(shù)據(jù)庫技術(shù)、產(chǎn)業(yè)傳承奮進(jìn)
云數(shù)據(jù)庫是哪種數(shù)據(jù)庫類型？
云數(shù)據(jù)庫是一種部署在虛擬計算環(huán)境中的數(shù)據(jù)庫，它融合了云計算的彈性和可擴展性，為用戶提供高效、靈活的數(shù)據(jù)庫服務(wù)。云
工商網(wǎng)監(jiān)
評論