NoSQL 與 SQL：內(nèi)容、地點和方式
作為初學者，了解兩種最常用的數(shù)據(jù)庫類型是必不可少的：SQL和NoSQL。在本文中，我已盡力提供一個全面的指南，幫助初學者了解 SQL 和 NoSQL 之間的區(qū)別、它們的用例以及它們比另一個表現(xiàn)更好的場景。此處的信息將為您提供 SQL 和 NoSQL 數(shù)據(jù)庫的概述，并重點介紹每種數(shù)據(jù)庫的優(yōu)缺點。到本文結束時，您將能夠就為您的項目使用哪種類型的數(shù)據(jù)庫做出明智的決定。無論您是軟件開發(fā)人員、數(shù)據(jù)分析師，還是希望存儲和管理數(shù)據(jù)的企業(yè)主，此信息都對您很有價值且相關。
那么，讓我們深入探索 SQL 和 NoSQL 數(shù)據(jù)庫的世界。
關于 SQL 和 NoSQL 的事實
- SQL 最初是由Donald D. Chamberlin和Raymond F. Boyce在IBM于 1970 年代初從Edgar F. Codd那里學習關系模型后開發(fā)的。
- NoSQL一詞由 Carlo Strozzi 在 1998 年使用。
- Oracle 于 1979 年將第一個商業(yè)關系數(shù)據(jù)庫推向市場，隨后是DB2、SAP Sybase ASE 和Informix。
- NoSQL 數(shù)據(jù)庫不是關系數(shù)據(jù)庫的替代品，而是為某些用例提供替代解決方案。
- SQL 數(shù)據(jù)庫提供高度的數(shù)據(jù)一致性和事務支持，使其成為需要數(shù)據(jù)完整性和可靠性的應用程序的熱門選擇。
- NoSQL 數(shù)據(jù)庫通常具有水平可擴展性，這意味著它們可以輕松地跨多個服務器分發(fā)數(shù)據(jù)，從而實現(xiàn)更大的可擴展性。
- CAP定理，也以計算機科學家Eric Brewer的名字命名為 Brewer 定理，指出任何分布式數(shù)據(jù)存儲只能提供三個保證中的兩個：
何時使用 SQL 或 NoSQL 沒有硬性規(guī)定，特定項目的最佳選擇將取決于項目的具體需求和約束。
SQL 數(shù)據(jù)庫通常比 NoSQL 數(shù)據(jù)庫使用更廣泛。根據(jù) DB-Engines的一項調(diào)查，在流行度和使用率上排名前五的數(shù)據(jù)庫都是 SQL 數(shù)據(jù)庫（Oracle、MySQL、Microsoft SQL Server、PostgreSQL 和 SQLite）。
使用 SQL 或 NoSQL 的實際應用程序
- Twitter 使用 NoSQL 數(shù)據(jù)庫 (Cassandra) 來存儲和管理其用戶生成的海量數(shù)據(jù)。他們說， “我們的地理團隊使用它來存儲和查詢他們的興趣點數(shù)據(jù)庫。研究團隊使用它來存儲對我們整個用戶群進行的數(shù)據(jù)挖掘的結果。 ”
- Netflix 使用 SQL 和 NoSQL 數(shù)據(jù)庫的組合來存儲和管理與其流媒體服務相關的數(shù)據(jù)。該公司使用 SQL 數(shù)據(jù)庫 (MySQL) 存儲結構化交易數(shù)據(jù)，例如訂戶信息和賬單記錄，并使用 NoSQL 數(shù)據(jù)庫 (Cassandra) 存儲與用戶交互和推薦相關的數(shù)據(jù)。
- LinkedIn 使用 SQL 和 NoSQL 數(shù)據(jù)庫的組合來存儲和管理與其專業(yè)網(wǎng)絡平臺相關的數(shù)據(jù)。Espresso 是 LinkedIn 的在線、分布式、容錯 NoSQL 數(shù)據(jù)庫，目前為大約 30 個 LinkedIn 應用程序提供支持，包括會員資料、InMail（LinkedIn 的會員間消息傳遞系統(tǒng)）、部分主頁和移動應用程序。
- Facebook使用 MySQL 作為主要數(shù)據(jù)庫，這是一個由 Oracle 開發(fā)的開源數(shù)據(jù)庫，為 Facebook 的一些最重要的工作負載提供支持。他們引入了 MyRocks，一種新的 MySQL 數(shù)據(jù)庫引擎，其目標是提高空間和寫入效率，超過壓縮 InnoDB 所能達到的水平。
- Stack Overflow使用 SQL Server。Nick Craver在他的一篇博客中寫道，Stack Overflow 正在使用 SQL Server 作為單一事實來源。Elastic 和 Redis 中的所有數(shù)據(jù)都來自 SQL Server。他們運行兩個帶有AlwaysOn 可用性組的 SQL Server 集群。
SQL 和 NoSQL 在不同業(yè)務中的用例
數(shù)據(jù)庫
- 財務系統(tǒng)
- 客戶關系管理 (CRM) 系統(tǒng)
- 庫存管理系統(tǒng)
- 人力資源 (HR) 系統(tǒng)
- 數(shù)據(jù)倉庫和商業(yè)智能 (BI) 系統(tǒng)
無SQL
- 社交媒體網(wǎng)絡
- 電子商務網(wǎng)站
- 實時分析系統(tǒng)
- 移動應用程序后端
- 內(nèi)容管理系統(tǒng) (CMS)
這些只是幾個示例，SQL 和 NoSQL 還有許多其他用例。
特定項目的最佳技術將取決于項目的具體需求和限制。
云端數(shù)據(jù)庫
大多數(shù)主要的云提供商都提供各種 SQL 和 NoSQL 數(shù)據(jù)庫作為服務。以下是一些主要云提供商提供的數(shù)據(jù)庫類型的一些示例：
- Amazon Web Services (AWS) 提供一系列 SQL 和 NoSQL 數(shù)據(jù)庫，包括：
- SQL：亞馬遜 RDS（MySQL、PostgreSQL、Oracle、Microsoft SQL Server）
- NoSQL：Amazon DynamoDB（鍵值對）、Amazon DocumentDB（文檔）、Amazon Neptune（圖形）
- Microsoft Azure 提供一系列 SQL 和 NoSQL 數(shù)據(jù)庫，包括：
- SQL：Azure SQL 數(shù)據(jù)庫（關系）、Azure Database for MySQL、Azure Database for PostgreSQL
- NoSQL：Azure Cosmos DB（多模型）、Azure 表存儲（鍵值）
- Google Cloud Platform 提供一系列 SQL 和 NoSQL 數(shù)據(jù)庫，包括：
- SQL：云 SQL（MySQL、PostgreSQL）
- NoSQL：Cloud Firestore（文檔）、Cloud Bigtable（寬列）、Cloud Datastore（文檔）
在 SQL 和無 SQL 之間進行選擇的最佳實踐
在為特定項目選擇 SQL 和 NoSQL 時，需要牢記一些最佳實踐（這不是最終列表）：
- 了解項目的具體需求和限制。這將幫助您確定最適合的技術。
- 考慮您正在使用的數(shù)據(jù)的類型和結構。SQL 非常適合具有明確關系的結構化、事務性數(shù)據(jù)，而 NoSQL 更適合處理具有較少定義關系的非結構化、大容量數(shù)據(jù)。（同樣，您的項目和用例將決定這一點。）
- 評估應用程序的可伸縮性和性能要求。您一定聽說過 NoSQL 數(shù)據(jù)庫通常比 SQL 數(shù)據(jù)庫更具可擴展性和性能，但情況可能并非總是如此。
- 考慮您需要的一致性和可靠性級別。SQL 數(shù)據(jù)庫通常更具可預測性和一致性，但 NoSQL 數(shù)據(jù)庫提供更大的靈活性。
- 測試不同的技術，看看哪一種技術在您的特定用例中表現(xiàn)最好。這將幫助您做出明智的決定。
- SQL 和 NoSQL 數(shù)據(jù)庫都可以提供高可用性和持久性，具體取決于具體的實施方式以及復制和分片等技術的使用。
- 每個人都在使用 NoSQL，所以這樣做并不總是正確的策略。
幫助決定的工具
為了幫助企業(yè)應用程序在 SQL 和 NoSQL 之間做出選擇，您可以考慮使用數(shù)據(jù)庫性能基準測試工具、數(shù)據(jù)庫設計和建模工具以及數(shù)據(jù)庫管理和監(jiān)控工具等工具。這些類型的工具的一些示例包括：
- MySQL 工作臺
- MongoDB 指南針
- 資料夾
- 海貍
- Redis 桌面管理器
數(shù)據(jù)庫實現(xiàn)失敗的原因
- 設計不當?shù)臄?shù)據(jù)模型或模式不符合應用程序的需要
- 性能測試或優(yōu)化不充分，導致數(shù)據(jù)庫性能不佳
- 缺乏強大的備份和恢復流程，導致數(shù)據(jù)丟失或損壞
- 數(shù)據(jù)庫維護和支持的規(guī)劃或資源不足
常見故障與異常
- 連接失敗—— 建立與數(shù)據(jù)庫的連接時出現(xiàn)問題，例如數(shù)據(jù)庫服務器未運行或連接詳細信息不正確時
- 解決方案：建立穩(wěn)健的連接管理和重試策略來處理連接失敗
- 查詢失敗 - 執(zhí)行查詢時出現(xiàn)問題，例如查詢語法無效或查詢執(zhí)行時間過長
- 解決方案：調(diào)試和優(yōu)化查詢以提高性能
- 事務失敗——如果數(shù)據(jù)庫事務出現(xiàn)問題，例如事務由于死鎖或違反約束而被取消或回滾
- 解決方案：實施適當?shù)慕灰坠芾硪宰畲笙薅鹊亟档徒灰资〉娘L險
- 數(shù)據(jù)損壞—— 當數(shù)據(jù)庫中存儲的數(shù)據(jù)出現(xiàn)問題時，例如當數(shù)據(jù)因硬件故障或軟件錯誤而損壞或丟失時，就會發(fā)生這種情況。
- 解決方案：實施備份和恢復策略以降低數(shù)據(jù)丟失或損壞的風險
- 性能問題：數(shù)據(jù)庫查詢性能不佳，如速度慢或數(shù)據(jù)庫消耗過多資源
- 解決方案：監(jiān)視和調(diào)整數(shù)據(jù)庫以識別和解決性能問題
數(shù)據(jù)庫的部署架構
- 獨立服務器：在此架構中，數(shù)據(jù)庫安裝在單個服務器上并由應用程序直接訪問。這是最簡單易用的部署選項，但不適合大規(guī)?；蚋呖捎眯詰贸绦?。
- 復制：在這里，數(shù)據(jù)庫部署在多臺服務器上，每臺服務器都托管一份數(shù)據(jù)副本。服務器配置在副本集中，其中一個服務器被指定為主服務器。應用程序寫入主服務器，數(shù)據(jù)自動復制到其他服務器。這提供了改進的可用性和容錯性，但不提供水平可伸縮性。
- 分片：這與復制相同，其中數(shù)據(jù)庫部署在多臺服務器上，并且數(shù)據(jù)跨服務器分區(qū)。這里的分區(qū)稱為分片，服務器被組織成一個分片集群。應用程序寫入集群，數(shù)據(jù)自動路由到適當?shù)姆制?。這種風格提供了改進的可伸縮性和性能，同時需要額外的配置和管理。
- 云托管服務：云提供商管理數(shù)據(jù)庫并由 API 訪問。這可能是最簡單的部署和管理方式。另一方面，它可能很昂貴，與其他相比，控制和定制會更少。
什么會導致數(shù)據(jù)庫中的性能問題
- 資源不足
- 設計不佳的查詢
- 索引問題
- 架構未優(yōu)化
- 分片問題
- 網(wǎng)絡延遲或帶寬
我使用 SQL 和 NOSQL 的個人經(jīng)驗
我是企業(yè) API 開發(fā)團隊的一員，最初我們開始使用 SQL 數(shù)據(jù)庫。后來當我們的組織采用 NoSQL 時，考慮到我們將擴展并且其他一切都會順利的事實，我們搬到了那里。
然而，我們開始遇到規(guī)模、性能、索引等挑戰(zhàn)。使用 NoSQL 數(shù)據(jù)庫的挑戰(zhàn)之一是它們通常缺乏關系數(shù)據(jù)庫提供的強大的數(shù)據(jù)一致性保證。您需要記住分布式環(huán)境中的“最終一致性”。這意味著在某些情況下數(shù)據(jù)可能會變得不一致或過時，例如當多個客戶端同時更新相同的數(shù)據(jù)時。
所以作為初學者，我們從來沒有想過這個場景，逐漸開始學習和重新設計數(shù)據(jù)庫架構，從記錄走向文檔。NoSQL 數(shù)據(jù)庫旨在處理大量數(shù)據(jù)和高讀寫吞吐量，但優(yōu)化其性能需要深入了解數(shù)據(jù)庫的體系結構和配置設置。
需要從只關注關系的心態(tài)轉變。數(shù)據(jù)庫是存儲數(shù)據(jù)的地方，遵循特定的數(shù)據(jù)結構?？紤]從充滿業(yè)務邏輯的存儲過程轉移到僅應用程序的業(yè)務邏輯：數(shù)據(jù)庫內(nèi)部將沒有邏輯。在充分利用 NoSQL 的同時，必須更好地進行數(shù)據(jù)建模和設計索引。
