關係型數據庫管理系統(RDBMS)與非關係型數據庫(NoSQL)之間的區別

簡介sql

關係型數據庫管理系統(RDBMS)用來操做創建在關係模型基礎上的數據庫,主要表明有:Microsoft SQL Server,Oracle,MySQL(開源)。mongodb

非關係型數據庫(NoSQL),主要表明有:MongoDB,Redis。數據庫

 

ACID vs BASE緩存

ACID BASE
原子性(Atomicity) 基本可用(Basically Available)
一致性(Consistency) 軟狀態/柔性事務(Soft state)
隔離性(Isolation) 最終一致性 (Eventual consistency)
持久性 (Durable)  

 

ACID服務器

ACID是關係型數據庫強一致性(Strong consistency)的四個要求。網絡

(1) 原子性(Atomicity):事務裏的全部操做要麼全都執行完成,要麼全都不執行。只要有一個操做失敗,整個事務就失敗,事務會回滾至它們最初的狀態。數據結構

(2) 一致性(Consistency):數據庫要一直處於一致的狀態,事務的運行不會改變數據庫本來的一致性約束。架構

(3) 隔離性(Isolation):事務的執行不被其餘事務干擾。若是一個事務要訪問的數據正在被另一個事務修改,只要另一個事務未提交,它所訪問的數據就不受未提交事務的影響。併發

(4) 持久性(Durable):一旦事務提交後,它所作的修改將會永久的保存在數據庫上,即便出現系統故障也不會丟失。app

 

(注:事務(Transaction)是用戶定義的一個操做序列。)

 

BASE

BASE是基於CAP理論逐步演化而來的,核心思想是即使不能達到強一致性,可是能夠根據應用的特色採用適當的方式來達到最終一致性(Eventual consistency)

(1) 基本可用(Basically Available):分佈式系統在出現故障的時候,容許損失部分可用性,即保證核心功能或者當前最重要功能可用。

(2) 軟狀態/柔性事務(Soft-state):狀態能夠有一段時間的不一樣步。

(3) 最終一致性(Eventual consistency):當全部服務邏輯執行完成後,系統最後將回到一個一致的狀態。

 

ACID和BASE並無一個嚴格的界限,它們取決與組織和系統決定在哪裏和如何架構這個系統的場景。它們可能容許在某些關鍵領域採起嚴格的ACID事務,其餘領域標準稍微放鬆一些。

 

區別

1. 事務控制模型不一樣

RDBMS採用ACID模型,而不少NoSQL系統基本採用BASE模型。雖然有些NoSQL系統支持ACID,但只適用於單個條目。NoSQL不採用ACID的主要緣由是其可擴展性方面的限制,若是文檔橫跨幾個服務器,事務控制將會很難實施。

總的來講,RDBMS關注一致性,而NoSQL系統則關注可用性。BASE系統顯著的特色是要保證在短期內,即便有不一樣步的風險,也要容許新數據可以被存儲。BASE系統傾向於簡單和迅速,由於它們沒必要編寫處理鎖定和釋放資源的代碼,它們的任務是保證流程運轉並稍後處理出錯的部分。

 

2. 數據結構不一樣

第一,關係型數據庫一般是以表格形式(行列)存儲數據,而NoSQL系統有多種存儲方式,包括列存儲(Cassandra)、key/value存儲(Redis)、文檔存儲(MongoDB)以及圖存儲(Neo4j)等。

第二,若要在關係型數據庫中存儲數據,必須先定義好模式(schemas),也就是用一種預約義的結構向數據庫說明:要有哪些表格,表中有哪些列,每一列都存放何種類型的數據。相比之下,NoSQL數據庫的數據存儲就比較隨意了。鍵值數據庫能夠把任何數據存放在一個」鍵」的名下。文檔數據庫實際上也如此,它對所存儲的文檔結構沒有限制。

 

3. 可擴展性不一樣

第一,在關係型數據庫裏,增刪字段是一件很是麻煩的事情。好比若是想刪除某列,若是此列和其餘數據關聯,那麼就沒法輕易刪除。NoSQL由於數據之間無關係,所以很是容易擴展。一旦發現了新東西,只要把它們加入數據庫中就好。

第二,從架構的層面上講,RDBMS是垂直擴展,當RDBMS數據庫負載增長時,須要用更大更好的服務器來擴展數據庫(由於RDBMS須要支持join,union等操做,通常不支持分佈式集羣)。而NoSQL數據庫是橫向擴展,能夠自動對數據進行分片,並將分片存儲在分佈式系統(distributed system)上,這樣,就能夠經過增長更多的服務器來進行擴展。

 

4. 數據讀寫速度不一樣

當關系型數據庫的數據量達到必定規模時,因爲關係型數據庫的系統邏輯很是複雜,使得其很是容易發生死鎖等併發問題,致使其讀寫速度下滑很是嚴重。而NoSQL數據庫得益於它的數據庫結構很是簡單,且具備良好的集成緩存能力,讀寫性能很是好。

 

5. 成熟度不一樣

關係型數據庫使用SQL語言,各類數據庫之間的區別很是小。而NoSQL數據庫沒有統一的標準,其產品包括各類不一樣存儲類型的數據庫。 

 

6. 成本不一樣

第一,關係型數據庫軟件價格昂貴,而NoSQL數據庫基本都是開源軟件,不須要花費大量成本購買使用,相比關係型數據庫價格便宜。

第二,因爲ACID模型很是複雜,維持高端的RDBMS系統是很昂貴的,須要訓練有素的人管理數據庫。而NoSQL數據庫部署簡單,一般使用廉價的服務器,管理也較少。

 

如下再摘錄一份MongoDB官網上的資料:https://www.mongodb.com/nosql-explained

NoSQL vs. SQL Summary

 

SQL Databases

NoSQL Databases

Types

One type (SQL database) with minor variations

Many different types including key-value stores, document databases, wide-column stores, and graph databases

Development History

Developed in 1970s to deal with first wave of data storage applications

Developed in late 2000s to deal with limitations of SQL databases, especially scalability, multi-structured data, geo-distribution and agile development sprints

Examples

MySQL, Postgres, Microsoft SQL Server, Oracle Database

MongoDB, Cassandra, HBase, Neo4j

Data Storage Model

Individual records (e.g., 'employees') are stored as rows in tables, with each column storing a specific piece of data about that record (e.g., 'manager,' 'date hired,' etc.), much like a spreadsheet. Related data is stored in separate tables, and then joined together when more complex queries are executed. For example, 'offices' might be stored in one table, and 'employees' in another. When a user wants to find the work address of an employee, the database engine joins the 'employee' and 'office' tables together to get all the information necessary.

Varies based on database type. For example, key-value stores function similarly to SQL databases, but have only two columns ('key' and 'value'), with more complex information sometimes stored as BLOBs within the 'value' columns. Document databases do away with the table-and-row model altogether, storing all relevant data together in single 'document' in JSON, XML, or another format, which can nest values hierarchically.

Schemas

Structure and data types are fixed in advance. To store information about a new data item, the entire database must be altered, during which time the database must be taken offline.

Typically dynamic, with some enforcing data validation rules. Applications can add new fields on the fly, and unlike SQL table rows, dissimilar data can be stored together as necessary. For some databases (e.g., wide-column stores), it is somewhat more challenging to add new fields dynamically.

Scaling

Vertically, meaning a single server must be made increasingly powerful in order to deal with increased demand. It is possible to spread SQL databases over many servers, but significant additional engineering is generally required, and core relational features such as JOINs, referential integrity and transactions are typically lost.

Horizontally, meaning that to add capacity, a database administrator can simply add more commodity servers or cloud instances. The database automatically spreads data across servers as necessary.

Development Model

Mix of open-source (e.g., Postgres, MySQL) and closed source (e.g., Oracle Database)

Open-source

Supports multi-record ACID transactions

Yes

Mostly no. MongoDB 4.0 and beyond support multi-document ACID transactions. Learn more

Data Manipulation

Specific language using Select, Insert, and Update statements, e.g. SELECT fields FROM table WHERE…

Through object-oriented APIs

Consistency

Can be configured for strong consistency

Depends on product. Some provide strong consistency (e.g., MongoDB, with tunable consistency for reads) whereas others offer eventual consistency (e.g., Cassandra).

 

結論

傳統的關係型數據庫具備不錯的性能,穩定性好,久經歷史考驗,積累了大量的成功案例。而NoSQL數據庫的出現,則彌補了關係型數據庫在某些方面的不足,能極大地節省開發成本和維護成本。
 
二者都有各自的特色和應用場景,將由你的應用業務需求決定適合使用傳統的RDBMS仍是NoSQL系統。
 
對於金融業,可用性和性能都不是最重要的,而一致性是最重要的,用戶能夠容忍系統故障而中止服務,但毫不能容忍賬戶上的錢無端減小(固然,無端增長是能夠的),此外,金融業還要求全部報表必須始終保持一致性和可信性,所以RDBMS ACID系統是理想的選擇。
 
而對於購物網站,可用性是最重要的,若是用戶生成訂單,無論什麼狀況,咱們都不但願此信息受到阻塞。此外,用戶的我的信息,社交網絡,地理位置等用戶生成的數據呈幾何倍增加,若是要對這些用戶數據進行挖掘,那SQL數據庫已經不適合了, NoSQL數據庫卻能很好地處理這些大數據。
 
固然也能夠把關係型數據庫和NoSQL結合起來使用,各取所長,須要使用關係特性的時候就使用關係型數據庫,須要使用NoSQL特性的時候咱們使用NoSQL數據庫。好比用戶評論的存儲,評論大概有主鍵id、評論的對象aid、評論內容content、用戶uid等字段。咱們能肯定的是評論內容content確定不會在數據庫中用where content="..."查詢,評論內容也是一個大文本字段,那麼咱們能夠把主鍵id、評論對象aid、用戶uid存儲在關係型數據庫,評論內容存儲在NoSQL,這樣關係型數據庫就節省了存儲content佔用的磁盤空間,從而節省大量IO。
 
此外,還能夠把NoSQL做爲緩存服務器,把熱點數據進行內存cache,非熱點數據存儲到磁盤以節省內存佔用。
相關文章
相關標籤/搜索