一廉嚼、關系型數據庫
關系型數據庫再扭，是指采用了關系模型來組織數據的數據庫燕酷。
關系模型是在1970年由IBM的研究員E.F.Codd博士首先提出的，在之后的幾十年中，關系模型的概念得到了充分的發(fā)展并逐漸成為主流數據庫結構的主流模型惭缰。
簡單來說拦焚，關系模型指的就是二維表格模型围辙，而一個關系型數據庫就是由二維表及其之間的聯系所組成的一個數據組織股冗。關系模型中常用的概念： 關系：可以理解為一張二維表，每個關系都具有一個關系名憋槐，就是通常說的表名 元組：可以理解為二維表中的一行双藕，在數據庫中經常被稱為記錄 屬性：可以理解為二維表中的一列，在數據庫中經常被稱為字段 域：屬性的取值范圍阳仔，也就是數據庫中某一列的取值限制 關鍵字：一組可以唯一標識元組的屬性忧陪，數據庫中常稱為主鍵，由一個或多個列組成 關系模式：指對關系的描述近范。其格式為：關系名(屬性1嘶摊，屬性2， ... ... 评矩，屬性N)更卒，在數據庫中成為表結構關系型數據庫的優(yōu)點：
容易理解：二維表結構是非常貼近邏輯世界的一個概念，關系模型相對網狀稚照、層次等其他模型來說更容易理解
使用方便：通用的SQL語言使得操作關系型數據庫非常方便
易于維護：豐富的完整性(實體完整性、參照完整性和用戶定義的完整性)大大減低了數據冗余和數據不一致的概率**關系型數據庫瓶頸

1).高并發(fā)讀寫需求 網站的用戶并發(fā)性非常高俯萌，往往達到每秒上萬次讀寫請求果录，對于傳統(tǒng)關系型數據庫來說，硬盤I/O是一個很大的瓶頸
2).海量數據的高效率讀寫 網站每天產生的數據量是巨大的咐熙，對于關系型數據庫來說弱恒，在一張包含海量數據的表中查詢，效率是非常低的
3).高擴展性和可用性 在基于web的結構當中棋恼，數據庫是最難進行橫向擴展的返弹，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力爪飘。對于很多需要提供24小時不間斷服務的網站來說义起，對數據庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移师崎。對網站來說默终，關系型數據庫的很多特性不再需要了：
事務一致性: 關系型數據庫在對事物一致性的維護中有很大的開銷，而現在很多web2.0系統(tǒng)對事物的讀寫一致性都不高
讀寫實時性: 對關系數據庫來說，插入一條數據之后立刻查詢齐蔽，是肯定可以讀出這條數據的两疚，但是對于很多web應用來說，并不要求這么高的實時性含滴，比如發(fā)一條消息之后诱渤，過幾秒乃至十幾秒之后才看到這條動態(tài)是完全可以接受的
復雜SQL，特別是多表關聯查詢: 任何大數據量的web系統(tǒng)谈况，都非常忌諱多個大表的關聯查詢勺美，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站（SNS鸦做，專指社交網絡服務励烦，包括了社交軟件和社交網站。）泼诱，從需求以及產品階級角度坛掠，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢治筒，以及單表的簡單條件分頁查詢屉栓，SQL的功能極大的弱化了 在關系型數據庫中，導致性能欠佳的最主要原因是多表的關聯查詢耸袜，以及復雜的數據分析類型的復雜SQL報表查詢友多。為了保證數據庫的ACID特性，我們必須盡量按照其要求的范式進行設計堤框，關系型數據庫中的表都是存儲一個格式化的數據結構域滥。每個元組字段的組成都是一樣，即使不是每個元組都需要所有的字段蜈抓，但數據庫會為每個元組分配所有的字段启绰，這樣的結構可以便于標語表之間進行鏈接等操作，但從另一個角度來說它也是關系型數據庫性能瓶頸的一個因素沟使。
二委可、NoSQL
NoSQL一詞首先是Carlo Strozzi在1998年提出來的，指的是他開發(fā)的一個沒有SQL功能腊嗡，輕量級的着倾，開源的關系型數據庫。這個定義跟我們現在對NoSQL的定義有很大的區(qū)別燕少，它確確實實字如其名卡者，指的就是“沒有SQL”的數據庫。但是NoSQL的發(fā)展慢慢偏離了初衷客们，我們要的不是“no sql”虎眨，而是“no relational”蟋软，也就是我們現在常說的非關系型數據庫了。 2009年初嗽桩，Johan Oskarsson舉辦了一場關于開源分布式數據庫的討論岳守，Eric Evans在這次討論中再次提出了NoSQL一詞，用于指代那些非關系型的碌冶，分布式的湿痢，且一般不保證遵循ACID原則的數據存儲系統(tǒng)。Eric Evans使用NoSQL這個詞扑庞，并不是因為字面上的“沒有SQL”的意思譬重，他只是覺得很多經典的關系型數據庫名字都叫“**SQL”,所以為了表示跟這些關系型數據庫在定位上的截然不同，就是用了“NoSQL“一詞罐氨。注：數據庫事務必須具備ACID特性臀规，ACID是Atomic原子性，Consistency一致性栅隐，Isolation隔離性塔嬉，Durability持久性。
非關系型數據庫提出另一種理念租悄，例如谨究，以鍵值對存儲，且結構不固定泣棋，每一個元組可以有不一樣的字段胶哲，每個元組可以根據需要增加一些自己的鍵值對，這樣就不會局限于固定的結構潭辈，可以減少一些時間和空間的開銷鸯屿。使用這種方式，用戶可以根據需要去添加自己需要的字段把敢，這樣碾盟，為了獲取用戶的不同信息，不需要像關系型數據庫中技竟，要對多表進行關聯查詢屈藐。僅需要根據id取出相應的value就可以完成查詢榔组。但非關系型數據庫由于很少的約束，他也不能夠提供像SQL所提供的where這種對于字段屬性值情況的查詢搓扯。并且難以體現設計的完整性包归。他只適合存儲一些較為簡單的數據椎椰，對于需要進行較復雜查詢的數據沾鳄，SQL數據庫顯的更為合適慨飘。
2-1.非關系型數據庫分類
由于非關系型數據庫本身天然的多樣性瓤的，以及出現的時間較短，因此吞歼，不想關系型數據庫圈膏，有幾種數據庫能夠一統(tǒng)江山，非關系型數據庫非常多篙骡，并且大部分都是開源的稽坤。
這些數據庫中，其實實現大部分都比較簡單医增，除了一些共性外慎皱，很大一部分都是針對某些特定的應用需求出現的，因此叶骨，對于該類應用茫多，具有極高的性能。依據結構化方法以及應用場合的不同忽刽，主要分為以下幾類：
1).面向高性能并發(fā)讀寫的key-value數據庫：key-value數據庫的主要特點即使具有極高的并發(fā)讀寫性能天揖，Redis,Tokyo Cabinet,Flare就是這類的代表
2).面向海量數據訪問的面向文檔數據庫：這類數據庫的特點是，可以在海量的數據中快速的查詢數據跪帝，典型代表為MongoDB以及CouchDB
3).面向可擴展性的分布式數據庫：這類數據庫想解決的問題就是傳統(tǒng)數據庫存在可擴展性上的缺陷今膊，這類數據庫可以適應數據量的增加以及數據結構的變化
三. 關系型數據庫 V.S. 非關系型數據庫
關系型數據庫的最大特點就是事務的一致性：傳統(tǒng)的關系型數據庫讀寫操作都是事務的，具有ACID的特點伞剑，這個特性使得關系型數據庫可以用于幾乎所有對一致性有要求的系統(tǒng)中斑唬，如典型的銀行系統(tǒng)。
但是黎泣，在網頁應用中恕刘，尤其是SNS應用中，一致性卻不是顯得那么重要抒倚，用戶A看到的內容和用戶B看到同一用戶C內容更新不一致是可以容忍的褐着，或者說，兩個人看到同一好友的數據更新的時間差那么幾秒是可以容忍的托呕，因此含蓉，關系型數據庫的最大特點在這里已經無用武之地频敛，起碼不是那么重要了。
相反地馅扣，關系型數據庫為了維護一致性所付出的巨大代價就是其讀寫性能比較差斟赚，而像微博、facebook這類SNS的應用岂嗓，對并發(fā)讀寫能力要求極高汁展，關系型數據庫已經無法應付(在讀方面，傳統(tǒng)上為了克服關系型數據庫缺陷厌殉，提高性能食绿，都是增加一級memcache來靜態(tài)化網頁，而在SNS中公罕，變化太快器紧，memchache已經無能為力了)，因此楼眷，必須用新的一種數據結構存儲來代替關系數據庫铲汪。
關系數據庫的另一個特點就是其具有固定的表結構，因此罐柳，其擴展性極差掌腰，而在SNS中，系統(tǒng)的升級张吉，功能的增加齿梁，往往意味著數據結構巨大變動，這一點關系型數據庫也難以應付肮蛹，需要新的結構化數據存儲勺择。
于是，非關系型數據庫應運而生伦忠，由于不可能用一種數據結構化存儲應付所有的新的需求省核，因此，非關系型數據庫嚴格上不是一種數據庫昆码，應該是一種數據結構化存儲方法的集合气忠。
必須強調的是，數據的持久存儲赋咽，尤其是海量數據的持久存儲旧噪，還是需要一種關系數據庫這員老將。

oracle與mysql的區(qū)別

一冬耿、并發(fā)性
并發(fā)性是數據庫最重要的特性，但并發(fā)涉及到資源的獲取萌壳、共享與鎖定亦镶。
MySQL：mysql以表級鎖為主日月，對資源鎖定的粒度很大，如果一個session對一個表加鎖時間過長缤骨，會讓其他session無法更新此表中的數據爱咬。雖然InnoDB引擎的表可以用行級鎖，但這個行級鎖的機制依賴于表的索引绊起，如果表沒有索引精拟，或者sql語句沒有使用索引，那么仍然使用表級鎖虱歪。
Oracle：oracle使用行級鎖蜂绎，對資源鎖定的粒度要小很多，只是鎖定sql需要的資源笋鄙，并且加鎖是在數據庫中的數據行上师枣，不依賴與索引。所以oracle對并發(fā)性的支持要好很多萧落。
二践美、一致性
oracle：oracle支持serializable的隔離級別，可以實現最高級別的讀一致性找岖。每個session提交后其他session才能看到提交的更改陨倡。oracle通過在undo表空間中構造多版本數據塊來實現讀一致性，每個session查詢時许布，如果對應的數據塊發(fā)生變化兴革，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邏輯備份時要鎖定數據，才能保證備份的數據是一致的曲管，影響業(yè)務正常的dml使用却邓。
七、熱備份
oracle有成熟的熱備工具rman院水，熱備時腊徙，不影響用戶使用數據庫。即使備份的數據庫不一致檬某，也可以在恢復時通過歸檔日志和聯機重做日志進行一致的回復撬腾。
mysql：myisam的引擎，用mysql自帶的mysqlhostcopy熱備時恢恼，需要給表加讀鎖民傻，影響dml操作。innodb的引擎场斑，它會備份innodb的表和索引漓踢，但是不會備份.frm文件。用ibbackup備份時漏隐，會有一個日志文件記錄備份期間的數據變化喧半，因此可以不用鎖表，不影響其他用戶使用數據庫青责。但此工具是收費的挺据。innobackup是結合ibbackup使用的一個腳本，他會協助對.frm文件的備份脖隶。
八扁耐、sql語句的擴展和靈活性
mysql對sql語句有很多非常實用而方便的擴展，比如limit功能产阱，insert可以一次插入多行數據婉称，select某些管理數據可以不加from。
oracle在這方面感覺更加穩(wěn)重傳統(tǒng)一些。
九王暗、復制
oracle：既有推或拉式的傳統(tǒng)數據復制榨乎，也有dataguard的雙機或多機容災機制，主庫出現問題是瘫筐，可以自動切換備庫到主庫，但配置管理較復雜铐姚。
mysql：復制服務器配置簡單策肝，但主庫出問題時，叢庫有可能丟失一定的數據隐绵。且需要手工切換叢庫到主庫之众。
十、性能診斷
oracle有各種成熟的性能診斷調優(yōu)工具依许，能實現很多自動分析棺禾、診斷功能。比如awr峭跳、addm膘婶、sqltrace、tkproof等
mysql的診斷調優(yōu)方法較少蛀醉，主要有慢查詢日志悬襟。
十一、權限與安全
mysql的用戶與主機有關拯刁，感覺沒有什么意義脊岳，另外更容易被仿冒主機及ip有可乘之機。 oracle的權限與安全概念比較傳統(tǒng)垛玻，中規(guī)中矩割捅。十二、分區(qū)表和分區(qū)索引
oracle的分區(qū)表和分區(qū)索引功能很成熟帚桩，可以提高用戶訪問db的體驗亿驾。
mysql的分區(qū)表還不太成熟穩(wěn)定。
十三朗儒、管理工具
oracle有多種成熟的命令行颊乘、圖形界面、web管理工具醉锄，還有很多第三方的管理工具乏悄，管理極其方便高效。
mysql管理工具較少恳不，在Linux下的管理工具的安裝有時要安裝額外的包（phpmyadmin, etc)檩小，有一定復雜性。

轉自http://blog.csdn.net/ochangwen/article/details/53423301 感謝烟勋！