關係型數據庫，是指採用了關係模型來組織數據的數據庫。
關係模型是在1970年由IBM的研究員E.F.Codd博士首先提出的，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成爲主流數據庫結構的主流模型。
簡單來說，關係模型指的就是二維表格模型，而一個關係型數據庫就是由二維表及其之間的聯繫所組成的一個數據組織。
關係模型中常用的概念：
關係：可以理解爲一張二維表，每個關係都具有一個關係名，就是通常說的表名
元組：可以理解爲二維表中的一行，在數據庫中經常被稱爲記錄
屬性：可以理解爲二維表中的一列，在數據庫中經常被稱爲字段
域：屬性的取值範圍，也就是數據庫中某一列的取值限制
關鍵字：一組可以唯一標識元組的屬性，數據庫中常稱爲主鍵，由一個或多個列組成
關係模式：指對關係的描述。其格式爲：關係名(屬性1，屬性2， ... ... ，屬性N)，在數據庫中成爲表結構
關係型數據庫的優點：
容易理解：二維表結構是非常貼近邏輯世界的一個概念，關係模型相對網狀、層次等其他模型來說更容易理解
使用方便：通用的SQL語言使得操作關係型數據庫非常方便
易於維護：豐富的完整性(實體完整性、參照完整性和用戶定義的完整性)大大減低了數據冗餘和數據不一致的概率
2. 關係型數據庫瓶頸
高併發讀寫需求
網站的用戶併發性非常高，往往達到每秒上萬次讀寫請求，對於傳統關係型數據庫來說，硬盤I/O是一個很大的瓶頸
海量數據的高效率讀寫
網站每天產生的數據量是巨大的，對於關係型數據庫來說，在一張包含海量數據的表中查詢，效率是非常低的
高擴展性和可用性
在基於web的結構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移。
對網站來說，關係型數據庫的很多特性不再需要了：
事務一致性
關係型數據庫在對事物一致性的維護中有很大的開銷，而現在很多web2.0系統對事物的讀寫一致性都不高
讀寫實時性
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比如發一條消息之後，過幾秒乃至十幾秒之後纔看到這條動態是完全可以接受的
複雜SQL，特別是多表關聯查詢
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品階級角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能極大的弱化了
在關係型數據庫中，導致性能欠佳的最主要原因是多表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢。爲了保證數據庫的ACID特性，我們必須儘量按照其要求的範式進行設計，關係型數據庫中的表都是存儲一個格式化的數據結構。每個元組字段的組成都是一樣，即使不是每個元組都需要所有的字段，但數據庫會爲每個元組分配所有的字段，這樣的結構可以便於標語表之間進行鏈接等操作，但從另一個角度來說它也是關係型數據庫性能瓶頸的一個因素。
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數據庫顯的更爲合適。
4. 關係型數據庫 V.S. 非關係型數據庫
關係型數據庫的最大特點就是事務的一致性：傳統的關係型數據庫讀寫操作都是事務的，具有ACID的特點，這個特性使得關係型數據庫可以用於幾乎所有對一致性有要求的系統中，如典型的銀行系統。
但是，在網頁應用中，尤其是SNS應用中，一致性卻不是顯得那麼重要，用戶A看到的內容和用戶B看到同一用戶C內容更新不一致是可以容忍的，或者說，兩個人看到同一好友的數據更新的時間差那麼幾秒是可以容忍的，因此，關係型數據庫的最大特點在這裏已經無用武之地，起碼不是那麼重要了。
相反地，關係型數據庫爲了維護一致性所付出的巨大代價就是其讀寫性能比較差，而像微博、facebook這類SNS的應用，對併發讀寫能力要求極高，關係型數據庫已經無法應付(在讀方面，傳統上爲了克服關係型數據庫缺陷，提高性能，都是增加一級memcache來靜態化網頁，而在SNS中，變化太快，memchache已經無能爲力了)，因此，必須用新的一種數據結構存儲來代替關係數據庫。
關係數據庫的另一個特點就是其具有固定的表結構，因此，其擴展性極差，而在SNS中，系統的升級，功能的增加，往往意味着數據結構巨大變動，這一點關係型數據庫也難以應付，需要新的結構化數據存儲。
於是，非關係型數據庫應運而生，由於不可能用一種數據結構化存儲應付所有的新的需求，因此，非關係型數據庫嚴格上不是一種數據庫，應該是一種數據結構化存儲方法的集合。
必須強調的是，數據的持久存儲，尤其是海量數據的持久存儲，還是需要一種關係數據庫這員老將。
5. 非關係型數據庫分類
由於非關係型數據庫本身天然的多樣性，以及出現的時間較短，因此，不想關係型數據庫，有幾種數據庫能夠一統江山，非關係型數據庫非常多，並且大部分都是開源的。
這些數據庫中，其實實現大部分都比較簡單，除了一些共性外，很大一部分都是針對某些特定的應用需求出現的，因此，對於該類應用，具有極高的性能。依據結構化方法以及應用場合的不同，主要分爲以下幾類：
面向高性能併發讀寫的key-value數據庫：
key-value數據庫的主要特點即使具有極高的併發讀寫性能，Redis,Tokyo Cabinet,Flare就是這類的代表
面向海量數據訪問的面向文檔數據庫：
這類數據庫的特點是，可以在海量的數據中快速的查詢數據，典型代表爲MongoDB以及CouchDB
面向可擴展性的分佈式數據庫：
這類數據庫想解決的問題就是傳統數據庫存在可擴展性上的缺陷，這類數據庫可以適應數據量的增加以及數據結構的變化