非關係資料庫是資料庫，不會使用大部分傳統資料庫系統中所找到之數據列和數據行的表格式架構。 相反地，非關係資料庫會使用已針對所儲存數據類型的特定需求優化的記憶體模型。 例如，數據可以儲存為簡單的索引鍵/值組、JSON 檔，或以邊緣和頂點組成的圖形。
所有這些數據存放區都有共同之處，就是它們不會使用 關係型模型。 此外，它們通常更具體於所支援數據類型，以及如何查詢數據。 例如，時間序列數據存放區會針對以時間為基礎的數據序列進行查詢優化。 不過，圖表數據存放區已針對探索實體之間的加權關聯性進行優化。 這兩種格式都無法一般化為管理事務數據的工作。
NoSQL 一詞是指不使用 SQL 進行查詢的數據存放區。 相反地，數據存放區會使用其他程式設計語言和建構來查詢數據。 實際上，“NoSQL” 表示「非關係資料庫」，即使其中許多資料庫都支援 SQL 相容的查詢。 不過，基礎查詢執行策略通常與傳統關係資料庫管理系統 （RDBMS） 執行相同 SQL 查詢的方式非常不同。
NoSQL 資料庫的實作和特製化有變化，例如關係資料庫的功能有變化。 這些變化提供每個實作自己的主要優勢，並隨附自己的學習曲線和使用建議。 下列各節說明非關係型或 NoSQL 資料庫的主要類別。
檔資料存放區
檔數據存放區會在稱為 文件的實體中管理一組具名字符串字段和對象數據值。 這些數據存放區通常會以 JSON 檔的形式儲存數據。 每個域值可以是純量專案，例如數位或複合專案，例如清單或父子集合。 檔欄位中的數據可以透過各種方式編碼，包括 XML、YAML、JSON、二進位 JSON （BSON），或甚至儲存為純文本。 檔中的欄位會公開至記憶體管理系統，讓應用程式能夠使用這些欄位中的值來查詢和篩選數據。
通常，文件包含實體的整個資料。 組成實體的項目是應用程式特有的。 例如，實體可以包含客戶的詳細資料、訂單或兩者的組合。 單一檔可能包含將散佈在關係資料庫管理系統 （RDBMS） 中數個關係型數據表的資訊。 文件存放區不需要所有文件都具有相同的結構。 這種自由形式的方法提供了很大的彈性。 例如，應用程式可以將不同的資料儲存在檔中，以響應商務需求變更。
應用程式可以使用檔案索引鍵來擷取檔。 索引鍵是檔的唯一標識符，通常為哈希，以協助平均散發數據。 某些文件資料庫會自動建立文件索引鍵。 其他文件則可讓您指定文件的屬性，當作索引鍵使用。 應用程式也可以根據一或多個欄位的值來查詢文件。 某些文件資料庫支援編制索引，以根據一或多個索引欄位來快速查閱文件。
許多檔案資料庫都支援就地更新，可讓應用程式修改檔中特定欄位的值，而不需要重寫整份檔。 單一檔中多個字段的讀取和寫入作業通常是不可部分完成的。
相關的 Azure 服務：
單欄式數據存放區
單欄式或數據行系列數據存放區會將數據組織成數據行和數據列。 最簡單的形式是，數據行系列數據存放區看起來與關係資料庫非常類似，至少在概念上。 數據行系列資料庫的真正威力在於其建構疏鬆數據的反正規化方法，這源於數據行導向的儲存方法。
您可以將數據行系列數據存放區視為保存具有數據列和數據行的表格式數據，但數據行會分成稱為數據行系列的群組。 每個數據行系列都會保存一組邏輯相關的數據行，而且通常會以單位的形式擷取或操作。 其他個別存取的數據可以儲存在個別的數據行系列中。 在數據行系列中，可以動態加入新的數據行，而且數據列可能比較疏鬆（也就是說，每個數據行不需要有值）。
下圖顯示兩個數據行系列 Identity 和 Contact Info的範例。 單一實體的數據在每個數據行系列中都有相同的數據列索引鍵。 這個結構，其中數據行系列中任何指定對象的數據列可以動態變化，是數據行系列方法的重要優點，使得這種形式的數據存放區非常適合以不同的架構儲存數據。
與索引鍵/值存放區或文件資料庫不同，大部分的數據行系列資料庫會以索引鍵順序實際儲存數據，而不是藉由計算哈希。 數據列索引鍵會被視為主要索引，並透過特定索引鍵或索引鍵範圍啟用索引鍵型存取。 某些實作可讓您針對數據行系列中的特定數據行建立次要索引。 次要索引可讓您依數據行值擷取數據，而不是數據列索引鍵。
在磁碟上，數據行系列中的所有數據行都會一起儲存在相同的檔案中，每個檔案中都有特定數目的數據列。 使用大型數據集時，此方法可藉由減少一次查詢一些數據行時，需要從磁碟讀取的數據量來建立效能優勢。
一個數據列的讀取和寫入作業通常是在單一數據行系列內不可部分完成的，雖然某些實作提供整個數據列的不可部分完成性，跨越多個數據行系列。
相關的 Azure 服務：
索引鍵/值數據存放區
索引鍵/值存放區基本上是大型哈希表。 您可以將每個數據值與唯一索引鍵產生關聯，而索引鍵/值存放區會使用此索引鍵來使用適當的哈希函式來儲存數據。 已選取哈希函式，以提供數據記憶體間哈希索引鍵的偶數分佈。
大部分的索引鍵/值存放區只支援簡單的查詢、插入和刪除作業。 若要修改值（部分或完全修改），應用程式必須覆寫整個值的現有數據。 在大部分的實作中，讀取或寫入單一值是不可部分完成的作業。 如果值很大，撰寫可能需要一些時間。
應用程式可以將任意數據儲存為一組值，不過某些索引鍵/值存放區會限制值的大小上限。 預存值對記憶體系統軟體不透明。 應用程式必須提供和解譯任何架構資訊。 基本上，值為 Blob，而索引鍵/值存放區只會依索引鍵擷取或儲存值。
索引鍵/值存放區針對使用索引鍵值或索引鍵範圍執行簡單查閱的應用程式進行高度優化，但不適合需要跨不同索引鍵/值數據表查詢數據的系統，例如跨多個數據表聯結數據。
索引鍵/值存放區也不會針對非索引鍵值進行查詢或篩選的案例進行優化，而不是只根據索引鍵執行查閱。 例如，使用關係資料庫時，您可以使用 WHERE 子句來篩選非索引鍵數據行來尋找記錄，但索引鍵/值存放區通常沒有這類值的查閱功能，或者如果這樣做，則需要緩慢掃描所有值。
單一索引鍵/值存放區可大幅調整，因為數據存放區可以輕鬆地將數據分散到不同機器上的多個節點上。
相關 Azure 服務：
圖形數據存放區
圖形數據存放區會管理兩種類型的信息、節點和邊緣。 節點代表實體，邊緣會指定這些實體之間的關聯性。 節點和邊緣都可以有屬性，可提供該節點或邊緣的相關信息，類似於數據表中的數據行。 邊緣也可以有指示關聯性本質的方向。
圖形數據存放區的目的是讓應用程式有效率地執行查詢，以周遊節點和邊緣的網路，以及分析實體之間的關聯性。 下圖顯示組織的人員數據結構化為圖表。 實體是員工和部門，邊緣表示報告關聯性，以及員工工作所在的部門。 在此圖形中，邊緣上的箭號顯示關聯性的方向。
此結構可讓您直接執行查詢，例如「尋找直接或間接向 Sarah 回報的所有員工」或「誰在與 John 同一個部門工作？對於具有許多實體和關聯性的大型圖表，您可以快速執行複雜的分析。 許多圖形資料庫都提供查詢語言，可讓您用來有效率地周遊關聯性網路。
相關的 Azure 服務：
時間序列資料存放區
時間序列數據是一組依時間組織的值，而時間序列數據存放區會針對這種類型的數據進行優化。 時間序列數據存放區必須支援非常大量的寫入，因為它們通常會從大量來源即時收集大量數據。 時間序列數據存放區已針對儲存遙測數據進行優化。 案例包括IoT感測器或應用程式/系統計數器。 更新很少見，而且刪除通常做為大量作業。
雖然寫入時間序列資料庫的記錄通常很小，但通常會有大量的記錄，而且數據大小總計可能會快速成長。 時間序列數據存放區也會處理順序失序和延遲抵達的數據、數據點的自動編製索引，以及時間範圍中所述查詢的優化。 這項最後一項功能可讓查詢快速跨數百萬個數據點和多個數據流執行，以支援時間序列視覺效果，這是取用時間序列數據的常見方式。
相關 Azure 服務：
物件數據存放區
對象資料存放區已針對儲存和擷取大型二進位物件或 Blob 進行優化，例如影像、文本檔、視訊和音訊數據流、大型應用程式數據物件和檔，以及虛擬機磁碟映像。 物件包含儲存的數據、某些元數據，以及存取物件的唯一標識符。 物件存放區的設計目的是支持個別非常大的檔案，並提供大量的總記憶體來管理所有檔案。
某些物件資料存放區會將指定的 Blob 複寫到多個伺服器節點，以快速平行讀取。 接著，此程式可針對大型檔案中包含的數據進行向外延展查詢，因為多個進程通常會在不同的伺服器上執行，因此每個進程都可以同時查詢大型數據檔。
對象數據存放區的特殊案例之一是網路檔案共用。 使用檔案共用可讓檔案使用伺服器消息塊（SMB）等標準網路通訊協定，跨網路存取檔案。 基於適當的安全性和並行訪問控制機制，以這種方式共用數據可讓分散式服務為基本、低階的作業提供高度可調整的數據存取，例如簡單的讀取和寫入要求。
相關 Azure 服務：
外部索引數據存放區
外部索引數據存放區可讓您搜尋其他數據存放區和服務中保留的資訊。 外部索引可作為任何數據存放區的次要索引，並可用來編製大量數據的索引，並提供近乎實時的這些索引存取。
例如，您可能有文字檔案儲存在檔案系統中。 依檔案路徑尋找檔案的速度很快，但根據檔案的內容進行搜尋時，需要掃描所有檔案的速度很慢。 外部索引可讓您建立次要搜尋索引，然後快速尋找符合準則的檔案路徑。 外部索引的另一個範例應用程式是索引鍵/值存放區，而索引鍵/值則只由索引鍵編製索引。 您可以根據數據中的值來建置次要索引，並快速查閱可唯一識別每個相符專案的索引鍵。
索引是藉由執行索引處理來建立。 這可以使用提取模型、由數據存放區觸發，或使用應用程式程序代碼起始的推送模型來執行。 索引可以是多維度，而且可支援跨大量文字數據的任意文字搜尋。
外部索引數據存放區通常用來支援全文檢索和網頁式搜尋。 在這些情況下，搜尋可能完全或模糊。 模糊搜尋會尋找符合一組字詞的檔，並計算其相符程度。 某些外部索引也支持語言分析，這些分析可以根據同義字傳回相符專案、類型擴充（例如，比對“狗”與“寵物”），以及字幹分析（例如，搜尋 “run” 也符合 “ran” 和 “running” ）。
相關的 Azure 服務：
一般需求
非關係型數據存放區通常會使用與關係資料庫所使用的不同記憶體架構。 具體而言，它們傾向於沒有固定的架構。 此外，它們通常不支援交易，或限制交易的範圍，而且通常不會因為延展性原因而包含次要索引。
相較於許多傳統關係資料庫，NoSQL 資料庫通常會提供理想的架構彈性和平臺延展性層級，但有時候這些優點會以較弱的一致性為代價。 即使您可以彈性地儲存數據，您仍然需要識別和分析您的數據存取模式，然後設計適當的數據架構，否則您的 NoSQL 資料庫可能會遭受繁重的工作負載或非預期的使用模式。
下列會比較每個非關係型數據存放區的需求：
| 需求 | 檔數據 | 數據列系列數據 | 索引鍵/值數據 | 圖表資料 |
|---|---|---|---|---|
| 正規化 | 反正規化 | 反正規化 | 反正規化 | 規範化 |
| 結構描述 | 讀取的架構 | 寫入時定義的數據列系列、讀取時的數據行架構 | 讀取的架構 | 讀取的架構 |
| 一致性 （跨併行交易） | 無法一致性，檔層級保證 | 數據行系列層級保證 | 索引鍵層級保證 | 圖形層級保證 |
| 不可部分完成性 （交易範圍） | 集合 | Table | Table | 圖表 |
| 鎖定策略 | 開放式 （無鎖定） | 悲觀主義 （數據列鎖定） | 開放式（實體標籤（ETag）） | |
| 存取模式 | 隨機存取 | 高/寬數據的匯總 | 隨機存取 | 隨機存取 |
| 編製索引 | 主要和次要索引 | 主要和次要索引 | 僅限主要索引 | 主要和次要索引 |
| 數據圖形 | Document | 包含資料行之數據列系列的表格式 | 索引鍵和值 | 包含邊緣和頂點的圖形 |
| 疏鬆 | Yes | .是 | 是 | No |
| 寬 （許多資料行/屬性） | Yes | 是 | 無 | No |
| Datum 大小 | 小型 （KB） 到中 （低 MB） | 中型 （MB） 到大型 （低 GB） | 小型 （KB） | 小型 （KB） |
| 整體最大縮放比例 | 非常大（PB） | 非常大（PB） | 非常大（PB） | 大型 （TB） |
| 需求 | 時間序列資料 | 對象數據 | 外部索引數據 |
|---|---|---|---|
| 正規化 | 規範化 | 反正規化 | 反正規化 |
| 結構描述 | 讀取的架構 | 讀取的架構 | 寫入時架構 |
| 一致性 （跨併行交易） | N/A | N/A | N/A |
| 不可部分完成性 （交易範圍） | N/A | Object | N/A |
| 鎖定策略 | N/A | 悲觀 （Blob 鎖定） | N/A |
| 存取模式 | 隨機存取和匯總 | 循序存取 | 隨機存取 |
| 編製索引 | 主要和次要索引 | 僅限主要索引 | N/A |
| 數據圖形 | 表格式 | Blob 和元數據 | Document |
| 疏鬆 | No | N/A | No |
| 寬 （許多資料行/屬性） | No | .是 | Yes |
| Datum 大小 | 小型 （KB） | 大型 （GB） 到非常大 （TB） | 小型 （KB） |
| 整體最大縮放比例 | 大型 （低 TB） | 非常大（PB） | 大型 （低 TB） |
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Zoiner Tejada | CEO 暨架構設計師