如何評價王垠的 A 計劃？

01-15

根據《商業計劃》，其A計劃（新型資料庫）：
我現在最感興趣的一件事情，也是技術難度最高的一件事，就是設計和製造一個全新的資料庫系統（DBMS）……從我的 B+ 樹設計出發，再加上對資料庫裡面各種概念（比如事務）的重新理解，我將會構造一個極其簡單而高效的底層資料庫系統。在此之上，結合我對程序語言和編譯器的深刻理解，這個資料庫將擁有一個極其簡單而強大的查詢系統，用以解決遠程訪問和多機構架的需求……我的另一個目標就是消化和轉換這類分散式系統理論，使得它們大大簡化，用以擴展底層資料庫，而得到分散式的擴展和可靠性保障……這是一個相當大規模的計劃，包括了大量的研究和實現工作，所以可能會花不少時間。當然，最後的代碼應該不會很長。我的目標，是建立起一家可以跟 Oracle 匹敵的資料庫公司，統一和簡化互聯網領域和其它新興領域的資料庫應用，並且蠶食銀行等傳統領域的資料庫市場。
姊妹問題：
如何評價王垠的B計劃？
如何評價王垠的C計劃？

可以嘗試來螞蟻金服 OceanBase 團隊，可能有戲，單槍匹馬，不太可能的。很多工程問題，需要實際的場景去逼壓出來。

他的思路和業界思路是不一樣的。

業界通常是發現需求，或者是發現現有的不足。垠神的思路是，我要搞個資料庫，我就能從無到有搞一個大新聞出來，這個資料庫沒有現在資料庫的各種缺點，有各種先進理論加持，有各種先進技術保障。

這通常不容易，尤其是從無到有地實現一個業界發展了很多年的東西，最後往往會發現殊途同歸。在計算機領域，能把理論率先結合到實踐裡面的都是領域佼佼者，對於一些基礎組件，理論的發展和落地是非常重要的，但是……B+樹？這兩年看到的分形樹就算是B+樹在理論領域最知名的變體了，其他的根本沒什麼新進展出現。那麼，做一個先進的資料庫為什麼要從B+樹開始？

剛入行的新人，都應該動手造造輪子。就像曾經學習演算法的時候，都是從頭實現STL裡面的各種結構和演算法，可是重新實現和能完全超越並沒有必然聯繫。垠神的新資料庫能超過MySQL已經是萬幸，畢竟他不喜歡處理各種corner case。

本來不打算回答這個問題，但是介於A計劃提到了我們的產品，我還是想來回答這個問題。

A計劃提到，設計和製造一個全新的資料庫系統是技術難度最高的一件事。這個我認同，開發資料庫以及存儲引擎難度不小，需要很多時間來打磨。資料庫的確也很重要，也有經濟價值，但是不是最亂，忽悠最多的一個領域，我就不知道了。的確，有些廠商會過度的宣傳一些並不太實用的功能，或者過度宣傳某些不複雜的實現，這是商業手段，很多其他領域都在宣傳，比如手機，各種智能穿戴設備等等，這不能說明資料庫領域有多亂。資料庫領域除了商業部分，應該還有技術研發以及理論研究部分。我相信國內外很多公司研發的各類資料庫在滿足各種不同場景的需要時，並沒有忽悠，也不亂。

資料庫從最開始發展到現在，提出了很多新概念，有些概念的確也是新瓶裝舊酒，變化不大，但是很多概念是有意義的，不是為了嚇人，每一種模型或者概念的提出都是為了解決一類新的問題。時代在變，需求也在變，所以資料庫也在變。我相信，模型或者概念的提出者正是充分了解了需求變化了，才會提出新的模型和概念以及實現去解決他們面臨的新問題，而不是A計劃中說的「沒有從根本性的認識到他們在解決什麼問題」。

A計劃提到了Berkeley DB，說它用了上百萬行代碼（其實也沒有上百萬行代碼），最後只解決了一個用數千行代碼就能更好解決的問題。由此，A計劃認為資料庫領域的人，根本不知道自己在做什麼，不懂計算和語言。這個我非常不認同。幾千行代碼能解決問題到底是什麼，到底是什麼，該計劃沒有說，我猜測可能是KV對的CRUD（如果不是，請糾正），那幾千行代碼，實現一個玩具級的KV存儲引擎應該不難，但是這樣實現的KV存儲引擎，並沒有任何商業上的價值，正確性，穩定性都無法保證。至於說到現在資料庫領域的人根本不知道他們在做什麼，不懂計算和語言，我只能說，無知者無畏。

A計劃，在後面提到會改造B+樹和事務，實現一個簡單而高效的底層資料庫，同時要實現一個簡單而強大的查詢系統，我不好評價，只能說，這個工作將是非常困難的，希望能實現。至於，A計劃說的要把資料庫還原到它本來應該是的樣子，恰到好處的解決問題，我很好奇，什麼時候資料庫原來的樣子，不是用來存儲數據嗎？什麼時候恰到好處了？這些是否有標準？解決什麼問題？

說到分散式資料庫，A計劃說這個領域很混亂。Paxos是沒有人講得清楚的理論。Raft雖然好些，但是也有很多問題。這些我都不同意，Paxos並不是沒有人講得清楚，也不是沒有人能懂的理論，在Raft出現之前，就有很多分散式系統，他們用的就是Paxos演算法，所以肯定有人講得清，看得懂。

A計劃的作者提到他會轉換分散式理論，是分散式的擴展和可靠性得到保障，我拭目以待，希望早日實現，前提是他要真正懂分散式。

最後，作者提到，他的目標是建立一個可以和Oracle匹敵的資料庫。我覺得他過謙了，如果現在這個領域的人都不知道自己在做什麼，而他知道，他的公司一定會在短時間內打敗Oracle的。

看完這個計劃後，我有一個簡單的結論，該計劃的作者沒有做過資料庫。

我們也是小團隊，在做資料庫，真正做起來，工程上實現，會比預想的進度慢很多，遇到的困難也遠超計劃，已經花了11個月時間，只做出了單機性能遠超memcache 和redis的KV資料庫，內存佔用低於redis,例如100萬4.1KByte，redis佔用8G, 我們佔4.1G, 數據底層庫優化非常耗時，其中有超越std::unordered_map/set性能70%的自研hash_map/set,還做了比boost lockfree spsc queue快50%的wait free queue,支持任意大小，任意對象，有了比std::shared_ptr快一倍，功能全覆蓋，支持完全線程安全的新共享指針庫。有了新型更高性能spin lock和多種新型鎖，例如支持讀鎖升級為寫鎖等。有了比boost asio io_service快五倍的std function任務調度庫，。。。。還有大量計劃中正在編寫的底層庫，還有很多已經列入計劃，有新演算法，但無暇實現的庫。實現了一些容易做的庫，

包括二進位轉十進位，用新演算法將慢速除法優化為更快的乘法，比std::to_string提升了數倍，從整個C++底層開始做更好的基礎庫，目標也很宏大，人手少，無錢，一邊還要找項目養團隊，一邊努力開發haisql中，已經實現的部分可下載評測 http://www.haisql.com 。。。。。。

我最期待的不是王垠的A計劃，B計劃，C計劃....

我最期待的是他用什麼語言實現這些ABCDEFG計劃，鑒於他之前將各個語言噴了個遍，我很期待他有knuth的精神，創造一門X語言，然後使用牛X語言去實現他的這些計劃。

如果沒有X語言，難道要使用彙編？

時間會證明一切。

我不想談論看好或者不看好的什麼的。這都沒有意義。

相反，我倒很期待看到他的設計、理念以及努力。哪怕項目失敗，哪怕結果打臉，這其中的思考和求索也都是有意義的

若真有一款好用，小巧，耐乾的資料庫出世，光大碼農兄弟又何樂而不為？

不看好他做工程性那麼強的項目。當中大量的Corner case需要dirty work來解決，不是他的強項

從A計劃中，看到了他的野心，可能不小。

但又讓我產生另外一種感覺，和我之前看胡正博客時產生的感覺一樣。

也許你也會跟我有相同的感覺。

個人認為他還是實施B計劃比較好，畢竟腦殘粉比較多。

雖然不想黑他，但是我覺得他過一段時間又會寫一篇文章，《為什麼我不再執行A計劃？》，或者是，《為什麼我不再研究分散式資料庫？》。

資料庫界羅永浩

不幸的是，人總會老死的。獨孤求敗的少年也會在長白山的落日殘雪裡孤獨終老，獨樹一幟的天才也會在夕陽西下後的午夜對著床單痛哭。

我們可能再也聽不到一位狂人的plan B了，因為他註定會花盡後半生寫就：「我為什麼放棄plan A」。

預言，必須要實現

A計劃給人的感覺就是，剛掌握了B+樹，就準備寫一個分散式資料庫，可能B+樹真的掌握的非常好……

另外，他都精通PL那麼久了還沒有產出一個新的語言，現在他說正在消（xue）化（xi）分散式系統理論……

以他的套路，最後應該會宣布其他計劃都因為B計劃達不到預期而失敗。

Linux是一個人設計出來的，C語言是一個人設計出來的，nginx是一個人設計出來的，lucene是一個人設計出來的，sqlite，redis，netty，PHP，python，lua，hadoop等等許多知名的軟體最初都是一個人設計出來的，我相信一個優秀的程序員能底成千上百的普通coder，但是從他的言行看，並不是這類人。知易行難，做這種大型系統，不是了解一兩個數據結構那麼簡單。除了喬布斯，許多用重新定義這個詞的人，不過是賺點噱頭而已。

這才是大神該做的事，紀念碑。

這是王垠證明自己的終極方案，此產品一旦成功推出並被市場驗證，所有質疑王垠的人將全部閉嘴。

散了吧，王銀同學真的只是想告訴我們，

即使我這樣牛逼的人也會吹牛逼~

沉迷在自己是天才的世界裡...

一個從來沒把事情干到底過，不惑之年還沉迷於自己是超級天才的夢了，不是別的，就是巨嬰

我愛我家從頭再來

志新:（給阿文點煙）啊張秘書

小張:唉唉
志新:的把我下一步我計劃給我阿文兄弟念念
小張:唉……哪個計劃？你這計劃有一百個呢
志新:就是最新計劃里的第一大步里的第一小步里的那個……括弧一……

希望王大神不只是說說而已，如果開源的話，我也可以去做點貢獻。

給垠神投資30元，支持一下垠神創業。接下來垠神的資料庫做出來了，再投資一個億，雖然現在還沒有一個億，哈哈哈。

就是想做個文件系統，扯了半天皮。