一、關係型資料庫

    關係型資料庫，是指採用了關係模型來組織資料的資料庫。
    關係模型是在1970年由IBM的研究員E.F.Codd博士首先提出的，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成為主流資料庫結構的主流模型。
    簡單來說，關係模型指的就是二維表格模型，而一個關係型資料庫就是由二維表及其之間的聯絡所組成的一個數據組織。
關係模型中常用的概念：
    關係：可以理解為一張二維表，每個關係都具有一個關係名，就是通常說的表名
    元組：可以理解為二維表中的一行，在資料庫中經常被稱為記錄
    屬性：可以理解為二維表中的一列，在資料庫中經常被稱為欄位
    域：屬性的取值範圍，也就是資料庫中某一列的取值限制
    關鍵字：一組可以唯一標識元組的屬性，資料庫中常稱為主鍵，由一個或多個列組成
    關係模式：指對關係的描述。其格式為：關係名(屬性1，屬性2， ... ... ，屬性N)，在資料庫中成為表結構

關係型資料庫的優點：
    容易理解：二維表結構是非常貼近邏輯世界的一個概念，關係模型相對網狀、層次等其他模型來說更容易理解
    使用方便：通用的SQL語言使得操作關係型資料庫非常方便
    易於維護：豐富的完整性(實體完整性、參照完整性和使用者定義的完整性)大大減低了資料冗餘和資料不一致的概率

關係型資料庫瓶頸
  1).高併發讀寫需求
    網站的使用者併發性非常高，往往達到每秒上萬次讀寫請求，對於傳統關係型資料庫來說，硬碟I/O是一個很大的瓶頸
  2).海量資料的高效率讀寫
    網站每天產生的資料量是巨大的，對於關係型資料庫來說，在一張包含海量資料的表中查詢，效率是非常低的
  3).高擴充套件性和可用性
    在基於web的結構當中，資料庫是最難進行橫向擴充套件的，當一個應用系統的使用者量和訪問量與日俱增的時候，資料庫卻沒有辦法像web server和app server那樣簡單的通過新增更多的硬體和服務節點來擴充套件效能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行升級和擴充套件是非常痛苦的事情，往往需要停機維護和資料遷移。

對網站來說，關係型資料庫的很多特性不再需要了：
  事務一致性: 關係型資料庫在對事物一致性的維護中有很大的開銷，而現在很多web2.0系統對事物的讀寫一致性都不高
  讀寫實時性: 對關係資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出這條資料的，但是對於很多web應用來說，並不要求這麼高的實時性，比如發一條訊息之後，過幾秒乃至十幾秒之後才看到這條動態是完全可以接受的
  複雜SQL，特別是多表關聯查詢: 任何大資料量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析型別的複雜SQL報表查詢，特別是SNS型別的網站（SNS，專指社交網路服務，包括了社交軟體和社交網站。），從需求以及產品階級角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能極大的弱化了

    在關係型資料庫中，導致效能欠佳的最主要原因是多表的關聯查詢，以及複雜的資料分析型別的複雜SQL報表查詢。為了保證資料庫的ACID特性，我們必須儘量按照其要求的正規化進行設計，關係型資料庫中的表都是儲存一個格式化的資料結構。每個元組欄位的組成都是一樣，即使不是每個元組都需要所有的欄位，但資料庫會為每個元組分配所有的欄位，這樣的結構可以便於標語表之間進行連結等操作，但從另一個角度來說它也是關係型資料庫效能瓶頸的一個因素。

二、NoSQL

    NoSQL一詞首先是Carlo Strozzi在1998年提出來的，指的是他開發的一個沒有SQL功能，輕量級的，開源的關係型資料庫。這個定義跟我們現在對NoSQL的定義有很大的區別，它確確實實字如其名，指的就是“沒有SQL”的資料庫。但是NoSQL的發展慢慢偏離了初衷，我們要的不是“no sql”，而是“no relational”，也就是我們現在常說的非關係型資料庫了。
    2009年初，Johan Oskarsson舉辦了一場關於開源分散式資料庫的討論，Eric Evans在這次討論中再次提出了NoSQL一詞，用於指代那些非關係型的，分散式的，且一般不保證遵循ACID原則的資料儲存系統。Eric Evans使用NoSQL這個詞，並不是因為字面上的“沒有SQL”的意思，他只是覺得很多經典的關係型資料庫名字都叫“**SQL”,所以為了表示跟這些關係型資料庫在定位上的截然不同，就是用了“NoSQL“一詞。
注：資料庫事務必須具備ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation隔離性，Durability永續性。
    非關係型資料庫提出另一種理念，例如，以鍵值對儲存，且結構不固定，每一個元組可以有不一樣的欄位，每個元組可以根據需要增加一些自己的鍵值對，這樣就不會侷限於固定的結構，可以減少一些時間和空間的開銷。使用這種方式，使用者可以根據需要去新增自己需要的欄位，這樣，為了獲取使用者的不同資訊，不需要像關係型資料庫中，要對多表進行關聯查詢。僅需要根據id取出相應的value就可以完成查詢。但非關係型資料庫由於很少的約束，他也不能夠提供像SQL所提供的where這種對於欄位屬性值情況的查詢。並且難以體現設計的完整性。他只適合儲存一些較為簡單的資料，對於需要進行較複雜查詢的資料，SQL資料庫顯的更為合適。

2-1.非關係型資料庫分類
    由於非關係型資料庫本身天然的多樣性，以及出現的時間較短，因此，不想關係型資料庫，有幾種資料庫能夠一統江山，非關係型資料庫非常多，並且大部分都是開源的。
    這些資料庫中，其實實現大部分都比較簡單，除了一些共性外，很大一部分都是針對某些特定的應用需求出現的，因此，對於該類應用，具有極高的效能。依據結構化方法以及應用場合的不同，主要分為以下幾類：
    1).面向高效能併發讀寫的key-value資料庫：key-value資料庫的主要特點即使具有極高的併發讀寫效能，Redis,Tokyo Cabinet,Flare就是這類的代表
    2).面向海量資料訪問的面向文件資料庫：這類資料庫的特點是，可以在海量的資料中快速的查詢資料，典型代表為MongoDB以及CouchDB
    3).面向可擴充套件性的分散式資料庫：這類資料庫想解決的問題就是傳統資料庫存在可擴充套件性上的缺陷，這類資料庫可以適應資料量的增加以及資料結構的變化

三. 關係型資料庫  V.S.  非關係型資料庫

    關係型資料庫的最大特點就是事務的一致性：傳統的關係型資料庫讀寫操作都是事務的，具有ACID的特點，這個特性使得關係型資料庫可以用於幾乎所有對一致性有要求的系統中，如典型的銀行系統。
    但是，在網頁應用中，尤其是SNS應用中，一致性卻不是顯得那麼重要，使用者A看到的內容和使用者B看到同一使用者C內容更新不一致是可以容忍的，或者說，兩個人看到同一好友的資料更新的時間差那麼幾秒是可以容忍的，因此，關係型資料庫的最大特點在這裡已經無用武之地，起碼不是那麼重要了。
    相反地，關係型資料庫為了維護一致性所付出的巨大代價就是其讀寫效能比較差，而像微博、facebook這類SNS的應用，對併發讀寫能力要求極高，關係型資料庫已經無法應付(在讀方面，傳統上為了克服關係型資料庫缺陷，提高效能，都是增加一級memcache來靜態化網頁，而在SNS中，變化太快，memchache已經無能為力了)，因此，必須用新的一種資料結構儲存來代替關係資料庫。
    關係資料庫的另一個特點就是其具有固定的表結構，因此，其擴充套件性極差，而在SNS中，系統的升級，功能的增加，往往意味著資料結構巨大變動，這一點關係型資料庫也難以應付，需要新的結構化資料儲存。
    於是，非關係型資料庫應運而生，由於不可能用一種資料結構化儲存應付所有的新的需求，因此，非關係型資料庫嚴格上不是一種資料庫，應該是一種資料結構化儲存方法的集合。

    必須強調的是，資料的持久儲存，尤其是海量資料的持久儲存，還是需要一種關係資料庫這員老將。

---------------------------------------------------------------------------------------------------------------------------------------------

oracle與mysql的區別

一、併發性
  併發性是資料庫最重要的特性，但併發涉及到資源的獲取、共享與鎖定。
    mysql：mysql以表級鎖為主，對資源鎖定的粒度很大，如果一個session對一個表加鎖時間過長，會讓其他session無法更新此表中的資料。雖然InnoDB引擎的表可以用行級鎖，但這個行級鎖的機制依賴於表的索引，如果表沒有索引，或者sql語句沒有使用索引，那麼仍然使用表級鎖。
    oracle：oracle使用行級鎖，對資源鎖定的粒度要小很多，只是鎖定sql需要的資源，並且加鎖是在資料庫中的資料行上，不依賴與索引。所以oracle對併發性的支援要好很多。

二、一致性
    oracle：oracle支援serializable的隔離級別，可以實現最高級別的讀一致性。每個session提交後其他session才能看到提交的更改。oracle通過在undo表空間中構造多版本資料塊來實現讀一致性，每個session查詢時，如果對應的資料塊發生變化，oracle會在undo表空間中為這個session構造它查詢時的舊的資料塊。
    mysql：mysql沒有類似oracle的構造多版本資料塊的機制，只支援read commited的隔離級別。一個session讀取資料時，其他session不能更改資料，但可以在表最後插入資料。session更新資料時，要加上排它鎖，其他session無法訪問資料。

三、事務
    oracle很早就完全支援事務。
    mysql在innodb儲存引擎的行級鎖的情況下才支援事務。

四、資料永續性
    oracle：保證提交的資料均可恢復，因為oracle把提交的sql操作線寫入了線上聯機日誌檔案中，保持到了磁碟上，如果出現數據庫或主機異常重啟，重啟後oracle可以考聯機線上日誌恢復客戶提交的資料。
    mysql：預設提交sql語句，但如果更新過程中出現db或主機重啟的問題，也許會丟失資料。

五、提交方式
    oracle預設不自動提交，需要使用者手動提交。
    mysql預設是自動提交。

六、邏輯備份
    oracle邏輯備份時不鎖定資料，且備份的資料是一致的。
    mysql邏輯備份時要鎖定資料，才能保證備份的資料是一致的，影響業務正常的dml使用。

七、熱備份
    oracle有成熟的熱備工具rman，熱備時，不影響使用者使用資料庫。即使備份的資料庫不一致，也可以在恢復時通過歸檔日誌和聯機重做日誌進行一致的回覆。
    mysql：myisam的引擎，用mysql自帶的mysqlhostcopy熱備時，需要給表加讀鎖，影響dml操作。innodb的引擎，它會備份innodb的表和索引，但是不會備份.frm檔案。用ibbackup備份時，會有一個日誌檔案記錄備份期間的資料變化，因此可以不用鎖表，不影響其他使用者使用資料庫。但此工具是收費的。innobackup是結合ibbackup使用的一個指令碼，他會協助對.frm檔案的備份。

八、sql語句的擴充套件和靈活性
    mysql對sql語句有很多非常實用而方便的擴充套件，比如limit功能，insert可以一次插入多行資料，select某些管理資料可以不加from。
    oracle在這方面感覺更加穩重傳統一些。

九、複製
    oracle：既有推或拉式的傳統資料複製，也有dataguard的雙機或多機容災機制，主庫出現問題是，可以自動切換備庫到主庫，但配置管理較複雜。
    mysql：複製伺服器配置簡單，但主庫出問題時，叢庫有可能丟失一定的資料。且需要手工切換叢庫到主庫。

十、效能診斷
    oracle有各種成熟的效能診斷調優工具，能實現很多自動分析、診斷功能。比如awr、addm、sqltrace、tkproof等
    mysql的診斷調優方法較少，主要有慢查詢日誌。

十一、許可權與安全
    mysql的使用者與主機有關，感覺沒有什麼意義，另外更容易被仿冒主機及ip有可乘之機。
    oracle的許可權與安全概念比較傳統，中規中矩。

十二、分割槽表和分割槽索引
    oracle的分割槽表和分割槽索引功能很成熟，可以提高使用者訪問db的體驗。
    mysql的分割槽表還不太成熟穩定。

十三、管理工具
    oracle有多種成熟的命令列、圖形介面、web管理工具，還有很多第三方的管理工具，管理極其方便高效。
    mysql管理工具較少，在linux下的管理工具的安裝有時要安裝額外的包（phpmyadmin, etc)，有一定複雜性。

參考：http://blog.sina.com.cn/s/blog_61e034d50100k6xn.html