中國有包含底層邏輯都是自己的資料庫嗎?

這段時間跟著幾位投資人見了一位在深圳的創業者,他主要的業務是做資料庫,號稱顛覆性的構思並且製作出來一套新的資料庫(底層邏輯)...

我理解的大意的是萬事萬物都是獨立且沒有意義的,所以在編程的時候沒有必要去定義,只給一串隨機的編碼事物,然後在應用時才賦予其意義。我看了一下演示,編程的時候是包含的結構,一個事物展開裡面有其他的事物....有別於現在常用的資料庫(好像出自於科德的萬物相關聯的理論...)他的資料庫採用全新的理論並且已經實現。

問題來了,我問了他幾個問題以及他的回答:

1、這個資料庫比起傳統的資料庫有什麼優勢?他回答...底層有是完全不是一樣了,編譯時間縮短,可以無損更改....

2、有什麼應用場景?他回答...想讓軍方使用,理由是中國要自己的資料庫,更安全...

好了,我的描述肯定不專業,有需要的話我這邊有他路演的APP(含概念以及團隊成員等信息)。我想請教的是:

1、中國需要自己的資料庫嗎?(就是底層邏輯也是自己的)

2、軍方或者民方對資料庫這塊的需求或者痛點是什麼?這個數據有應用場景嗎?

3、這個號稱顛覆性的資料庫是否真有其事?需要高人來驗證

這個項目我們是想要投資的,所以想深入了解一下相關信息。這個資料庫可信嗎?或者說有價值嗎?如果有學者想要和這位博士交流或者對接我也可以幫忙牽線搭橋。


現在這個時間點和開源界的盛況,要刻意糾結每一行代碼都要國人自行研發是一種對人力的不尊重。

其次,所謂的底層,究竟需要多底層,資料庫下運行的操作系統是否需要自己寫?硬體是否不能用x86架構?再比如編譯資料庫的編譯器?資料庫書寫的語言等,都是舶來品

第二段表達的主要觀點就是目前的計算機體系其實都是幾十年積累相輔相成的,糾結於是否自己從頭做一套並不是一個特別負責任的想法,姑且認為腦洞大開吧,仔細想想完全不可行且存在巨大資源浪費

分段來說說自稱自己全部做的資料庫

我認為是一種狹義的自行研發,那就是核心代碼是自己寫的,但是語言,編譯器,操作系統仍然是開源發布版本,而且除了代碼是自己的外,程序的邏輯,實現方式肯定又跳不出借鑒已有開源資料庫的路子,所以不知道現在如何定義這樣的研發方式,官話可能叫:自主研發吧?


投資資料庫的話,不如找我吧。看知乎quicklib和vn.py吵個沒完,我想讓這個笑話變成現實。知乎用戶:作為一名程序員,我這屬於什麼水平?

絕對不扯玄學,保密,安全。

目標很簡單,讓炒股大媽都能用上程序化交易。

目前所有程序化交易軟體,無論是否開源,都是為專業交易員設計的。只是為了學會簡單的使用,就要花費不少的時間。你不能指望大媽為了炒股,還去專門學寫程序。

所以,必須儘可能減少大媽花在學習程序化交易軟體使用上的時間,並且實際的運行的速度不能被專業交易員用的那些拉開不用跑分就能感覺到的差距。

因此,我提出需要兩項技術作為支撐。

把日常使用的語言稱為X,把程序化交易中使用的語言成為Y。用Y寫的程序,按X理解,意思不會出現偏差。那麼只需要看幾個例子就能迅速掌握了。可以大大降低學習時間。這個是有可能的,參考 各減平均各自乘相加除以項數開方

現在各種資料庫跑分一個比一個快。為什麼二進位文件體積不到1M的kdb+,一年單個核心授權費要上萬美元?就是因為asof join跑分比誰都快。程序化交易中非常需要這個。華爾街有很多沒有實力開發全套程序化交易軟體的公司都買了kdb+的授權。除了代碼看上去就像line noise以外,kdb+還有一個缺陷,也就是查詢和你寫的條件表達式先後順序有關的。這個就對炒股大媽很不友好了。所以需要一個全新設計的planner,查詢速度和順序無關,支持asof join,在asof join的跑分上,同價位機器要打敗其他資料庫,而在別的查詢跑分上,要打敗kdb+。 Summary of the 1.1 Billion Taxi Rides Benchmarks

總結,目標就是寫一個為炒股大媽優化的kdb+。


據我所知,關係資料庫除了oceanbase沒有別家


1、中國需要自己的資料庫

2、軍方項目里達夢比較吃香一些

3、先看出創新點再投資


謝邀。

觀點僅供參考。

針對這個神秘的資料庫,我的觀點是:

1. 「資料庫」這個概念比較模糊,應付的場景不同做法也不同,當然投資的價值也不同。不知道這個資料庫是類似MySQL(InnoDB/TokuDB/MyRocks)還是其他?

2. 在傳統資料庫領域,顛覆性的"全新理論"上次出現還是MIT大牛們發表的TokuDB使用的FT索引演算法論文,而且還是基於b-tree改進的,不是「全新」,這個太困難了。

3. MySQL也可以很安全,只是性能問題沒人去使用。

非常期望這是真的,薛定鄂的資料庫理論。

個人猜測這個理論只在某些場景上有用,比如壓縮、加密等。

針對題主的問題:

1. 個別企業可能是政治需要,目前開源的產品太多了,資料庫理論越來越普及,修修bug加加feature不是問題。

2. N/A

3. N/A


下次記得帶個懂技術的去面試!


在關係資料庫和SQL語言發明之前,類似的資料庫模型很多,但是自從關係型資料庫和SQL受到全世界程序員的追捧之後,所有的其他方向或者模型的資料庫都衰落了,因為性能或者佔用空間或者編程友好性等方面有缺陷,慢慢都退出了市場。近年來,由於關係型資料庫在擴展性方面遇到了瓶頸,出現了一些更原始的NoSQL資料庫,類似redis memcache mangodb等等眾多更底層的東西,它們分別在各自特定的領域具備更好的擴展性和性能表現。

資料庫領域難點比較多,代碼量也大,也經過了長時間的歷史考驗,現有的模型是多少代頂級程序員的共同選擇,很多技術路徑不可能徹底顛覆,對現有產品深刻理解的前提下再談創新,才是這個領域該有的態度。不看好這種動不動徹底顛覆的,況且單個技術路徑的改變未必能夠保證方向的正確性,或許是走了歷史的老路或者歧路。

萬丈高樓平地起,基礎很重要。資料庫研發需要的基礎知識體系很多,需要有頂級c++程序員,良好的架構設計,完整的測試體系,頂級的演算法工程師,事務處理的專家,分散式體系有深刻理解的頂尖人才,累計下來,才會有正確的姿勢開發下一代資料庫。

利益相關,以下為複製粘貼,

我們是小團隊,也在做資料庫,真正做起來,工程上實現,會比預想的進度慢很多,遇到的困難也遠超計劃,已經花了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


好些年前還在做雲的時候從頭實現過一個無中央節點的分散式存儲,結構化數據是它所支持的三個數據模型中之一。當時做了MySQL的plugin可以作為MySQL的外部表來在在線業務里,也對Impala做了定製化加入了對這個資料庫的支持,所以可以利用Impala來做數據分析,然後還有讀寫效率更高的原生的API。從某些意義上來說,離大家心裡期望的那個資料庫又有點差別,比方說在MySQL里作為外部表用的時候無法支持事務,但是從大面上來看可以說它也算是一個資料庫吧。

開發開始的那個時候還沒有license友好的存儲引擎可以直接用,再加上老闆事畢自己輪的大方針,於是選擇了整個底層的存儲引擎開始整體從頭開發,再加上老闆要求這套存儲系統出了需要提供結構化數據模型還應當同時支持對象數據模型以及文件系統的數據模型。所以當時這套存儲系統總共實現了兩個存儲引擎來應對不同數據模型的需求,一個跟Facebook haystack類似的log structured引擎,一個是自己設計的時序引擎。難說這兩個引擎有多麼創新,但是好歹算是自己從頭開始擼出來的於是也可以做一些特殊的優化,比方說存儲引擎可以跨進程已snapshot的方式讀取數據,在接入Impala之後可以直接在Impala的進程內掃描數據避免了額外的數據拷貝開銷可以達到很高的掃描吞吐。在結構化這一層接入了llvm來根據schema來直接生成解序列化row data的機器碼來提高讀取性能。在經歷了多年與memory corruption和leak的鬥爭還有性能上優化的鬥爭達到比較成熟後,在當時在某些領域還是有挺大的優勢的。尤其是即便是幾年後在產品基本成熟的時候Time-Series Database方向也還沒有特別多的選擇,當時我們的產品已經可以利用原聲API支持非常大的寫入吞吐,也可以利用Impala來達到非常高的查詢分析性能了。

說起來大概也算做過跟題主目前想要了解的一些問題接近的工作,離開這個雲這個行業也好幾年了不知道自己說的會不會比較離譜,簡單的說說個人的一些想法希望能對題主有所幫助吧。

中國需要自己的資料庫嗎?(就是底層邏輯也是自己的)

這個問題更多是從非技術性因素上考慮的吧,作為一個工程師,我自己的感覺是技術上來說完全從頭開始自己做資料庫只要有足夠的投入那其實並不是很難的事情。最開始做這個的時候大概是10年,那會兒基本上還沒有什麼可以參考的東西,最後這整套東西基本上我一個人也就擼出來了。像阿里,騰訊還有現在這麼多非常厲害的做資料庫方向的公司應該說是可以輕而易舉的做出來,但是為什麼做或者說為什麼不做,個人感覺考慮的應該更多是技術之外的因素吧。

軍方或者民方對資料庫這塊的需求或者痛點是什麼?這個數據有應用場景嗎?

在產品基本做成熟之後我就離開了,那會兒老闆的說法是這個東西他押寶在軍方市場。而且據說後面也的確是在軍方做測試可能也的確是賣進去了,但是這都是在我走之後的事情了具體情況不得而知。我當時了解到的情況是軍方考慮這種東西的時候會優選完全私有的實現避免外部人對內部系統實現細節的理解。但是如果沒有好的滿足這個條件的選擇的話,他們會更傾向於選擇開源的產品這樣畢竟還是可以投入人力去吃透他然後再需要的時候做需要的定製化開發和維護。所以從這個角度來說完全自己從頭實現底層邏輯的資料庫是在軍方是有賣點的。除此之外性能啊可靠性啊之類的,個人感覺只能算是一個不太高的門檻。都到了這個年代了已經有非常非常多各種各樣的資料庫產品來滿足各種各樣不同的應用領域並且在自己適合的領域上達到非常好的性能。

想起來還有另外一個優勢,我們更聽軍方的話,曾經port過這個資料庫到過申威處理器和龍芯上,後來我走了之後聽說又應軍方的要求port過到arm的處理器上。對於開源產品來說有的時候可能因為代碼基礎太大有用了一些平台相關的特性所以需要投入非常大的精力才能將其port到其他的平台,然而當port好之後怎麼說服上游把這些小眾平台支持的代碼合併上去可能又會成為問題,所以國人自己從底層開始主導開發的資料庫在這個角度看可能也算是一個優勢吧。

這個號稱顛覆性的資料庫是否真有其事?需要高人來驗證

顛覆這個事情我也沒見過太大的世面不好說,當時做的時候覺得自己做的東西很牛逼很顛覆,走出來看到更大的世界之後,覺得其實算不上什麼大不了的事情,在中國有非常非常多的人在這個領域做的非常非常好,比自己好太多強太多。


我們組目前在做純自研的關係資料庫,從sql到存儲,每一行都是自研。經過一年開發,已經實現了基本功能,tpcc可以跑起來並且跑分超越pg。


聽著像是個documentDB或者graphDB。這倆都不是新東西。當然,有可能不是。從題主描述看不出來是什麼 (*-*)

具體到題主的總是:

  1. 不需要。但需要有真懂資料庫的,能把開源資料庫的代碼都搞懂,問題就不大了。底層邏輯我理解是storage層,比如innoDB之於mysql。寫這種東西的確需要功底。如果有真懂資料庫的,必然就能寫出這種東西來。但重新造的輪子並不一定比現成的好使,所以真正使用的資料庫系統並不一定需要重新寫一套。所以,中國需要有能寫底層的人,但中國需要的資料庫並不一定需要具有新的底層。
  2. 現在的痛點主要在吞吐率上吧。低吞吐率的一般mysql就搞定了。
  3. 從題主描述很難看出來是不是新的。有可能只是個documentDB之類的東西,也可能真的是很新的。


有。馮玉才老師領銜的達夢資料庫,可惜已經比較老了。


感覺要麼題主不是資料庫領域人士所以用語看不懂,沒法回答;要麼碰到騙子了,資料庫屆的民科?


推薦閱讀:

如何評價貴陽建設「大數據之都」的計劃?
目前創辦一家數據挖掘的公司難點在哪裡?
有人了解Pivotal這個公司嗎,前景如何?
為什麼說HADOOP擴展性優於MPP架構的關係型資料庫?
如何自學數據產品經理?

TAG:資料庫 | 數據結構 | 資料庫設計 | 數據科學家 | 大數據 |