建站
咨詢
售后
建站咨詢
新聞中心
臨近年底，這也是我今年的最后幾篇文章之一了。今年冬天特別冷，穿啥衣服都不覺得暖和。翻了一陣子發(fā)現(xiàn)數(shù)據(jù)庫廠商送的衣服大多比較厚實(shí)，適合這個(gè)寒冬穿。于是最近經(jīng)常穿著各種數(shù)據(jù)庫的衣服上班下班。前些天穿了一件IvorySQL的衣服坐飛機(jī)，空姐看了我半天后問我：“這件始祖鳥的衣服好像沒見過別人穿過”。我笑著說：“這是高端品牌，一般人買不著”。上周一個(gè)朋友約我小聚，脫掉外套后發(fā)現(xiàn)倆人都穿了一件同款的PingCap藍(lán)色厚T恤?？礃幼硬恢刮乙粋€(gè)人發(fā)現(xiàn)了國(guó)產(chǎn)數(shù)據(jù)庫的這個(gè)好處。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比北川羌族網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式北川羌族網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋北川羌族地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴。
今天聊聊自研數(shù)據(jù)庫的難點(diǎn)，在看到這個(gè)問題的時(shí)候肯定有些朋友會(huì)問：“為什么我們需要大型數(shù)據(jù)庫，把自己的數(shù)據(jù)庫拆小不就解決問題了嗎？”，我也經(jīng)常會(huì)聽到：“為什么非要這樣，為什么不那樣”。每個(gè)企業(yè)的實(shí)際情況不同，其需求是不同的，作為一個(gè)用戶你說不需要某個(gè)功能是完全沒毛病的，不過作為數(shù)據(jù)庫廠商，需要為各種各樣的應(yīng)用場(chǎng)景提供解決方案。
進(jìn)入正題，對(duì)于這個(gè)問題大家的觀點(diǎn)可能比較一致，不管采用哪種方式，自研確實(shí)很難，因?yàn)殛P(guān)系型數(shù)據(jù)庫發(fā)展這么多年，很成功的大型商用集中式通用數(shù)據(jù)庫就那么幾個(gè)，最成功的不外乎Oracle、SQL SERVER、DB2這三巨頭。連曾經(jīng)風(fēng)光無限的SYBASE、 INFORMIX在大浪淘沙中都已經(jīng)變成路人甲了。
這些年國(guó)產(chǎn)數(shù)據(jù)庫替代的需求很旺盛，以中國(guó)如此大的數(shù)據(jù)庫市場(chǎng)，能不能培養(yǎng)出一個(gè)像Oracle一樣的數(shù)據(jù)庫產(chǎn)品呢？我想應(yīng)該能，不過從零開始從頭研發(fā)似乎難度有點(diǎn)大，比如說一個(gè)類似Oracle的數(shù)據(jù)庫，其核心代碼一般來說要超過1000萬行，就按1200萬行計(jì)算吧。按照一個(gè)人月2000行核心代碼計(jì)算（這個(gè)代碼量不是全流程代碼量，數(shù)據(jù)庫核心研發(fā)全流程評(píng)估代碼量不會(huì)超過1000行/人月），那么一人年的代碼量是2.4萬，那么需要500人年。
按照最理想的狀態(tài)，我們能招到100個(gè)高水平的核心代碼研發(fā)工程師，從0開始最樂觀需要5年時(shí)間才能拿出一個(gè)初級(jí)產(chǎn)品，再花上兩三年在實(shí)際用戶那里去磨合提升，才能初步成型。按照數(shù)據(jù)庫核心代碼研發(fā)人員100萬的平均年薪（這個(gè)是比較低的，國(guó)外的數(shù)據(jù)庫核心代碼研發(fā)人員年薪要在30萬美金以上），需要投入的研發(fā)經(jīng)費(fèi)是5億。在市場(chǎng)不明朗的情況下，每年投入一億，砸5年才能上市。這種買賣除非是航天軍工這種舉國(guó)體制下，恐怕很少會(huì)有企業(yè)能如此投入。如果再算上周邊工具與接口需要投入的數(shù)倍研發(fā)人員，以及三五百人起步的銷售人員，數(shù)百人的營(yíng)銷市場(chǎng)人員與管理人員，一家成功的數(shù)據(jù)庫企業(yè)每年要投入的資金至少也要幾個(gè)小目標(biāo)。而目前又有幾家企業(yè)每年能真正賣出幾個(gè)億的數(shù)據(jù)庫許可證與服務(wù)呢？
基于此我一般不太敢相信中國(guó)真的存在很多這樣的完全自研的數(shù)據(jù)庫企業(yè)和產(chǎn)品。算一算賬我們大體上也知道數(shù)據(jù)庫廠商動(dòng)不動(dòng)就說我們核心研發(fā)幾百人上千人是件多么不靠譜的事情，大部分國(guó)產(chǎn)數(shù)據(jù)庫廠商的年收入都不足1個(gè)小目標(biāo)，如何能長(zhǎng)期支撐如此燒錢的核心研發(fā)團(tuán)隊(duì)？我所了解的很多數(shù)據(jù)庫廠商的核心研發(fā)人員不過二三十人而已，甚至一些小企業(yè)只是一個(gè)個(gè)位數(shù)。
既然現(xiàn)在從零開始干不大現(xiàn)實(shí)，那么基于開源代碼是否簡(jiǎn)單一些呢？確實(shí)這是難度較低的做法，也是目前大多數(shù)國(guó)產(chǎn)數(shù)據(jù)庫廠商采用的方案?；陂_源代碼可選的是MySQL或者Postgresql，MySQL雖然很強(qiáng)大，長(zhǎng)期霸占數(shù)據(jù)庫流行榜的TOP 2，但是MySQL的核心代碼不足以支撐它成為一個(gè)大型的集中式數(shù)據(jù)庫，其GPL開源協(xié)議也不支撐在它的基礎(chǔ)上大幅度修改代碼，并做成開源的商用數(shù)據(jù)庫。
因此PG變成了唯一的選擇了。可惜的是，PG在整體架構(gòu)，核心代碼以及一些核心算法上也不具備直接成為Oracle這樣的大型通關(guān)系型數(shù)據(jù)庫的潛質(zhì)。astore存儲(chǔ)引擎、XID64、FULL PAGE WRITE、DOUBLE BUFFER、不太完善的checkpoint設(shè)計(jì)、低效率的lwlock代碼、由于缺乏pmon/smon導(dǎo)致的kill -9災(zāi)難、優(yōu)化器能力不足、缺乏高并發(fā)與增量備份能力、沒有類似ORACLE RAC的高可用方案等因素都阻礙了PG作為一個(gè)大型關(guān)鍵數(shù)據(jù)庫的基礎(chǔ)平臺(tái)。 要想達(dá)成我提的目標(biāo)，必須對(duì)PG的核心代碼做大手術(shù)才行。
要對(duì)PG動(dòng)大手術(shù)，依然需要大量高水平的數(shù)據(jù)庫核心開發(fā)人員參與，這也不是一般企業(yè)能玩得起的。所以說目前國(guó)產(chǎn)數(shù)據(jù)庫雖然有200多家了，不過大多數(shù)企業(yè)都選擇去搞分布式數(shù)據(jù)庫，而不去碰大型集中式數(shù)據(jù)庫這個(gè)燙山芋。這是因?yàn)閿?shù)據(jù)庫核心研發(fā)的難度太大了，分布式數(shù)據(jù)庫可以把有限的研發(fā)放到分布式集群上，從而避免更加花錢的對(duì)數(shù)據(jù)庫核心的深度優(yōu)化所需要的投入。
花大力氣去研發(fā)數(shù)據(jù)庫核心不僅僅是技術(shù)上有難度，甚至有些時(shí)候有錢都不一定能干好，因?yàn)榭赡苷也坏阶銐虻母咚降难邪l(fā)人員。在沒有占有足夠大的市場(chǎng)的情況下，不敢投入巨資去做研發(fā)。產(chǎn)品水平不夠又無法吸引足夠多的用戶。這個(gè)先有雞還是先有蛋的問題是目前困擾國(guó)產(chǎn)數(shù)據(jù)庫發(fā)展的最大障礙。
雖然說研發(fā)一個(gè)大型集中式數(shù)據(jù)庫很難，但是中國(guó)自主可控的市場(chǎng)又必須有這么個(gè)產(chǎn)品，中國(guó)的數(shù)據(jù)庫市場(chǎng)規(guī)模也支撐得了這么一個(gè)產(chǎn)品，因此我還是對(duì)中國(guó)能夠出現(xiàn)這么一個(gè)產(chǎn)品持有樂觀態(tài)度的。只不過在目前千軍萬馬爭(zhēng)奪這個(gè)制高點(diǎn)的情況下，絕大多數(shù)企業(yè)會(huì)在這場(chǎng)長(zhǎng)跑中落敗，只有少數(shù)企業(yè)最后會(huì)在競(jìng)爭(zhēng)中活下來，就像30年前國(guó)外商用數(shù)據(jù)庫市場(chǎng)的那場(chǎng)大戰(zhàn)一樣。
當(dāng)前名稱：基于開源代碼開發(fā)一個(gè)大型集中式通用關(guān)系型數(shù)據(jù)庫很難嗎？
文章出自：http://m.fisionsoft.com.cn/article/dhgioos.html
