數據庫系關系數據庫?簡單來說區别在于數據庫軟件是否負責維護數據間的關系，今天小編就來聊一聊關于數據庫系關系數據庫?接下來我們就一起去研究一下吧!

數據庫系關系數據庫

簡單來說區别在于數據庫軟件是否負責維護數據間的關系。

關系型數據庫是依照實體-關系模型建立起來的，它包括兩個部分：一是數據庫部分，負責數據的保存和索引，讓你完成增删改查操作；另一個是關系部分，利用數據表把數據按行的形式組織起來，檢查每個字段的數據類型、長度甚至取值範圍，利用外鍵約束數據表之間的關系，利用事務機制确保數據庫操作的 ACID 特性。

非關系型數據庫全部或者部分放棄了實體-關系模型，它們隻負責保存數據，并不組織數據表，也不約束表間關系，關系的部分交由開發人員自己來完成。比如 mongodb 用 JSON 序列化的方式保存數據，雖然也有表的概念，但是結構可以随時擴展調整，而無需更新既有數據。比如 LevelDB 是一個 Key-Value 數據庫，重視寫入性能而非讀取性能。 Redis 提供了 Key-Value 、 List 、 Set 、 Sorted Set 等多種數據結構模型。 Cassandra 則使用面向列的數據模型。

關系型數據庫設計之初是為了給國防、金融、政府及企業管理使用，對數據一緻性要求極高，再加上當年存儲成本高昂，業界努力的方向也是确保事務安全和減少數據冗餘。實體-關系模型提供了簡單易學、健壯可靠，相對通用的軟件數據建模方法，自然成為各種數據庫軟件的基礎模型。非關系型數據庫早就存在，但是因為缺乏必要的數據一緻性保障而未能流行。直到 SNS 時代，社交網絡應用對數據的一緻性要求相對較低，對數據處理的實時性要求和大并發處理能力方面的要求非常高。通過放棄一緻性檢查和事務機制，非關系型數據庫一般比關系型數據庫擁有更好的性能，而且也不局限于實體-關系模型，能有更靈活的數據模型和操作方式供開發人員使用。

未來的趨勢是兩者結合， PostgreSQL 作為老牌的 RDBMS 開始提供 JSON 等更靈活的數據字段， Redis 等典型的 NOSQL 系統也開始提供 atom 操作接口。

不存在哪種數據庫更好，請按自己的實際業務場景結合起來使用。

把數據庫想象成一個箱子。你往 Oracle 型箱子放東西前必須用盒子裝起來（盒子即是表），而且規定了一個盒子裡隻能放規格一緻的東西（表中的記錄都擁有相同的字段）。你往 MongoDB 型箱子放東西時就沒那麼多限制了，隻管放就行了，怕太亂就也用盒子裝起來（盒子即是集合），但沒有規格一緻的限制（集合中的記錄可以有不同的字段）。

簡單來講就是範式化與非範式化。

1.實質。

非關系型數據庫的實質：非關系型數據庫産品是傳統關系型數據庫的功能閹割版本，通過減少用不到或很少用的功能，來大幅度提高産品性能。

2.價格。

目前基本上大部分主流的非關系型數據庫都是免費的。而比較有名氣的關系型數據庫，比如Oracle、DB2、MSSQL是收費的。雖然Mysql免費，但它需要做很多工作才能正式用于生産。

3.功能。

實際開發中，有很多業務需求，其實并不需要完整的關系型數據庫功能，非關系型數據庫的功能就足夠使用了。這種情況下，使用性能更高、成本更低的非關系型數據庫當然是更明智的選擇。

非關系型數據庫的優勢：

1. 性能

NOSQL是基于鍵值對的，可以想象成表中的主鍵和值的對應關系，而且不需要經過SQL層的解析，所以性能非常高。

2. 可擴展性

同樣也是因為基于鍵值對，數據之間沒有耦合性，所以非常容易水平擴展。

關系型數據庫的優勢：

1. 複雜查詢

可以用SQL語句方便的在一個表以及多個表之間做非常複雜的數據查詢。

2. 事務支持

使得對于安全性能很高的數據訪問要求得以實現。

對于這兩類數據庫，對方的優勢就是自己的弱勢，反之亦然。

但是近年來這兩種數據庫都在向着另外一個方向進化。例如：

NOSQL數據庫慢慢開始具備SQL數據庫的一些複雜查詢功能的雛形，比如Couchbase的index以及MONGO的複雜查詢。對于事務的支持也可以用一些系統級的原子操作來實現例如樂觀鎖之類的方法來曲線救國。

SQL數據庫也開始慢慢進化，比如HandlerSocker技術的實現，可以在MYSQL上實現對于SQL層的穿透，用NOSQL的方式訪問數據庫，性能可以上可以達到甚至超越NOSQL數據庫。可擴展性上例如Percona Server，可以實現無中心化的集群。

雖然這兩極都因為各自的弱勢而開始進化出另一極的一些特性，但是這些特性的增加也會消弱其本來具備的優勢，比如Couchbase上的index的增加會逐步降低數據庫的讀寫性能。所以怎樣構建系統的短期和長期存儲策略，用好他們各自的強項是架構師需要好好考慮的重要問題。

參考前文：Mysql和MongoDB性能對比及應用場景分析

,