臨近年底，這也是我今年的最后幾篇文章之一了。今年冬天特別冷，穿啥衣服都不覺得暖和。翻了一陣子發(fā)現(xiàn)數(shù)據(jù)庫廠商送的衣服大多比較厚實，適合這個寒冬穿。于是最近經(jīng)常穿著各種數(shù)據(jù)庫的衣服上班下班。前些天穿了一件IvorySQL的衣服坐飛機，空姐看了我半天后問我：“這件始祖鳥的衣服好像沒見過別人穿過”。我笑著說：“這是高端品牌，一般人買不著”。上周一個朋友約我小聚，脫掉外套后發(fā)現(xiàn)倆人都穿了一件同款的PingCap藍色厚T恤?？礃幼硬恢刮乙粋€人發(fā)現(xiàn)了國產(chǎn)數(shù)據(jù)庫的這個好處。

今天聊聊自研數(shù)據(jù)庫的難點，在看到這個問題的時候肯定有些朋友會問：“為什么我們需要大型數(shù)據(jù)庫，把自己的數(shù)據(jù)庫拆小不就解決問題了嗎？”，我也經(jīng)常會聽到：“為什么非要這樣，為什么不那樣”。每個企業(yè)的實際情況不同，其需求是不同的，作為一個用戶你說不需要某個功能是完全沒毛病的，不過作為數(shù)據(jù)庫廠商，需要為各種各樣的應用場景提供解決方案。

進入正題，對于這個問題大家的觀點可能比較一致，不管采用哪種方式，自研確實很難，因為關系型數(shù)據(jù)庫發(fā)展這么多年，很成功的大型商用集中式通用數(shù)據(jù)庫就那么幾個，最成功的不外乎Oracle、SQL SERVER、DB2這三巨頭。連曾經(jīng)風光無限的SYBASE、 INFORMIX在大浪淘沙中都已經(jīng)變成路人甲了。

這些年國產(chǎn)數(shù)據(jù)庫替代的需求很旺盛，以中國如此大的數(shù)據(jù)庫市場，能不能培養(yǎng)出一個像Oracle一樣的數(shù)據(jù)庫產(chǎn)品呢？我想應該能，不過從零開始從頭研發(fā)似乎難度有點大，比如說一個類似Oracle的數(shù)據(jù)庫，其核心代碼一般來說要超過1000萬行，就按1200萬行計算吧。按照一個人月2000行核心代碼計算（這個代碼量不是全流程代碼量，數(shù)據(jù)庫核心研發(fā)全流程評估代碼量不會超過1000行/人月），那么一人年的代碼量是2.4萬，那么需要500人年。

按照最理想的狀態(tài)，我們能招到100個高水平的核心代碼研發(fā)工程師，從0開始最樂觀需要5年時間才能拿出一個初級產(chǎn)品，再花上兩三年在實際用戶那里去磨合提升，才能初步成型。按照數(shù)據(jù)庫核心代碼研發(fā)人員100萬的平均年薪（這個是比較低的，國外的數(shù)據(jù)庫核心代碼研發(fā)人員年薪要在30萬美金以上），需要投入的研發(fā)經(jīng)費是5億。在市場不明朗的情況下，每年投入一億，砸5年才能上市。這種買賣除非是航天軍工這種舉國體制下，恐怕很少會有企業(yè)能如此投入。如果再算上周邊工具與接口需要投入的數(shù)倍研發(fā)人員，以及三五百人起步的銷售人員，數(shù)百人的營銷市場人員與管理人員，一家成功的數(shù)據(jù)庫企業(yè)每年要投入的資金至少也要幾個小目標。而目前又有幾家企業(yè)每年能真正賣出幾個億的數(shù)據(jù)庫許可證與服務呢？

基于此我一般不太敢相信中國真的存在很多這樣的完全自研的數(shù)據(jù)庫企業(yè)和產(chǎn)品。算一算賬我們大體上也知道數(shù)據(jù)庫廠商動不動就說我們核心研發(fā)幾百人上千人是件多么不靠譜的事情，大部分國產(chǎn)數(shù)據(jù)庫廠商的年收入都不足1個小目標，如何能長期支撐如此燒錢的核心研發(fā)團隊？我所了解的很多數(shù)據(jù)庫廠商的核心研發(fā)人員不過二三十人而已，甚至一些小企業(yè)只是一個個位數(shù)。

既然現(xiàn)在從零開始干不大現(xiàn)實，那么基于開源代碼是否簡單一些呢？確實這是難度較低的做法，也是目前大多數(shù)國產(chǎn)數(shù)據(jù)庫廠商采用的方案?；陂_源代碼可選的是MySQL或者Postgresql，MySQL雖然很強大，長期霸占數(shù)據(jù)庫流行榜的TOP 2，但是MySQL的核心代碼不足以支撐它成為一個大型的集中式數(shù)據(jù)庫，其GPL開源協(xié)議也不支撐在它的基礎上大幅度修改代碼，并做成開源的商用數(shù)據(jù)庫。

因此PG變成了唯一的選擇了?？上У氖?，PG在整體架構(gòu)，核心代碼以及一些核心算法上也不具備直接成為Oracle這樣的大型通關系型數(shù)據(jù)庫的潛質(zhì)。astore存儲引擎、XID64、FULL PAGE WRITE、DOUBLE BUFFER、不太完善的checkpoint設計、低效率的lwlock代碼、由于缺乏pmon/smon導致的kill -9災難、優(yōu)化器能力不足、缺乏高并發(fā)與增量備份能力、沒有類似ORACLE RAC的高可用方案等因素都阻礙了PG作為一個大型關鍵數(shù)據(jù)庫的基礎平臺。 要想達成我提的目標，必須對PG的核心代碼做大手術才行。   

要對PG動大手術，依然需要大量高水平的數(shù)據(jù)庫核心開發(fā)人員參與，這也不是一般企業(yè)能玩得起的。所以說目前國產(chǎn)數(shù)據(jù)庫雖然有200多家了，不過大多數(shù)企業(yè)都選擇去搞分布式數(shù)據(jù)庫，而不去碰大型集中式數(shù)據(jù)庫這個燙山芋。這是因為數(shù)據(jù)庫核心研發(fā)的難度太大了，分布式數(shù)據(jù)庫可以把有限的研發(fā)放到分布式集群上，從而避免更加花錢的對數(shù)據(jù)庫核心的深度優(yōu)化所需要的投入。

花大力氣去研發(fā)數(shù)據(jù)庫核心不僅僅是技術上有難度，甚至有些時候有錢都不一定能干好，因為可能找不到足夠的高水平的研發(fā)人員。在沒有占有足夠大的市場的情況下，不敢投入巨資去做研發(fā)。產(chǎn)品水平不夠又無法吸引足夠多的用戶。這個先有雞還是先有蛋的問題是目前困擾國產(chǎn)數(shù)據(jù)庫發(fā)展的最大障礙。

雖然說研發(fā)一個大型集中式數(shù)據(jù)庫很難，但是中國自主可控的市場又必須有這么個產(chǎn)品，中國的數(shù)據(jù)庫市場規(guī)模也支撐得了這么一個產(chǎn)品，因此我還是對中國能夠出現(xiàn)這么一個產(chǎn)品持有樂觀態(tài)度的。只不過在目前千軍萬馬爭奪這個制高點的情況下，絕大多數(shù)企業(yè)會在這場長跑中落敗，只有少數(shù)企業(yè)最后會在競爭中活下來，就像30年前國外商用數(shù)據(jù)庫市場的那場大戰(zhàn)一樣。