資料庫產品的成功絕對不是技術堆疊的成功，而是需要有大量的應用場景磨合才能逐步成功的。如果僅僅依靠自己那幾百個用戶，想要發展出成熟的高水平的商用資料庫產品來，那幾乎是不太能的。依靠開源社區的廣大用戶來研發自己的資料庫產品不失為一種比較好的策略。 ...
目前國產關係型資料庫已經有上百種，比較知名的也有好幾十種，其中大多數都和某些開源資料庫或者開源組件有關。實際上我並不反對國產資料庫基於開源代碼構建，因為利用開源代碼可以縮短國產資料庫研發與上市的時間，縮短國產資料庫與國外商用資料庫的技術差距。資料庫是在應用中不斷磨合出來，而不是簡單的研發出來的。很多朋友喜歡講某某資料庫技術很先進，用了很多新技術。如果為了滿足某個用戶的特殊應用場景需求而使用某些先進技術，這是沒有任何問題的，而對於資料庫產品來說並非如此。如果你看看Oracle資料庫就是可以看出其核心的很多核心技術甚至都是三十多年前就已經成型了，其技術優勢的來源是這些年不斷滿足用戶需求的功能迭代。
我們分析國產資料庫的源頭並不是為了證明哪個資料庫是開源套殼的，因為我並不反對國產資料庫擁抱開原生態，只要資料庫廠商在開源代碼上疊加了自己的技術和價值，哪怕只有簡單的服務，都是應該得到尊重的，資料庫產品的價值取決於資料庫廠商能夠給與用戶的價值。
上圖是2022年我們對部分國產資料庫的技術來源進行分析統計的結果，數據來源是截至與2021年7月的工信部白皮書。其中基於PG和Mysql兩大開源項目的國產資料庫產品接近60%。在我對國產資料庫的譜系分析的時候也看到，幾乎所有的國產資料庫廠家都在開源資料庫上進行了一定的研發改造，或者加入了自己的核心代碼。
一部分資料庫廠家的產品來源於開源代碼，不過目前已經於開源社區的代碼脫離獨立發展，今後很難把開源社區的一些新技術直接引入自己的資料庫產品了，比如Gaussdb和openGauss已經完全脫離了開源的PG和PGXC，已經只能獨立往前發展了。而另一部分廠家在對自己的資料庫產品做封裝的時候十分謹慎，保持著與開源社區代碼的相容性，這樣他們可以繼續跟上開源社區的腳步。
資料庫產品的成功絕對不是技術堆疊的成功，而是需要有大量的應用場景磨合才能逐步成功的。如果僅僅依靠自己那幾百個用戶，想要發展出成熟的高水平的商用資料庫產品來，那幾乎是不太能的。依靠開源社區的廣大用戶來研發自己的資料庫產品不失為一種比較好的策略。
打造國產資料庫開源生態也是一種十分不錯的策略，從今年的鯤鵬開發者大會上可以看到，擁抱openGauss開源社區的企業越來越多。利用華為巨大的研發投入抱團取暖，把國產的openGauss開源社區做好做大，也是國產資料庫發展的一條不錯的道路。
國產資料庫種類繁多，來源各異，因此把國產資料庫的家譜高清楚也不是一件容易的事情，昨天一個朋友畫了一張信創資料庫的圖，讓我幫忙看看是否正確。從中受到啟發，我畫了一張更全的國產資料庫譜系圖，我會把它附在本文的結尾處。本圖僅僅是我個人的認知，並不權威。因此圖中可能存在一些疏漏，如果大家發現問題，可以留言告訴我。
畫這張譜系圖也並不是為了證明大多數國產資料庫是開源套殼，剛纔我就說過我十分贊成國產資料庫擁抱開源社區。實際上國產資料庫廠商對是否使用了開源代碼往往遮遮掩掩是很沒必要的。在自己產品中大膽的聲明基於開源代碼也沒啥丟臉的，反而是正確的聲明開源代碼是尊重知識產權的表現。你如果去看看Oracle的版權聲明，會發現，Oracle資料庫的代碼中也使用了大量的開源代碼。
正確的聲明開源代碼，不僅僅是國產資料庫在尊重知識產權方面的表現，也為用戶能夠能更好的選型資料庫和使用資料庫提供了便利。如果某個用戶以前大量使用過PG資料庫，那麼他們在XC資料庫選擇的時候，選擇一個和PG資料庫有淵源的商用資料庫產品是不是更合適一些呢？如果我是企業的IT主管，我肯定會這麼考慮。
作者|白鱔
本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/The-Genealogy-of-Domestic-Database.html
