我欲封天耳根小说,小说改编的网页游戏,欢乐颂小说在线阅读

隨著大數(shù)據(jù)時(shí)代的來臨，數(shù)據(jù)量不斷增長，傳統(tǒng)小機(jī)上跑數(shù)據(jù)庫的模式擴(kuò)容困難且成本高昂，難以支撐業(yè)務(wù)發(fā)展。很多用戶開始轉(zhuǎn)向分布式計(jì)算路線，用多臺廉價(jià)的 PC 服務(wù)器組成集群來完成大數(shù)據(jù)計(jì)算任務(wù)。Hadoop/Spark 就是其中重要的軟件技術(shù)，由于開源免費(fèi)而廣受歡迎。經(jīng)過多年的應(yīng)用和發(fā)展，Hadoop 已經(jīng)被廣泛接受，不僅直接應(yīng)用于數(shù)據(jù)計(jì)算，還發(fā)展出很多基于它的新數(shù)據(jù)庫，比如 Hive、Impala 等。

Hadoop/Spark 之重

Hadoop 的設(shè)計(jì)目標(biāo)是成百上千臺節(jié)點(diǎn)的集群，為此，開發(fā)者實(shí)現(xiàn)了很多復(fù)雜、沉重的功能模塊。但是，除了一些互聯(lián)網(wǎng)巨頭企業(yè)、國家級通信運(yùn)營商和大型銀行外，大多數(shù)場景的數(shù)據(jù)量并沒有那么巨大。結(jié)果，經(jīng)常能看到只有幾個(gè)到十幾個(gè)節(jié)點(diǎn)的 Hadoop 集群。由于目標(biāo)和現(xiàn)實(shí)的錯(cuò)位，對很多用戶來講，Hadoop 成了一個(gè)在技術(shù)、應(yīng)用和成本上都很沉重的產(chǎn)品。技術(shù)之重如果真的有幾千臺計(jì)算機(jī)組成的集群，是不可能依靠手工個(gè)性化管理的。試想，將這些計(jì)算機(jī)羅列出來，運(yùn)維人員看都看不過來，更別說管理和分配任務(wù)了。再說，這么多機(jī)器，難免會(huì)不斷出現(xiàn)各種故障，怎么保證計(jì)算任務(wù)順利執(zhí)行？Hadoop/Spark 的開發(fā)者為了解決這些問題，編寫了大量代碼，用于實(shí)現(xiàn)自動(dòng)化節(jié)點(diǎn)管理、任務(wù)分配和強(qiáng)容錯(cuò)功能。但是，這些功能本身就要占用很多計(jì)算資源（CPU、內(nèi)存和硬盤等），如果用到幾臺到十幾臺節(jié)點(diǎn)的集群上，就太過沉重了。集群本來就不大，Hadoop 還要占用相當(dāng)一部分的資源，非常不劃算。不僅如此，Hadoop 產(chǎn)品線很長，要把這些模塊都放在一個(gè)平臺上運(yùn)行，還要梳理好各個(gè)產(chǎn)品之間的相互依賴性，就不得不實(shí)現(xiàn)一個(gè)包羅萬象的復(fù)雜架構(gòu)。雖然大多數(shù)場景只用其中一兩個(gè)產(chǎn)品，也必須接受這個(gè)復(fù)雜、沉重的平臺。后來出現(xiàn)的 Spark 彌補(bǔ)了 Hadoop 對內(nèi)存利用的不足，技術(shù)上是不是可以變輕呢？很遺憾，Spark 走向了另一個(gè)極端，從理論模型上就只考慮內(nèi)存計(jì)算了。特別是 Spark 中的 RDD 采用了 immutable 機(jī)制，在每個(gè)計(jì)算步驟后都會(huì)復(fù)制出新的 RDD，造成內(nèi)存和 CPU 的大量占用和浪費(fèi)，離開大內(nèi)存甚至無法運(yùn)行，所以技術(shù)上還是很重。使用之重Hadoop 技術(shù)上太過復(fù)雜，也就意味著安裝和運(yùn)維會(huì)很麻煩。集群只有幾臺計(jì)算機(jī)時(shí)，卻不得不使用為幾千臺節(jié)點(diǎn)集群設(shè)計(jì)的節(jié)點(diǎn)管理、任務(wù)分配和容錯(cuò)功能。可想而知，安裝、配置、調(diào)試都很困難，日常運(yùn)行的維護(hù)、管理工作也不容易。即使克服這些困難讓 Hadoop 運(yùn)行起來了，編寫大數(shù)據(jù)計(jì)算代碼時(shí)還會(huì)面臨更大的麻煩。Hadoop 編程的核心框架是 MapReduce，程序員要編寫并行程序，只要寫 Map 和 Reduce 動(dòng)作即可，用來解決求和、計(jì)數(shù)等簡單問題也確實(shí)有效。但是，遇到復(fù)雜一些的業(yè)務(wù)邏輯，用 MapReduce 編程就會(huì)變得非常困難。例如，業(yè)務(wù)計(jì)算中很常見的 JOIN 計(jì)算，就很難用 MapReduce 實(shí)現(xiàn)。再比如，很多和次序有關(guān)的運(yùn)算實(shí)現(xiàn)起來也很困難。Spark 的 Scala 語言具備一定的結(jié)構(gòu)化數(shù)據(jù)計(jì)算能力，是不是能簡單一些呢？很可惜，Scala 使用難度很大，難學(xué)更難精。遇到復(fù)雜一些的運(yùn)算邏輯，Scala 也很難寫出來。MapReduce、Scala 都這么難，所以 Hadoop/Spark 計(jì)算語法開始回歸 SQL 語言。Hive 可以將 SQL 轉(zhuǎn)化為 MapReduce 所以很受歡迎，Spark SQL 的應(yīng)用也比 Scala 廣泛的多。但是，用 SQL 做一些常規(guī)查詢還算簡單，用于處理多步驟過程計(jì)算或次序相關(guān)運(yùn)算還是非常麻煩，要寫很復(fù)雜的 UDF。而且，許多計(jì)算場景雖然勉強(qiáng)能用 SQL 實(shí)現(xiàn)，但是計(jì)算速度卻很不理想，也很難進(jìn)行性能調(diào)優(yōu)。成本之重雖然 Hadoop 軟件本身開源免費(fèi)，但它技術(shù)復(fù)雜、使用困難，會(huì)帶來高昂的綜合成本。前面說過，Hadoop 自身會(huì)占用過多的 CPU、內(nèi)存和硬盤，而 Spark 需要大內(nèi)存支撐才能正常運(yùn)行。所以不得不為 Hadoop/Spark 采購更高配置的服務(wù)器，要增加硬件支出。Hadoop/Spark 使用困難，就需要投入更多的人力去完成安裝、運(yùn)維，保證 Hadoop/Spark 的正常運(yùn)轉(zhuǎn)；還要投入更多的開發(fā)人員，編程實(shí)現(xiàn)各種復(fù)雜的業(yè)務(wù)計(jì)算，要增加人力資源成本。由于使用過于困難，很多用戶不得不采購商業(yè)公司的收費(fèi)版本 Hadoop/Spark，價(jià)格相當(dāng)可觀，會(huì)大幅增加軟件采購成本。既然 Hadoop 如此沉重，為什么還有很多用戶會(huì)選擇它呢？答案很簡單：暫時(shí)找不到別的選擇，也只有 Hadoop 勉強(qiáng)可用，好歹知名度高一些。如此一來，用戶就只能安裝、配置 Hadoop 的重型應(yīng)用，并忍受 Hadoop 本身對計(jì)算資源的大量消耗。小規(guī)模集群的服務(wù)器數(shù)量本來就不多，Hadoop 又浪費(fèi)了不少，小馬拉大車，最后運(yùn)行的效果可想而知。花了大價(jià)錢采購、費(fèi)事費(fèi)力的使用 Hadoop，實(shí)際計(jì)算的性能卻不理想。就沒有別的選擇了？

輕量級的選擇

開源的 esProc SPL 是輕量級大數(shù)據(jù)計(jì)算引擎，采用了全新的實(shí)現(xiàn)技術(shù)，可以做到技術(shù)輕、使用簡單、成本低。技術(shù)輕本文開頭說過，越來越大的數(shù)據(jù)量讓傳統(tǒng)數(shù)據(jù)庫撐不住，所以用戶只能轉(zhuǎn)向分布式計(jì)算技術(shù)。而數(shù)據(jù)庫之所以撐不住，是因?yàn)?SQL 難以實(shí)現(xiàn)高速算法，大數(shù)據(jù)運(yùn)算性能只能指望數(shù)據(jù)庫的優(yōu)化引擎，遇到復(fù)雜計(jì)算時(shí)，優(yōu)化引擎又常常無能為力。所以，我們應(yīng)該想辦法設(shè)計(jì)更高效的算法，而不是一味地追求分布式計(jì)算。按照這個(gè)思路，SPL 提供了眾多高性能算法（有許多是業(yè)界首創(chuàng)）以及高效的存儲方案，同等硬件環(huán)境下可以獲得遠(yuǎn)超過數(shù)據(jù)庫的運(yùn)算性能。安裝在單機(jī)上的 SPL 就可以完成很多大數(shù)據(jù)計(jì)算任務(wù)，架構(gòu)比集群簡單很多，從技術(shù)上自然就輕的多了。SPL 的高性能算法有下面這些：

對于數(shù)據(jù)量更大的情況，SPL 實(shí)現(xiàn)了輕量級集群計(jì)算功能。這一功能的設(shè)計(jì)目標(biāo)是幾臺到十幾臺節(jié)點(diǎn)的集群，采用了與 Hadoop 完全不同的實(shí)現(xiàn)方法。SPL 集群不提供復(fù)雜沉重的自動(dòng)化管理功能，而是允許對每個(gè)節(jié)點(diǎn)進(jìn)行個(gè)性化配置。程序員可以根據(jù)數(shù)據(jù)特征和計(jì)算目標(biāo)來決定各節(jié)點(diǎn)存儲什么樣的數(shù)據(jù)，完成哪些計(jì)算。這樣做，不僅大大降低了架構(gòu)復(fù)雜度，也是提升性能的重要手段。以訂單分析為例，訂單表很大，要通過產(chǎn)品號字段與較小的產(chǎn)品表主鍵做關(guān)聯(lián)，再按照產(chǎn)品供應(yīng)商分組匯總訂單金額。SPL 集群可以很容易的將訂單表分段存放在各個(gè)節(jié)點(diǎn)的硬盤上，再將較小的產(chǎn)品表讀入每個(gè)節(jié)點(diǎn)的內(nèi)存中。計(jì)算時(shí)，每個(gè)節(jié)點(diǎn)僅對本機(jī)上的訂單分段和產(chǎn)品數(shù)據(jù)做關(guān)聯(lián)、分組匯總，可以縮短總計(jì)算時(shí)間；再將結(jié)果傳輸?shù)揭粋€(gè)節(jié)點(diǎn)上做二次匯總。由于傳輸?shù)氖堑谝淮螀R總的結(jié)果，數(shù)據(jù)量小、網(wǎng)絡(luò)傳輸時(shí)間較短。總體來說，這個(gè)方案可以獲得最佳性能，雖然程序員需要做一些更細(xì)致的工作，但對于小規(guī)模集群來說，增加的工作量并不大。SPL 也不提供超強(qiáng)的容錯(cuò)能力，不會(huì)像 Hadoop 那樣，在有節(jié)點(diǎn)故障的情況下，還要保證任何一個(gè)任務(wù)都會(huì)執(zhí)行成功。實(shí)際上，大多數(shù)計(jì)算任務(wù)的執(zhí)行時(shí)間都在幾個(gè)小時(shí)以內(nèi)，而幾臺、十幾臺機(jī)器的集群一般都能做到較長時(shí)間正常運(yùn)行，不會(huì)這么頻繁的出故障。即使偶爾出現(xiàn)節(jié)點(diǎn)故障導(dǎo)致任務(wù)執(zhí)行失敗，再重新計(jì)算一遍也可以接受，畢竟這種情況不會(huì)經(jīng)常發(fā)生。所以，SPL 的容錯(cuò)能力只是保證有少數(shù)節(jié)點(diǎn)故障的時(shí)候，整個(gè)集群還能繼續(xù)工作并接受新任務(wù)（包括重算的任務(wù)），這就大大降低了 SPL 集群的復(fù)雜度。在內(nèi)存計(jì)算方面，SPL 沒有使用 Spark RDD 的 immutable 機(jī)制，而是采用了指針式復(fù)用機(jī)制，利用地址（指針）訪問內(nèi)存，在數(shù)據(jù)結(jié)構(gòu)沒有改變的情況下，直接用原數(shù)據(jù)的地址形成結(jié)果集，不必每個(gè)計(jì)算都將數(shù)據(jù)復(fù)制一遍，僅僅多保存一個(gè)地址（指針），可以同時(shí)減少 CPU 和內(nèi)存的消耗，運(yùn)行起來要比 Spark 輕很多了。并且，SPL 改進(jìn)了當(dāng)前的外存計(jì)算算法體系，降低了復(fù)雜度并擴(kuò)大了適應(yīng)范圍，可以做到內(nèi)外存計(jì)算結(jié)合，充分提升計(jì)算性能的同時(shí)，還不像 Spark 那樣依賴大內(nèi)存。使用簡單SPL 采用輕量級技術(shù)，自然更容易安裝、配置和運(yùn)行維護(hù)。SPL 不僅可以作為獨(dú)立服務(wù)器使用，還很容易集成到需要高性能計(jì)算的應(yīng)用中，比如即時(shí)查詢系統(tǒng)，只要引入幾個(gè) jar 包即可。Hadoop 則很難集成，只能在邊上作為一個(gè)數(shù)據(jù)源運(yùn)行。有些臨時(shí)性數(shù)據(jù)需要隨時(shí)進(jìn)行處理，則可使用 SPL 的桌面集成開發(fā)環(huán)境可視化地計(jì)算，快速得到結(jié)果。如果要安裝部署 Hadoop，那么等環(huán)境搭建好時(shí)臨時(shí)數(shù)據(jù)任務(wù)已經(jīng)過期了。前面展示的眾多 SPL 高性能算法，也能讓大數(shù)據(jù)計(jì)算編程變得簡單。程序員可以在較短時(shí)間內(nèi)掌握這些算法函數(shù)，學(xué)習(xí)成本相對較低。而且，使用這些現(xiàn)成的函數(shù)很容易實(shí)現(xiàn)各種復(fù)雜的計(jì)算需求，不僅比 MapReduce/Scala 簡單，比 SQL 也簡單很多。比如，以電商網(wǎng)站常見的漏斗分析為例，用 SQL 實(shí)現(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 來寫，會(huì)更加困難。即使是用 SQL 實(shí)現(xiàn)，寫出來的這段代碼和漏斗的步驟數(shù)量相關(guān)，每增加一步就要再增加一段子查詢。相比之下，SPL 就簡單得多，處理任意步驟數(shù)都是下面這樣簡潔的代碼：

	A	B
1	=["etype1","etype2","etype3"]	=file("event.ctx").open()
2	=B1.curs or(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 集群計(jì)算的代碼也非常簡單，比如前面提到的訂單分析計(jì)算，具體要求是：大訂單表分段存儲在 4 個(gè)節(jié)點(diǎn)上，小產(chǎn)品表則加載到每個(gè)節(jié)點(diǎn)的內(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í)行時(shí)，任務(wù)管理（內(nèi)存加載、任務(wù)拆分、合并等）所需要的計(jì)算資源，遠(yuǎn)遠(yuǎn)小于關(guān)聯(lián)和分組匯總計(jì)算的消耗。如此輕便的任務(wù)管理功能，可以在任意節(jié)點(diǎn)、甚至是集成開發(fā)環(huán)境 IDE 上執(zhí)行。

成本低與 Hadoop 相同，SPL 也是開源軟件，不同的是 SPL 不僅軟件免費(fèi)，綜合成本也非常低。SPL 安裝、配置、運(yùn)維很容易，可以大大降低支持人員的人力資源成本。同時(shí)，由于 SPL 降低了大數(shù)據(jù)計(jì)算編程的難度，程序員很容易實(shí)現(xiàn)各種復(fù)雜的計(jì)算，開發(fā)效率顯著提高，也就節(jié)省了程序員的人力資源成本。而且，由于 SPL 技術(shù)體系非常輕，平臺自身占用的 CPU、內(nèi)存和硬盤很少，可以讓更多的資源用于業(yè)務(wù)計(jì)算，能大幅提高硬件利用率。SPL 也不像 Spark 那樣依賴大內(nèi)存，總體來說，大大減少了硬件采購成本。

SPL 既輕且快

SPL 技術(shù)輕、自身消耗小，而且還提供了眾多高性能算法，所以，在幾個(gè)到幾十個(gè)節(jié)點(diǎn)的集群，甚至單機(jī)的情況下，比 Hadoop/Spark 有更好的性能表現(xiàn)。案例 1：某電商漏斗分析計(jì)算。Spark：6 節(jié)點(diǎn)，每節(jié)點(diǎn) 4CPU 核，平均計(jì)算時(shí)間：25 秒。SPL：單機(jī)，8 線程計(jì)算，平均計(jì)算時(shí)間可達(dá) 10 秒。代碼量僅有 Spark Scala 的一半。案例 2：某大型銀行用戶畫像分析。Hadoop 上某 OLAP 服務(wù)器：虛擬機(jī) 100CPU 核，計(jì)算時(shí)間：120 秒。SPL：虛擬機(jī) 12CPU 核，計(jì)算時(shí)間：僅 4 秒。性能提高 250 倍。 案例 3：某商業(yè)銀行的手機(jī)銀行 APP，活期明細(xì)查詢，數(shù)據(jù)量大且高并發(fā)。基于 Hadoop 的某商用數(shù)據(jù)倉庫：高并發(fā)時(shí)無法達(dá)到秒級的響應(yīng)速度，只好換用 6 臺 ES 集群。SPL 單機(jī)：達(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ù)計(jì)算引擎 SPL 是首選，投入很低的成本，就可以做到技術(shù)輕、使用簡便，而且還能提高開發(fā)效率、達(dá)到更高的性能。GitHub：https://github.com/SPLWare/esProc

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。舉報(bào)投訴

cpu

cpu

+關(guān)注

關(guān)注
68

文章
10905

瀏覽量
213034
數(shù)據(jù)庫

數(shù)據(jù)庫

+關(guān)注

關(guān)注
7

文章
3848

瀏覽量
64691
大數(shù)據(jù)

大數(shù)據(jù)

+關(guān)注

關(guān)注
64

文章
8908

瀏覽量
137801

原文標(biāo)題：國產(chǎn)數(shù)據(jù)庫，計(jì)算性能太強(qiáng)了！

文章出處：【微信號：芋道源碼，微信公眾號：芋道源碼】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

數(shù)據(jù)庫廠商都怕低價(jià)競爭？阿里云說并不可懼

，我們來看看云原生數(shù)據(jù)庫由內(nèi)而外有哪些具體的與眾不同?經(jīng)過優(yōu)化的計(jì)算和存儲引擎使得POLARDB讀性能可達(dá)百萬QPS，寫性能超過13萬QPS;采用計(jì)

發(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è)計(jì)中長期受到設(shè)計(jì)人員重視的是如何更好更快地提高Oracle數(shù)據(jù)庫性能的問題。其中對數(shù)據(jù)庫表現(xiàn)有較大關(guān)聯(lián)的是兩個(gè)因素，一是執(zhí)行SQL語句的速度問題；二是

發(fā)表于 11-11 18:16 ?4次下載

分布式數(shù)據(jù)庫聚合計(jì)算性能優(yōu)化

針對分布式數(shù)據(jù)庫在分析應(yīng)用方面的聚合計(jì)算性能較低的問題，以MongoDB數(shù)據(jù)庫為研究實(shí)例，提出了一種基于片鍵和索引的數(shù)據(jù)庫

發(fā)表于 12-03 11:01 ?0次下載

數(shù)據(jù)庫教程之如何進(jìn)行數(shù)據(jù)庫設(shè)計(jì)

本文檔的主要內(nèi)容詳細(xì)介紹的是數(shù)據(jù)庫教程之如何進(jìn)行數(shù)據(jù)庫設(shè)計(jì)內(nèi)容包括了：1 數(shù)據(jù)庫設(shè)計(jì)概述，2 數(shù)據(jù)庫需求分析，3 數(shù)據(jù)庫結(jié)構(gòu)設(shè)計(jì) ，4

發(fā)表于 10-19 10:41 ?21次下載

Serverless 解惑—函數(shù)計(jì)算如何訪問 MySQL 數(shù)據(jù)庫

任務(wù)，并提供日志查詢、性能監(jiān)控和報(bào)警等功能。借助函數(shù)計(jì)算，您可以快速構(gòu)建任何類型的應(yīng)用和服務(wù)，并且只需為任務(wù)實(shí)際消耗的資源付費(fèi)。訪問 MySQL 數(shù)據(jù)庫是指在函數(shù)計(jì)算中通過編寫代碼調(diào)

發(fā)表于 03-09 16:52 ?743次閱讀

國產(chǎn)數(shù)據(jù)庫真的迎來轉(zhuǎn)折點(diǎn)了嗎？

下一步，永遠(yuǎn)比這一步更難。 數(shù)據(jù)庫與操作系統(tǒng)、中間件是計(jì)算機(jī)基礎(chǔ)的三大軟件。 “缺芯少魂”之痛常讓人為國產(chǎn)操作系統(tǒng)的不足捏一把汗，而數(shù)據(jù)庫卻更像藏在水面之下的冰山，甚少有人關(guān)注。現(xiàn)在，

發(fā)表于 03-03 16:50 ?4208次閱讀

華為云數(shù)據(jù)庫\-GaussDB for MySQL數(shù)據(jù)庫

華為云更可靠，技術(shù)強(qiáng)、創(chuàng)新快、資源多的特點(diǎn)。華為云采用了最新的DFV分布式存儲技術(shù)，架構(gòu)方面使用了計(jì)算存儲分離架構(gòu)，存儲還最高支持128TB的海量存儲，可以實(shí)現(xiàn)超百萬級QPS吞吐，還支持跨AZ部署，故障秒級切換，既擁有商業(yè)數(shù)據(jù)庫的性能

發(fā)表于 10-27 14:56 ?1307次閱讀

國產(chǎn)自研數(shù)據(jù)庫是更新?lián)Q代首選

了極為重要的轉(zhuǎn)型升級。特別是在自主創(chuàng)新的時(shí)代背景下，國產(chǎn)數(shù)據(jù)庫的快速崛起更是令人側(cè)目。那么作為國產(chǎn)數(shù)據(jù)庫的代表之一，華為云數(shù)據(jù)庫對此有著怎樣

發(fā)表于 06-05 10:31 ?926次閱讀

數(shù)據(jù)庫建立|數(shù)據(jù)庫創(chuàng)建的方法？

數(shù)據(jù)庫是一個(gè)存儲關(guān)鍵數(shù)據(jù)的文件系統(tǒng)。利用數(shù)據(jù)庫管理系統(tǒng)建立每個(gè)人的數(shù)據(jù)庫可以更好地提供安全。 數(shù)據(jù)庫建立|

發(fā)表于 07-14 11:15 ?1325次閱讀

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在

發(fā)表于 08-28 17:09 ?1905次閱讀

數(shù)據(jù)庫應(yīng)用及其特點(diǎn) 數(shù)據(jù)庫數(shù)據(jù)的基本特點(diǎn)

數(shù)據(jù)庫應(yīng)用及其特點(diǎn) 數(shù)據(jù)庫數(shù)據(jù)的基本特點(diǎn)? 數(shù)據(jù)庫應(yīng)用及其特點(diǎn) 隨著計(jì)算機(jī)技術(shù)的不斷發(fā)展和普及，數(shù)據(jù)

發(fā)表于 08-28 17:22 ?2942次閱讀

星火夜話，論道國產(chǎn)數(shù)據(jù)庫

”活動(dòng)，希望能夠傳承薩師煊先生研究中國數(shù)據(jù)庫之初心，共話國產(chǎn)數(shù)據(jù)庫技術(shù)創(chuàng)新，共釋填補(bǔ)福建省基礎(chǔ)軟件領(lǐng)域空白的技術(shù)路線，共謀福建省信創(chuàng)新質(zhì)生產(chǎn)力發(fā)展之道，照亮我國數(shù)據(jù)庫技術(shù)、產(chǎn)業(yè)傳承奮進(jìn)

發(fā)表于 12-28 14:01 ?511次閱讀

云數(shù)據(jù)庫是哪種數(shù)據(jù)庫類型？

云數(shù)據(jù)庫是一種部署在虛擬計(jì)算環(huán)境中的數(shù)據(jù)庫，它融合了云計(jì)算的彈性和可擴(kuò)展性，為用戶提供高效、靈活的數(shù)據(jù)庫服務(wù)。云

發(fā)表于 01-07 10:22 ?143次閱讀