數(shù)據(jù)庫核心開發(fā)知多少--大家一起來寫數(shù)據(jù)庫引擎（獲獎名單已公布-9-25）

send_linux

獲獎名單已公布，詳情請看：http://www.72891.cn/thread-4099837-1-1.html

數(shù)據(jù)庫應用項目是通過數(shù)據(jù)庫引擎與數(shù)據(jù)庫鏈接的。何為數(shù)據(jù)庫引擎呢？簡而言之，數(shù)據(jù)庫引擎就是驅動各種數(shù)據(jù)庫的程序，它負責處理數(shù)據(jù)庫相關工作的整個核心部份。同樣的，數(shù)據(jù)庫應用項目的操作指令，均會通過數(shù)據(jù)庫引擎的處理作用到數(shù)據(jù)庫上。國內同行做數(shù)據(jù)庫核心引擎開發(fā)方面工作還是比較少的。大家更多的是停留在熟練使用和部分代碼的修修補補上。

想必大家在國內各種技術社區(qū)和大會上都見過，各種對Oracle內幕，比如塊構造，隱藏參數(shù)等津津樂道，對于調整好一條SQL語句使之在甲骨文的優(yōu)化器下能高性能運轉而感到成就感十足。在開源數(shù)據(jù)庫技術方面，大家則熱衷于在開源代碼上修修改改來滿足自己的業(yè)務需求。

但是您有想過自己來試一下，從頭開發(fā)一個完整的數(shù)據(jù)庫么？
比如從頭創(chuàng)建一個Linux下簡易分布式文檔型數(shù)據(jù)庫？
歡迎大家加入我們的討論！

如果您對NoSQL技術選型方面想更多了解，歡迎參與我們的有獎調查活動：NoSQL和大數(shù)據(jù)技術大調查，歡迎大家參與！

如果您對這樣的挑戰(zhàn)沒有概念，您可以看一下這個：ITPUB資深版主wangzhongnew的一個學習課程：http://www.dataguru.cn/article-3165-1.html

本期話題：
1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？

本期嘉賓：
ITPUB資深版主：wangzhongnew，畢業(yè)于加拿大卡爾加里大學，于2005年在IBM多倫多實驗室進行DB2數(shù)據(jù)庫的研發(fā)與技術支持，并參與設計IBM下一代彈性數(shù)據(jù)平臺。2012年創(chuàng)立SequoiaDB巨杉NoSQL數(shù)據(jù)庫并擔任總架構師與首席技術官。

活動時間：
2013年8月18日-9月10日

活動獎品：
分享最精彩的Cuer將獲得價值300元的羅技K400無線觸控鍵盤一個，共一個
最佳參與分享Cuer將獲得價值100元的無線路由一個，共5個


更多活動內容，請關注ChinaUnix官方微信！

xike2002

mark一下，下來補充。

1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
答：數(shù)據(jù)庫的引擎技術和存儲技術是當今時代的大家非常關心的東西。曾經(jīng)下載過MYSQL的源碼，真心感覺編寫和設計這些代碼人的功力太深了，可能還是因為閱歷不夠，無法完全理解所有的代碼，只能繼續(xù)修煉內功不斷的提高，有機會在品讀MYSQL源碼。

2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
答：我覺得任何一種數(shù)據(jù)庫引擎的開發(fā)都不容易，需要付出很多的努力！

你能用的數(shù)據(jù)庫引擎取決于mysql在安裝的時候是如何被編譯的。要添加一個新的引擎，就必須重新編譯MYSQL。在缺省情況下，MYSQL支持三個引擎：ISAM、MYISAM和HEAP。另外兩種類型INNODB和BERKLEY（BDB），也常�？梢允褂�。

下面看一下幾種常用的引擎。
ISAM
ISAM是一個定義明確且歷經(jīng)時間考驗的數(shù)據(jù)表格管理方法，它在設計之時就考慮到數(shù)據(jù)庫被查詢的次數(shù)要遠大于更新的次數(shù)。因此，ISAM執(zhí)行讀取操作的速度很快，而且不占用大量的內存和存儲資源。ISAM的兩個主要不足之處在于，它不支持事務處理，也不能夠容錯：如果你的硬盤崩潰了，那么數(shù)據(jù)文件就無法恢復了。如果你正在把ISAM用在關鍵任務應用程序里，那就必須經(jīng)常備份你所有的實時數(shù)據(jù)，通過其復制特性，MYSQL能夠支持這樣的備份應用程序。
MYISAM
MYISAM是MYSQL的ISAM擴展格式和缺省的數(shù)據(jù)庫引擎。除了提供ISAM里所沒有的索引和字段管理的大量功能，MYISAM還使用一種表格鎖定的機制，來優(yōu)化多個并發(fā)的讀寫操作。其代價是你需要經(jīng)常運行OPTIMIZE TABLE命令，來恢復被更新機制所浪費的空間。MYISAM還有一些有用的擴展，例如用來修復數(shù)據(jù)庫文件的MYISAMCHK工具和用來恢復浪費空間的MYISAMPACK工具。
MYISAM強調了快速讀取操作，這可能就是為什么MYSQL受到了WEB開發(fā)如此青睞的主要原因：在WEB開發(fā)中你所進行的大量數(shù)據(jù)操作都是讀取操作。所以，大多數(shù)虛擬主機提供商和INTERNET平臺提供商只允許使用MYISAM格式。
HEAP
HEAP允許只駐留在內存里的臨時表格。駐留在內存里讓HEAP要比ISAM和MYISAM都快，但是它所管理的數(shù)據(jù)是不穩(wěn)定的，而且如果在關機之前沒有進行保存，那么所有的數(shù)據(jù)都會丟失。在數(shù)據(jù)行被刪除的時候，HEAP也不會浪費大量的空間。HEAP表格在你需要使用SELECT表達式來選擇和操控數(shù)據(jù)的時候非常有用。要記住，在用完表格之后就刪除表格。
INNODB和BERKLEYDB
INNODB和BERKLEYDB（BDB）數(shù)據(jù)庫引擎都是造就MYSQL靈活性的技術的直接產(chǎn)品，這項技術就是MYSQL++ API。在使用MYSQL的時候，你所面對的每一個挑戰(zhàn)幾乎都源于ISAM和MYISAM數(shù)據(jù)庫引擎不支持事務處理也不支持外來鍵。盡管要比ISAM和MYISAM引擎慢很多，但是INNODB和BDB包括了對事務處理和外來鍵的支持，這兩點都是前兩個引擎所沒有的。如前所述，如果你的設計需要這些特性中的一者或者兩者，那你就要被迫使用后兩個引擎中的一個了。

3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？
答：NOSQL系統(tǒng)一般都會宣傳一個特性，那就是性能好，然后為什么呢？關系型數(shù)據(jù)庫發(fā)展了這么多年，各種優(yōu)化工作已經(jīng)做得很深了，NOSQL系統(tǒng)一般都是吸收關系型數(shù)據(jù)庫的技術，然后，到底是什么因素束縛了關系型數(shù)據(jù)庫的性能呢？我們從系統(tǒng)設計的角度看這個問題。

（1） 索引支持。關系型數(shù)據(jù)庫創(chuàng)立之初沒有想到今天的互聯(lián)網(wǎng)應用對可擴展性提出如此高的要求，因此，設計時主要考慮的是簡化用戶的工作，SQL語言的產(chǎn)生促成數(shù)據(jù)庫接口的標準化，從而形成了Oracle這樣的數(shù)據(jù)庫公司并帶動了上下游產(chǎn)業(yè)鏈的發(fā)展。關系型數(shù)據(jù)庫在單機存儲引擎支持索引，比如Mysql的Innodb存儲引擎需要支持索引，而NOSQL系統(tǒng)的單機存儲引擎是純粹的，只需要支持基于主鍵的隨機讀取和范圍查詢。NOSQL系統(tǒng)在系統(tǒng)層面提供對索引的支持，比如有一個用戶表，主鍵為user_id，每個用戶有很多屬性，包括用戶名，照片ID(photo_id)，照片URL，在NOSQL系統(tǒng)中如果需要對photo_id建立索引，可以維護一張分布式表，表的主鍵為<photo_id, user_id>形成的二元組。關系型數(shù)據(jù)庫由于需要在單機存儲引擎層面支持索引，大大降低了系統(tǒng)的可擴展性，使得單機存儲引擎的設計變得很復雜。

（2）事務并發(fā)處理。關系型數(shù)據(jù)庫有一整套的關于事務并發(fā)處理的理論，比如鎖的粒度是表級，頁級還是行級，多版本并發(fā)控制機制MVCC，事務的隔離級別，死鎖檢測，回滾，等等。然而，互聯(lián)網(wǎng)應用大多數(shù)的特點都是多讀少些，比如讀和寫的比例是10 : 1，并且很少有復雜事務需求，因此，一般可以采用更為簡單的copy-on-write技術：單線程寫，多線程讀，寫的時候執(zhí)行copy-on-write，寫不影響讀服務。NOSQL系統(tǒng)這樣的假設簡化了系統(tǒng)的設計，減少了很多操作的overhead，提高了性能。

（3）動態(tài)還是靜態(tài)的數(shù)據(jù)結構。關系型數(shù)據(jù)庫的存儲引擎總是一顆磁盤B+樹，為了提高性能，可能需要有insert buffer聚合寫，query cache緩存讀，經(jīng)常需要實現(xiàn)類似Linux page cache的緩存管理機制。數(shù)據(jù)庫中的讀和寫是互相影響的，寫操作也因為時不時需要將數(shù)據(jù)flush到磁盤而性能不高。簡而言之，關系型數(shù)據(jù)庫存儲引擎的數(shù)據(jù)結構是通用的動態(tài)更新的B+樹，然而，在NOSQL系統(tǒng)中，比如Bigtable中采用SSTable + MemTable的數(shù)據(jù)結構，數(shù)據(jù)先寫入到內存的MemTable，達到一定大小或者超過一定時間才會dump到磁盤生成SSTable文件，SSTable是只讀的。如果說關系型數(shù)據(jù)庫存儲引擎的數(shù)據(jù)結構是一顆動態(tài)的B+樹，那么SSTable就是一個排好序的有序數(shù)組。很明顯，實現(xiàn)一個有序數(shù)據(jù)比實現(xiàn)一個動態(tài)B+樹且包含復雜的并發(fā)控制機制要簡單高效地多。

（4）Join操作。關系型數(shù)據(jù)庫需要在存儲引擎層面支持Join，而NOSQL系統(tǒng)一般根據(jù)應用來決定Join實現(xiàn)的方式。舉個例子，有兩張表：用戶表和商品表，每個用戶下可能有若干個商品，用戶表的主鍵為<user_id, item_id>，用戶和商品的關聯(lián)屬性存放在用戶表中，商品表的主鍵為item_id，商品屬性包括商品名，商品URL，等等。假設應用需要查詢一個用戶的所有商品并顯示商品的詳細信息，普通的做法是先從用戶表查找指定用戶的所有item_id，然后對每個item_id去商品表查詢詳細信息，即執(zhí)行一次數(shù)據(jù)庫Join操作，這必然帶來了很多的磁盤隨機讀，并且由于Join帶來的隨機讀的局部性不好，緩存的效果往往也是有限的。在NOSQL系統(tǒng)中，我們往往可以將用戶表和商品表集成到一張寬表中，這樣雖然冗余存儲了商品的詳細信息，卻換來了查詢的高效。

liuxuejin

這個必須的幫頂，可惜功力不高啊，剛畢業(yè)的時候還特地下載了一個微型的java的數(shù)據(jù)庫打算啃啃源碼，但是 一直啃不動。

forgaoqiang

目前對于數(shù)據(jù)庫系統(tǒng)還處于使用和優(yōu)化階段，不具有開發(fā)能力，倒是對數(shù)據(jù)庫引擎有一些了解，分享下我所知道的一些內容吧~~
話說，斑竹給的學習地址鏈接是個廣告啊 要收費的樣子~~


1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？

Editing & Lunching~~

hbsycw

好話題，積極參與下，拋磚引玉：

1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
答：信息化時代，數(shù)據(jù)的持久存儲應該是一切應用的基礎，而數(shù)據(jù)庫就是數(shù)據(jù)存儲管理自動化的結晶。從開始接觸軟件開發(fā)，就在不斷接觸數(shù)據(jù)庫，從簡單的桌面數(shù)據(jù)庫ACCESS到大的關系數(shù)據(jù)庫MS SQLServer\Oracle\DB2等, 現(xiàn)在比較喜歡用的是MySQL，曾經(jīng)嘗試下載過源代碼來看，感覺還是需要在計算機基礎：數(shù)據(jù)結構和算法上下功夫。

2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
答：數(shù)據(jù)庫引擎是一個數(shù)據(jù)庫的核心功能實現(xiàn)。如果，我來參與開發(fā)，我想，第一步應該是功能定位。這里以MySQL來說，MySQL有多種引擎實現(xiàn)MyISAM\Innodb\MERGE\MEMORY(HEAP)\BDB(BerkeleyDB) 等，功能各不相同，難點應該還是在于，性能和功能的設計平衡。

3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？
答：NoSQL數(shù)據(jù)庫簡單說是KEY-VALUE存儲，和關系型數(shù)據(jù)庫的思想?yún)^(qū)別上，應該是簡化了關系，而提高了存取效率。

syzxlyx

1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
嘗試閱讀mysql，但太大，c、c++功力不夠，還有就是單槍匹馬，很難，沒看出所以然。
2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
我覺得是定位及架構設計最難。首先要找出你的位置，要有需求，然后才是架構設計要好，后續(xù)的模塊化開發(fā)，系統(tǒng)的擴展性才能好。
3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？
差別主要在于acid。nosql通過弱化某些方面來提升性能或擴展性，這是由acp理論決定了的平衡

tomac_cu

1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
postgresql 和 mysql  最大的感受是postgresql更加嚴謹

2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
難點在于如何協(xié)調不同的應用對于IO和CPU的使用特點。
如高IO和多事務并發(fā)是不同的類型，通過何種方式來調整dbe的即時優(yōu)化策略。
以及在現(xiàn)有數(shù)據(jù)結構下，來適應即時優(yōu)化策略，將是DBE的一個重要發(fā)展方向和難點。

3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？
NoSQL是面向數(shù)據(jù)的。而RDMS則是面向事務的。所以RDMS更適用于現(xiàn)有的各類中小型應用。
基于關系的運算，是實體世界的表格的抽象，也是企業(yè)管理中的重要元素。
NoSQL基于KV，象圖書館這樣的應用，在企業(yè)管理中少而又少。
所以注定了NoSQL只能在企業(yè)關鍵應用中進行助力，而無法全面取代RDBMS

gpingyang

1、您嘗試閱讀過哪些數(shù)據(jù)庫的代碼，您的感受是什么？
試著閱讀過一點點mysql和postgresql的源代碼，最大的感受就是：
mysql的代碼太過混亂，風格極不統(tǒng)一，C++，C風格的都有，模塊結構也不是很清楚，讀起來很費力，但這并不妨礙它成為最成功的開源數(shù)據(jù)庫
postgresql則是純C風格的，功能上mysql更強，但沒有mysql那種為單純強調性能的優(yōu)化；模塊劃分很清晰，風格也很統(tǒng)一；雖然是C代碼，但處處能體現(xiàn)OO的思想
也研究過tokyocabinet，不知道它是怎么火起來的，也許真的是它吹噓的那樣效率高？

2、如果您來參與開發(fā)數(shù)據(jù)庫引擎，您認為難點在哪？
數(shù)據(jù)庫是個很大的話題，但發(fā)展這么多多年，數(shù)據(jù)庫的理論大致沒啥變化
數(shù)據(jù)庫（或者應該專指RDBMS系統(tǒng)）從結構上可以分為下面幾個，每個模塊的難點都不太相同
1) sql parser
parser的功能就是把sql語句字符串解析出來，用程序語言的數(shù)據(jù)結構表示出來，并對語義的檢查，看輸入是否是個有效的sql
這部分的理論就是編譯原理中的詞法和語法解析的部分，實現(xiàn)詞法語法解析的技術已經(jīng)比成熟了。
lex, yacc之類的工具可以很好的完成這項工作，借助工具即使不太熟悉編譯原理的人也可以根據(jù)sql BNF語法實現(xiàn)parser
boost spirit庫可能也是另一個選擇，可以完全用C++代碼優(yōu)雅的完成一個parser，但我不清楚是不是真的有用這個庫去實現(xiàn)parser的
sql parser的難點不在編譯，而是在對sql 標準確的理解
2) sql reducer
reducer是對輸入sql進行優(yōu)化，裁減，涉及算法方面的東西就比較多了，個人認為是一個比較難的地方
比如，多個表join,怎樣的順序進行才比較高效，哪些子查詢比可以去掉
難點就是評估執(zhí)行的代價，并從估算和實際執(zhí)行中找到一個平衡點
3) execution plan builder
這部分根據(jù)reducer輸出的優(yōu)化后的結構，構建出執(zhí)行計劃
執(zhí)行計劃是由多個執(zhí)行元語構成的一棵樹結構，執(zhí)行元語如，分組，去除重復，排序等
它在數(shù)據(jù)庫中起到承前啟后的作用，怎么把它和上層與下層結合起來，抽象出一致的接口就顯得很重要
還有，一些動作是無法做到管道化的（就是說，必須把表中的所有數(shù)據(jù)都查出來，才可以把結果吐出來，例如：排序）
怎樣緩存中間生成的結果，也是一個難點，如果全部緩存在內存，結果集過大時就有撐爆內存的危險
4) storage
怎么在磁盤中存儲數(shù)據(jù)，meta data，index，實際數(shù)據(jù)怎么管理
內存和外存之前的速度差幾個數(shù)量級，因為這個差異，數(shù)據(jù)庫都會實現(xiàn)一個buffer manager策略，按塊讀取
異步IO也是一種可以利用的技術，分離讀與寫，這些都可以算作是難點
事務處理，這個東西絕對是難點中的難點

3、NoSQL等分布式數(shù)據(jù)庫和現(xiàn)在主流的RDMS的思想上有何差別？
NoSQL處理的數(shù)據(jù)結構更為簡單，更強調擴展性和效率
RDMS更關注的是ACID，更適合像交易系統(tǒng)這樣的東西
其實，我更愿意把NoSQL看作是"Not only SQL"

ecjtubaowp

話題很高深啊�。。�

send_linux

ecjtubaowp 發(fā)表于 2013-08-19 22:42
話題很高深�。。�！

歡迎老五多分享啊，呵呵