如何選擇 SQL 與 NoSQL ? 詳細介紹與差異比較
SQL 與 NoSQL 超講解！不看會後悔
SQL 關聯式資料庫（RDBMS）
介紹
結構化查詢語言（Structured Query Language）簡稱SQL，是一種特定目的程式語言，用於管理關聯式資料庫管理系統（RDBMS），或在關係流資料管理系統（RDSMS）中進行流處理。
SQL 的範圍包括資料插入、查詢、更新和刪除，資料庫模式建立和修改，以及資料存取控制。
資料模型
關聯式模型將資料標準化，成為由列和欄組成的表格。結構描述嚴格定義表格、列、欄、索引、表格之間的關係，以及其他資料庫元素。此類資料庫強化資料庫表格間的參考完整性。
在關聯式資料庫中，資料存儲在 Table 中， Table 類似於 Excel 的表單，由欄和列組成的多個儲存格，Table 中有一個唯一的 key 來標識每一行數據。這些唯一的 key 可以用來將 Table 連接在一起。正是這種結構使我們能夠辨識和存取資料，建立起資料庫中其他區塊之間的關係。也正是這些關係，使得關聯式資料庫變得如此強大，並且在資料庫中提供資料的一致性。
SQL 資料庫使用結構化查詢語言並具有用於定義和操作資料的預定義模式。 SQL 是可用的最通用和廣泛使用的查詢語言之一，使其成為許多用例的安全選擇。 它非常適合複雜的查詢。 但是，SQL 可能過於嚴格。 您必須使用預定義的模式來確定您的資料結構，然後才能使用它。 您的所有資料都必須遵循相同的結構。 這個過程需要大量的前期準備。 如果你想改變你的資料結構，這對你的整個系統來說將是困難和破壞性的。
優點：
- 統一性：不同的角色使用相同的語言、不同的RDBMS使用統一標準的語言。
- 易用性：SQL使用一種高階的非結構化查詢語言。.
- 穩定性：它堅持 ACID 準則 (原子性，一致性，隔離性，永續性),，這些準則保證了資料庫尤其是每個事務的穩定性，安全性和可預測性。
NoSQL 非關聯式資料庫（Not Only SQL）
允許部分資料使用SQL系統儲存，而其他資料允許使用 NoSQL 系統儲存。其數據儲存可以不需要固定的表格模式以及元資料（metadata），也經常會避免使用 SQL 的 JOIN 操作，一般有水平可延伸性的特徵。
資料模型
NoSQL 資料庫提供鍵值、文件和圖形等多種資料模型，具有最佳化的效能與規模。
優點:
- 彈性：NoSQL 資料庫整體而言提供促進更快速及更能反覆開發的彈性結構描述。具彈性的資料模型讓 NoSQL 資料庫成為半結構和非結構式資料的理想資料庫。
- 可擴展性：NoSQL 資料庫一般的設計都能透過硬體的分散式叢集來向外擴展，而不必藉由增加昂貴和重量級的伺服器來進行垂直擴展。有些雲端供應商背後將這些操作處理成全受管服務。
- 高效能：NoSQL 資料庫針對特定資料模型加以優化，並且存取比使用關聯式資料庫達到相同功能的更高效能模式。
- 高功能性：NoSQL 資料庫提供專為各別資料模型而建造的高功能 API 和資料。
ACID 準則
ACID，是指資料庫管理系統（DBMS）在寫入或更新資料的過程中，為保證事務（transaction）是正確可靠的，所必須具備的四個特性：
- 原子性（atomicity，或稱不可分割性）
- 一致性（consistency）
- 隔離性（isolation，又稱獨立性）
- 持久性（durability）
關聯式資料庫提供 ACID 屬性，NoSQL 資料庫通常透過鬆綁部分關聯式資料庫的 ACID 屬性來取捨，以達到能夠橫向擴展的更彈性化資料模型。
原子性（Atomicity）：一個事務（transaction）中的所有操作，或者全部完成，或者全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。即，事務不可分割、不可約簡。
一致性（Consistency）：在事務開始之前和事務結束以後，資料庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設約束、觸發器、級聯回滾等。
事務隔離（Isolation）：資料庫允許多個並發事務同時對其數據進行讀寫和修改的能力，隔離性可以防止多個事務並發執行時由於交叉執行而導致數據的不一致。事務隔離分為不同級別，包括未提交讀（Read uncommitted）、提交讀（read committed）、可重複讀（repeatable read）和串行化（Serializable）。
持久性（Durability）：事務處理結束後，對數據的修改就是永久的，即便系統故障也不會丟失。
CAP 定理
CAP 定理對分散式系統套用類似邏輯，亦即分散式系統只能提供三種所需特性的其中兩個： 一致性、可用性 及分割區容錯。
一致性（Consistency）：一致性表示所有用戶端可在同時看到相同資料，無論它們連接哪一個節點。 為了達到如此，每當將資料寫入某個節點時，就必須立即將它轉遞或抄寫至系統當中的所有其他節點，這樣才能將視為「成功」寫入。
可用性（Availability）：可用性表示任何要求提供資料的用戶端都會獲得回應，即使一或多個節點關閉也無妨。 用另一種方式來說，分散式系統中的所有工作節點都會針對任何要求傳回有效回應，沒有任何例外。
分割區容錯（Partition tolerance）：分割區是分散式系統內部的通訊岔斷，即兩個節點之間的連線遺失或暫時延遲。 分割區容錯表示，儘管系統內部節點之間有一些通訊故障，叢集必須持續運作。
根據定理，分佈式系統只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想像兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致，即喪失了C性質。如果為了保證數據一致性，將分區一側的節點設置為不可用，那麼又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質。
NoSQL 資料庫是根據所支援的兩個 CAP 特性來做分類：
- CP 資料庫：CP 資料庫提供一致性和分割區容錯，但代價是可用性。 當任何兩個節點之間出現分割區時，系統必須關閉不一致的節點（即使其無法使用），直到解決分割區為止。
- AP 資料庫：AP 資料庫提供可用性和分割區容錯，但代價是一致性。 當出現分割區時，所有節點保持可用，但在分割區錯誤端的那些節點可能會傳回版本比其他節點還舊的資料。（在解決分割區後，AP 資料庫通常會重新同步節點，以修復系統當中的所有不一致。）
- CA 資料庫：CA 資料庫跨所有節點提供一致性和可用性。 不過，如果在系統中任何兩個節點之間出現分割區，它就無法完成任務，結果導致無法提供容錯。
SQL 和 NoSQL 的區別
以下是 NoSQL 和 SQL 之間的主要區別：
| 範圍 | SQL | NOSQL |
|---|---|---|
| 定義 | SQL 資料庫主要稱為 RDBMS 或關係資料庫 | NoSQL 資料庫主要被稱為非關聯或分佈式資料庫 |
| 設計為 | 傳統的 RDBMS 使用 SQL 語法和查詢來分析和獲取資料以獲得進一步的洞察力。它們用於 OLAP 系統。 | NoSQL 資料庫系統由各種資料庫技術組成。這些資料庫是為了響應現代應用程式開發的需求而開發的。 |
| 查詢語言 | 結構化查詢語言 (SQL) | 沒有聲明性查詢語言 |
| 類型 | SQL 資料庫是基於表的資料庫 | NoSQL 資料庫可以是基於文檔、鍵值對、圖形資料庫 |
| 架構 | SQL 資料庫具有預定義的架構 | NoSQL 資料庫對非結構化資料使用動態模式。 |
| 擴展能力 | SQL 資料庫可垂直擴展 | NoSQL 資料庫可水平擴展 |
| 範例 | Oracle、Postgres 和 MS-SQL。 | MongoDB、Redis、Neo4j、Cassandra、Hbase。 |
| 最適合 | 複雜查詢密集型環境的理想選擇。 | 它不適合複雜的查詢。 |
| 分層資料存儲 | SQL 資料庫不適合分層資料儲存。 | 更適合分層資料儲存，因為它支持鍵值對方法。 |
| 變化 | 一種有細微變化的類型。 | 許多不同的類型，包括鍵值儲存、文檔資料庫和圖形資料庫。 |
| 發展年份 | 它是在 1970 年代開發的，用於處理平面文件儲存的問題 | 在 2000 年代後期開發，以克服 SQL 資料庫的問題和限制。 |
| 開源 | 像 Postgres 和 MySQL 這樣的開源和像 Oracle 資料庫這樣的商業的混合。 | 開源 |
| 一致性 | 它應該配置為強一致性。 | 它依賴於 DBMS，因為有些提供強一致性，如 MongoDB，而另一些只提供最終一致性，如 Cassandra。 |
| 最適合用於 | RDBMS 資料庫是解決 ACID 問題的正確選擇。 | NoSQL 是解決資料可用性問題的最佳選擇 |
| 重要性 | 當資料有效性非常重要時應該使用它 | 當擁有快速資料比正確資料更重要時使用 |
| 最佳選擇 | 當您需要支持動態查詢時 | 當您需要根據不斷變化的需求進行擴展時使用 |
| 硬體 | 專用資料庫硬體（Oracle Exadata 等） | 一般硬體 |
| 網絡 | 高可用網絡（Infiniband、Fabric Path 等） | 一般網絡（以太網等） |
| 儲存類型 | 高可用儲存（SAN、RAID 等） | 一般驅動器儲存（標準HDD、JBOD） |
| 最好的功能 | 跨平台支持，安全免費 | 易於使用、高性能和靈活的工具。 |
| 大公司使用 | Hootsuite, CircleCI, Gauges | Airbnb, Uber, Kickstarter |
| ACID vs. BASE Model | ACID（原子性、一致性、隔離性和持久性）是 RDBMS 的標準 | Base（基本可用、軟狀態、最終一致）是許多 NoSQL 系統的模型 |
| 最佳工作負載 | 關聯式資料庫專門用於交易性以及高度一致性的線上交易處理 (OLTP) 應用程式，並且非常適合於線上分析處理 (OLAP) 使用。 | NoSQL 資料庫專門用於包含低延遲應用程式的多樣資料存取模式。NoSQL 搜尋資料庫專門用於進行半結構資料的分析。 |
| 資料模型 | 關聯式模型將資料標準化，成為由列和欄組成的表格。結構描述嚴格定義表格、列、欄、索引、表格之間的關係，以及其他資料庫元素。此類資料庫強化資料庫表格間的參考完整性。 | NoSQL 資料庫提供鍵值、文件和圖形等多種資料模型，具有最佳化的效能與規模。 |
| ACID 屬性 | 關聯式資料庫則提供單元性、一致性、隔離性和耐用性 (ACID) 的屬性：單元性要求交易完整執行或完全不執行。一致性要求進行交易時資料就必須符合資料庫結構描述。隔離性要求並行的交易必須分開執行。耐用性要求從意外的系統故障或停電狀況還原成上個已知狀態的能力。 | NoSQL 資料庫通常透過鬆綁部分關聯式資料庫的 ACID 屬性來取捨，以達到能夠橫向擴展的更彈性化資料模型。這使得 NoSQL 資料庫成為橫向擴展超過單執行個體上限的高吞吐量、低延遲使用案例的最佳選擇。 |
| 效能 | 一般而言，效能取決於磁碟子系統。若要達到頂級效能，通常必須針對查詢、索引及表格結構進行優化。 | 效能通常會受到基礎硬體叢集大小、網路延遲，以及呼叫應用程式的影響。 |
| 擴展 | 關聯式資料庫通常透過增加硬體運算能力向上擴展，或以新增唯讀工作負載複本的方式向外擴展。 | NoSQL 資料庫通常可分割，因為存取模式可透過使用分散式架構來向外擴展，以近乎無限規模的方式提供一致效能來增加資料吞吐量。 |
| API | 存放和擷取資料的請求是透過符合結構式查詢語言 (SQL) 的查詢進行通訊。這些查詢是由關聯式資料庫剖析和執行。 | 以物件為基礎的 API 讓應用程式開發人員可輕鬆存放和擷取資料結構。應用程式可透過分區索引鍵查詢鍵值組、欄集，或包含序列化應用程式物件與屬性的半結構化文件。 |
SQL 與NoSQL 術語的比較
以下表格比較特定 NoSQL 資料庫與 SQL 資料庫所用的術語。
| SQL | MongoDB | DynamoDB | Cassandra | Couchbase |
|---|---|---|---|---|
| 表 | 集合 | 表 | 表 | 資料儲存貯體 |
| 列 | 文件 | 項目 | 列 | 文件 |
| 欄 | 欄位 | 屬性 | 欄 | 欄位 |
| 主索引鍵 | 物件 ID | 主索引鍵 | 主索引鍵 | 文件 ID |
| 索引 | 索引 | 次要索引 | 索引 | 索引 |
| 檢視 | 檢視 | 全域次要索引 | 具體化檢視 | 檢視 |
| 巢狀表格或物件 | 內嵌文件 | 對應 | 對應 | 對應 |
| 陣列 | 陣列 | 清單 | 清單 | 清單 |
何時應該使用 SQL ?
- SQL 是用於與 RDBMS 溝通的最簡單的語言
- 分析行為相關和定制的會話
- 建立自定義儀表板
- 快速儲存和從資料庫中獲取數據
- 執行複雜查詢和報表
- 工作負載磁片區通常適用于每秒數千筆交易
- 資料具有高度結構化，而且需要參考完整性
- 關聯性是透過標準化資料模型的資料表聯結來表示
- 資料通常是集中式的，或可以非同步複寫區域
- 您的應用程式將會部署到大型的高階硬體
何時應該使用 NoSQL ?
- 當不需要 ACID 時，關聯性可以是反正規化的資料模型
- 當傳統 RDBMS 模型不夠用時
- 您的資料是動態且經常變更，需要架構靈活的資料
- 不需要在資料庫中實現約束和驗證邏輯
- 從分佈式源記錄數據，資料擷取很簡單，而且沒有資料表聯結表示
- 它應該用於儲存臨時數據，如購物車、願望清單和 Session 資料
- 您有大量工作負載需要大規模延遲 (例如以毫秒為單位測量的延遲，而每秒執行數百萬筆交易)
- 資料通常會跨地理位置複寫，而且需要更精細地控制一致性、可用性和效能
- 您的應用程式將會部署到商用硬體，例如使用公用雲端
參考資料
https://www.codegym.tech/blog/sql-vs-nosql
https://iter01.com/597887.html
https://aws.amazon.com/tw/nosql/
https://zh.wikipedia.org/wiki/SQL
https://zh.wikipedia.org/wiki/NoSQL
https://www.guru99.com/sql-vs-nosql.html
https://www.guru99.com/dbms-transaction-management.html
https://docs.microsoft.com/zh-tw/dotnet/architecture/cloud-native/relational-vs-nosql-data
https://www.ibm.com/tw-zh/cloud/learn/cap-theorem
https://aws.amazon.com/tw/nosql/