簡介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
|
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). |
結論