Ⅰ 資料庫的事務處理必須滿足ACID原則，ACID分別是指什麼
ACID，指資料庫事務正確執行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。
Ⅱ 資料庫中的事務（Transaction）的ACID指的是什麼
事務是由一組sql語句組成的邏輯處理單元，事務具有以下4個屬性，通常簡稱為事務的ACID屬性。
ACID是Atomic（原子性）
Consistency（一致性）
Isolation（隔離性）
Durability（持久性）的英文縮寫。
Atomic（原子性）：指整個資料庫事務是不可分割的工作單位。只有使據庫中所有的操作執行成功，才算整個事務成功；事務中任何一個SQL語句執行失敗，那麼已經執行成功的SQL語句也必須撤銷，資料庫狀態應該退回到執行事務前的狀態。
Consistency（一致性）：指資料庫事務不能破壞關系數據的完整性以及業務邏輯上的一致性。例如對銀行轉帳事務，不管事務成功還是失敗，應該保證事務結束後ACCOUNTS表中Tom和Jack的存款總額為2000元。
Isolation（隔離性）：指的是在並發環境中，當不同的事務同時操縱相同的數據時，每個事務都有各自的完整數據空間。
Durability（持久性）：指的是只要事務成功結束，它對資料庫所做的更新就必須永久保存下來。即使發生系統崩潰，重新啟動資料庫系統後，資料庫還能恢復到事務成功結束時的狀態。
Ⅲ 如何自己實現一個關系型資料庫
對外數據模型為關系型資料庫，內部的實現主要分成兩大類，一類是disk-based，比如mysql，postgres，一類是memory based，後者包括MemSQL，SAP HAHA，OceanBase。看題目的意思指的是前者。這里說一個disk-based的關系型資料庫涉及多少東西。
上世紀70/80年代內存不大，數據不能都放在內存里，大部分數據都存在磁碟上，讀數據也需要從磁碟讀，然而讀寫磁碟太慢了，所以就在內存里做了一個buffer pool，將已經讀過的數據緩存到buffer pool中，寫的時候也是寫到buffer pool中就返回，buffer pool的功能就是管理數據在磁碟和內存的移動。在buffer pool中數據的管理單位是page。page大小一般幾十KB。一般都可以配置。如果buffer pool中沒有空閑的page，就需要將某一個page提出buffer pool，如果它是dirty page，就需要flush到磁碟，這里又需要一個LRU演算法。一個page包含多條記錄，page的格式需要設計用來支持變長欄位。如果這時宕機了，buffer pool中的數據就丟了。這就需要REDO log，將對數據的修改先寫到redo log中，然後寫buffer pool，然後返回給客戶端，隨後，buffer pool中的dirty page會被刷到數據文件中(NO FORCE)。那麼重啟的時候，數據就能從redo log中恢復。REDO log還沒刷完就刷數據到磁碟可以加快寫入速度，缺點就是恢復的時候需要回放UNDO log，回滾一些還沒有提交的事務的修改。寫log又分為邏輯log和物理log，還有物理邏輯log。簡單說邏輯log就是記錄操作，比如將某個值從1改成2.而物理log記錄具體到record的位置，例如某個page的某個record的某個field，原來的值是多少，新值是多少等。邏輯log的問題是並發情況下不太好恢復成一致。物理log對於某些操作比如create table又過於瑣碎，所以一般資料庫都採用混合的方式。為了跟蹤系統中各種操作的順序，這就需要為log分配id，記做LSN(log sequence number)。系統中記錄各種LSN，比如pageLSN, flushedLSN等等。為了加快宕機恢復速度，需要定期寫checkpoint，checkpoint就是一個LSN。
以上ACID里的C和D有關。下面說A和I，即原子性和隔離性。
這兩個性質通過concurrency control來保證。隔離級別有很多種，最開始有4種，從低到高read uncommitted, read committed, repeatable read, serializable。serializable就是多個事務並發執行的結果和某種順序執行事務的結果相同。除了serializable，其他都有各種問題。比如repeatable read有幻讀問題(phantom)，避免幻讀需要gap lock。read committed有幻讀和不可重復讀問題。後來又多了一些隔離級別，比如snapshot isolation，snapshot isolation也有write skew問題。早期，並發控制協議大多是基於兩階段鎖來做的(2PL)，所以早期只有前面提到的四種隔離級別，後來，又出現一類並發控制協議，統稱為Timestamp Ordering，所以又多了snapshot isolation等隔離級別。關於隔離級別，可以看看這篇論文 http://research.microsoft.com/pubs/69541/tr-95-51.pdf。2PL需要處理deadlock的問題。
Timestamp Ordering大體的思想就是認為事務之間沖突不大，不需要加鎖，只在commit的時候check是否有沖突。屬於一種樂觀鎖。
Timestamp Ordering具體來說包括多種，最常見的MVCC就是這類，還有一類叫做OCC(optimistic concurrency control)。MVCC就是對於事務的每次更新都產生新的版本，使用時間戳做版本號。讀的時候可以讀指定版本或者讀最新的版本。幾乎主流資料庫都支持MVCC，因為MVCC讀寫互相不阻塞，讀性能高。MySQL的回滾段就是用來保存老的版本。MVCC需要有後台線程來做不再需要的版本的回收工作。Postgres的vacuum就是做這事的。OCC和MVCC的區別是，OCC協議中，事務的修改保存在私有空間(比如客戶端)，commit的時候再去檢測沖突，通常的做法是事務開始時看一下自己要修改的數據的最後一次修改的時間戳，提交的時候去check是否這個時間戳變大了，如果是，說明被別人改過了，沖突。沖突後可以回滾或者重試。
上面這些搞定了就實現了資料庫的核心，然後為了性能，需要index，通常有兩種，一種支持順序掃描B+Tree,還有一種是Hash Index。單條讀適合用Hash Index,O(1)時間復雜度，順序掃描只適合用B+Tree，O(logN)復雜度。然後，有些查詢只需要掃描索引就能得到結果，有些查詢直接掃描數據表就能得到結果，有些查詢可以走二級索引，通過二級索引找到數據表然後得到結果。。具體用哪種方式就是優化器的事了。
再外圍一些，關系型資料庫自然需要支持SQL了，由SQL變成最後可以執行的物理執行計劃中間又有很多步，首先SQL通過詞法語法分析生成抽象語法樹，然後planner基於這棵樹生成邏輯執行計劃，邏輯執行計劃的生成通常涉及到等價謂詞重寫，子查詢消除等邏輯層面的優化技術，優化的目的當然是性能。比如等價謂詞重寫，用大於小於謂詞消除like，between .. and..等不能利用索引的謂詞。下一步是邏輯執行計劃生成物理執行計劃，物理執行計劃樹每個節點是一個operator，operator的執行就是實實在在的操作，比如掃表的operator，filter opertor。一個邏輯執行計劃通常可以有多個物理執行對應，選擇哪個就涉及到物理執行計劃優化，這里涉及到經典的cost model，綜合考慮內存,CPU, I/O,網路等。最典型的，三表join，從左到右還是右到左，使用hash join，還是sort merge join等。
Ⅳ 資料庫的問題：關系型資料庫與非關系型資料庫的區別，和各自的發展前景
當前主流的關系型資料庫有Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL等。
非關系型資料庫有 NoSql、Cloudant。
nosql和關系型資料庫比較
優點：
1）成本：nosql資料庫簡單易部署，基本都是開源軟體，不需要像使用oracle那樣花費大量成本購買使用，相比關系型資料庫價格便宜。
2）查詢速度：nosql資料庫將數據存儲於緩存之中，關系型資料庫將數據存儲在硬碟中，自然查詢速度遠不及nosql資料庫。
3）存儲數據的格式：nosql的存儲格式是key,value形式、文檔形式、圖片形式等等，所以可以存儲基礎類型以及對象或者是集合等各種格式，而資料庫則只支持基礎類型。
4）擴展性：關系型資料庫有類似join這樣的多表查詢機制的限制導致擴展很艱難。
缺點：
1）維護的工具和資料有限，因為nosql是屬於新的技術，不能和關系型資料庫10幾年的技術同日而語。
2）不提供對sql的支持，如果不支持sql這樣的工業標准，將產生一定用戶的學習和使用成本。
3）不提供關系型資料庫對事物的處理。
關系型資料庫的最大特點就是事務的一致性：傳統的關系型資料庫讀寫操作都是事務的，具有ACID的特點，這個特性使得關系型資料庫可以用於幾乎所有對一致性有要求的系統中，如典型的銀行系統。
關系型資料庫為了維護一致性所付出的巨大代價就是其讀寫性能比較差，而像微博、facebook這類SNS的應用，對並發讀寫能力要求極高，關系型資料庫已經無法應付(在讀方面，傳統上為了克服關系型資料庫缺陷，提高性能，都是增加一級memcache來靜態化網頁，而在SNS中，變化太快，memchache已經無能為力了)，因此，必須用新的一種數據結構存儲來代替關系資料庫。
關系資料庫的另一個特點就是其具有固定的表結構，因此，其擴展性極差，而在SNS中，系統的升級，功能的增加，往往意味著數據結構巨大變動，這一點關系型資料庫也難以應付，需要新的結構化數據存儲。
於是，非關系型資料庫應運而生，由於不可能用一種數據結構化存儲應付所有的新的需求，因此，非關系型資料庫嚴格上不是一種資料庫，應該是一種數據結構化存儲方法的集合。