一網(wǎng)打盡 NoSQL：當(dāng)下 NoSQL 類(lèi)型、適用場(chǎng)景及使用公司

前言

在互聯(lián)網(wǎng)和大數(shù)據(jù)的背景下，越來(lái)越多的網(wǎng)站、應(yīng)用系統(tǒng)需要支撐海量數(shù)據(jù)存儲(chǔ)、高并發(fā)請(qǐng)求、高可用、高可擴(kuò)展性等特性要求。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù) RDBMS 已經(jīng)難以應(yīng)對(duì)類(lèi)似的需求，各種各樣的 NoSQL（Not Only SQL）數(shù)據(jù)庫(kù)憑借易擴(kuò)展、大數(shù)據(jù)量和高性能以及靈活的數(shù)據(jù)模型成功的在數(shù)據(jù)庫(kù)領(lǐng)域站穩(wěn)了腳跟。本文將分析傳統(tǒng)數(shù)據(jù)庫(kù)的存在的問(wèn)題，以及幾類(lèi) NoSQL 如何解決這些問(wèn)題。在不同的業(yè)務(wù)場(chǎng)景下，作出正確的數(shù)據(jù)存儲(chǔ)技術(shù)選型。

傳統(tǒng)數(shù)據(jù)庫(kù)缺點(diǎn)

NoSQL 簡(jiǎn)介

NoSQL，指的是非關(guān)系型的數(shù)據(jù)庫(kù)，可以理解為關(guān)系型數(shù)據(jù)庫(kù)的一個(gè)有力補(bǔ)充。NoSQL 有時(shí)也稱(chēng)作 Not Only SQL 的縮寫(xiě)，是對(duì)不同于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)庫(kù)管理系統(tǒng)的統(tǒng)稱(chēng)，它具有非關(guān)系型、分布式、不提供 ACID 的數(shù)據(jù)庫(kù)設(shè)計(jì)模式等特征。

NoSQL 用于超大規(guī)模數(shù)據(jù)的存儲(chǔ)（例如谷歌或 Facebook 每天為他們的用戶(hù)收集萬(wàn)億比特的數(shù)據(jù)）。這些類(lèi)型的數(shù)據(jù)存儲(chǔ)不需要固定的模式，無(wú)需多余操作就可以橫向擴(kuò)展。

NoSQL 在許多方面性能大大優(yōu)于非關(guān)系型數(shù)據(jù)庫(kù)的同時(shí)，往往也伴隨一些特性的缺失。比較常見(jiàn)的是事務(wù)功能的缺失。數(shù)據(jù)庫(kù)事務(wù)正確執(zhí)行的四個(gè)基本要素 ACID 如下：

目前大家基本認(rèn)同將 NoSQL 數(shù)據(jù)庫(kù)分為四大類(lèi)：鍵值（Key-Value）數(shù)據(jù)庫(kù)、列存儲(chǔ)（Wide Column Store/Column-Family）數(shù)據(jù)庫(kù)、 圖（Graph-Oriented）數(shù)據(jù)庫(kù)以及面向文檔（Document-Oriented）數(shù)據(jù)庫(kù)，其中每一種類(lèi)型的數(shù)據(jù)庫(kù)都能夠解決關(guān)系型數(shù)據(jù)不能解決的問(wèn)題。在實(shí)際應(yīng)用中，NoSQL 數(shù)據(jù)庫(kù)的分類(lèi)界限其實(shí)沒(méi)有那么明顯，往往會(huì)是多種類(lèi)型的組合體。

鍵值（Key-Value）數(shù)據(jù)庫(kù)

使用鍵值（key-value）存儲(chǔ)的數(shù)據(jù)庫(kù)，其數(shù)據(jù)按照鍵值對(duì)的形式進(jìn)行組織、索引和存儲(chǔ)。KV 存儲(chǔ)非常適合不涉及過(guò)多數(shù)據(jù)關(guān)系業(yè)務(wù)的數(shù)據(jù)。它能夠有效減少讀寫(xiě)磁盤(pán)的次數(shù)，比關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)擁有更好的讀寫(xiě)性能，能夠解決關(guān)系型數(shù)據(jù)庫(kù)無(wú)法存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)的問(wèn)題。

常見(jiàn) K-V 數(shù)據(jù)庫(kù)?：Redis、Memcached、LevelDB、Cassandra

Redis

Redis 是一個(gè)使用 ANSI C 編寫(xiě)的開(kāi)源、支持網(wǎng)絡(luò)、基于內(nèi)存、可選持久性的鍵值對(duì)存儲(chǔ)數(shù)據(jù)庫(kù)。Redis 是目前最流行的鍵值對(duì)存儲(chǔ)數(shù)據(jù)庫(kù)之一。

最佳應(yīng)用場(chǎng)景：適用于數(shù)據(jù)變化快且數(shù)據(jù)庫(kù)大小可遇見(jiàn)（適合內(nèi)存容量）的應(yīng)用程序。

例如：股票價(jià)格、數(shù)據(jù)分析、實(shí)時(shí)數(shù)據(jù)搜集、實(shí)時(shí)通訊。

Memcached

Memcached 是一個(gè)開(kāi)放源代碼、高性能、分配的內(nèi)存對(duì)象緩存系統(tǒng)。用于加速動(dòng)態(tài) web 應(yīng)用程序，減輕關(guān)系型數(shù)據(jù)庫(kù)負(fù)載。它可以應(yīng)對(duì)任意多個(gè)連接，使用非阻塞的網(wǎng)絡(luò) IO。由于它的工作機(jī)制是在內(nèi)存中開(kāi)辟一塊空間，然后建立一個(gè) Hash 表，Memcached 自管理這些 Hash 表。
Memcached 簡(jiǎn)單而強(qiáng)大。它簡(jiǎn)單的設(shè)計(jì)促進(jìn)迅速部署，易于發(fā)現(xiàn)所面臨的問(wèn)題，解決了很多大型數(shù)據(jù)緩存。

Cassandra

Apache Cassandra（社區(qū)內(nèi)一般簡(jiǎn)稱(chēng)為 C*）是一套開(kāi)源的分布式 NoSQL 數(shù)據(jù)庫(kù)系統(tǒng)。它最初由 Facebook 開(kāi)發(fā)，用于儲(chǔ)存收件箱等簡(jiǎn)單格式數(shù)據(jù)，集 Google BigTable 的數(shù)據(jù)模型與 Amazon Dynamo 的完全分布式架構(gòu)于一身。Cassandra 是一種流行的分布式結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)方案。

最佳應(yīng)用場(chǎng)景：當(dāng)使用寫(xiě)操作多過(guò)讀操作（記錄日志）

例如：銀行業(yè)，金融業(yè)（雖然對(duì)于金融交易不是必須的，但這些產(chǎn)業(yè)對(duì)數(shù)據(jù)庫(kù)的要求會(huì)比它們更大）寫(xiě)比讀更快，所以一個(gè)自然的特性就是實(shí)時(shí)數(shù)據(jù)分析

LevelDB

LevelDB 是一個(gè)由 Google 所研發(fā)的鍵／值對(duì)（Key/Value Pair）嵌入式數(shù)據(jù)庫(kù)管理系統(tǒng)編程庫(kù)，以開(kāi)源的 BSD 許可證發(fā)布。LevelDB 是一個(gè)基于本地文件的存儲(chǔ)引擎，非分布式存儲(chǔ)引擎，原理基于 BigTable（LSM 文件樹(shù)），無(wú)索引機(jī)制，存儲(chǔ)條目為 Key-value。適用于保存數(shù)據(jù)緩存、日志存儲(chǔ)、高速緩存等應(yīng)用，主要是避免 RPC 請(qǐng)求帶來(lái)的延遲問(wèn)題。

相關(guān)特性

K-V 數(shù)據(jù)庫(kù)的相關(guān)特性，以 Redis 為例說(shuō)明：：

優(yōu)點(diǎn)

• 性能極高：Redis 單機(jī)最高能支持超過(guò) 10W 的 TPS。

• 豐富的數(shù)據(jù)類(lèi)型：Redis 支持包括 String，Hash，List，Set，SortedSet，Bitmap 和 Hyperloglog 等數(shù)據(jù)結(jié)構(gòu)。

• 豐富的特性：Redis 還支持 publish/subscribe，通知，key 過(guò)期等特性。

缺點(diǎn)

• Redis 事務(wù)不能支持原子性和持久性（A 和 D），只支持隔離性和一致性（I 和 C）。

應(yīng)用場(chǎng)景

適用場(chǎng)景

內(nèi)容緩存，主要用于處理大量數(shù)據(jù)的高訪問(wèn)負(fù)載，也用于一些日志系統(tǒng)等等。適合存儲(chǔ)用戶(hù)信息（比如會(huì)話(huà)）、配置文件、參數(shù)、購(gòu)物車(chē)等等。這些信息一般都和 ID 掛鉤。

不適用場(chǎng)景

• 不適合需要通過(guò)值來(lái)查詢(xún)，而不是鍵來(lái)查詢(xún)。Key-Value 數(shù)據(jù)庫(kù)中根本沒(méi)有通過(guò)值查詢(xún)的途徑。

• 不適合需要儲(chǔ)存數(shù)據(jù)之間的關(guān)系。在 Key-Value 數(shù)據(jù)庫(kù)中不能通過(guò)兩個(gè)或以上的鍵來(lái)關(guān)聯(lián)數(shù)據(jù)。

• 不適合需要支持事務(wù)的場(chǎng)景。在 Key-Value 數(shù)據(jù)庫(kù)中故障產(chǎn)生時(shí)不可以進(jìn)行回滾。

列存儲(chǔ)（Wide Column Store/Column-Family）數(shù)據(jù)庫(kù)

列式數(shù)據(jù)庫(kù)是以列相關(guān)存儲(chǔ)架構(gòu)進(jìn)行數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫(kù)，主要適合于批量數(shù)據(jù)處理和即時(shí)查詢(xún)。相對(duì)應(yīng)的是行式數(shù)據(jù)庫(kù)，數(shù)據(jù)以行相關(guān)的存儲(chǔ)架構(gòu)進(jìn)行空間分配，主要適合于小批量的數(shù)據(jù)處理，常用于聯(lián)機(jī)事務(wù)型數(shù)據(jù)處理?；诹惺綌?shù)據(jù)庫(kù)的列存儲(chǔ)特性，可以解決某些特定場(chǎng)景下關(guān)系型數(shù)據(jù)庫(kù)高 I/O 的問(wèn)題。

常見(jiàn)列式數(shù)據(jù)庫(kù)?：HBase、BigTable

HBase

HBase 是一個(gè)開(kāi)源的非關(guān)系型分布式數(shù)據(jù)庫(kù)（NoSQL），它參考了谷歌的 BigTable 建模，實(shí)現(xiàn)的編程語(yǔ)言為 Java。它是 Apache 軟件基金會(huì)的 Hadoop 項(xiàng)目的一部分，運(yùn)行于 HDFS 文件系統(tǒng)之上，為 Hadoop 提供類(lèi)似于 BigTable 規(guī)模的服務(wù)。因此，它可以容錯(cuò)地存儲(chǔ)海量稀疏的數(shù)據(jù)。

最佳應(yīng)用場(chǎng)景：適用于偏好 BigTable；對(duì)數(shù)據(jù)有版本查詢(xún)需求，并且需要對(duì)大數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時(shí)訪問(wèn)的場(chǎng)合。

例如：Facebook 消息數(shù)據(jù)庫(kù)

BigTable

BigTable 是一種壓縮的、高性能的、高可擴(kuò)展性的，基于 Google 文件系統(tǒng)（Google File System，GFS）的數(shù)據(jù)存儲(chǔ)系統(tǒng)，用于存儲(chǔ)大規(guī)模結(jié)構(gòu)化數(shù)據(jù)，適用于云計(jì)算。

相關(guān)特性

優(yōu)點(diǎn)

• 高效的儲(chǔ)存空間利用率：列式數(shù)據(jù)庫(kù)針對(duì)不同列的數(shù)據(jù)特征而發(fā)明了不同算法，使其比行式數(shù)據(jù)庫(kù)高的多的壓縮率。普通的行式數(shù)據(jù)庫(kù)一般壓縮率在 3：1 到 5：1 左右，而列式數(shù)據(jù)庫(kù)的壓縮率一般在 8：1 到 30：1 左右。

• 查詢(xún)效率高：讀取多條數(shù)據(jù)的同一列效率高，因?yàn)檫@些列都是存儲(chǔ)在一起的，一次磁盤(pán)操作可以把數(shù)據(jù)的指定列全部讀取到內(nèi)存中。

• 適合做聚合操作

• 適合大量的數(shù)據(jù)而不是小數(shù)據(jù)

缺點(diǎn)

• 不適合掃描小量數(shù)據(jù)

• 不適合隨機(jī)的更新

• 不適合做含有刪除和更新的實(shí)時(shí)操作

• 單行數(shù)據(jù)支持 ACID 的事務(wù)操作，多行數(shù)據(jù)的事務(wù)操作，不支持事務(wù)的正常回滾，支持（Isolation）隔離性、(Durability）持久性，不能保證(Atomicity）原子性、（Consistency）一致性

應(yīng)用場(chǎng)景

列數(shù)據(jù)庫(kù)的適用場(chǎng)景，以 HBase 為例說(shuō)明：

• 適合大數(shù)據(jù)量(100TB 級(jí)數(shù)據(jù)），有快速隨機(jī)訪問(wèn)的需求。

• 適合寫(xiě)密集型應(yīng)用，每天寫(xiě)入量巨大，而讀數(shù)量相對(duì)較小的應(yīng)用，比如 IM 的歷史消息，游戲日志等等。

• 適合不需要復(fù)雜查詢(xún)條件來(lái)查詢(xún)數(shù)據(jù)的應(yīng)用。HBase 只支持基于 rowkey 的查詢(xún)，對(duì)于 HBase 來(lái)說(shuō)，單條記錄或者小范圍的查詢(xún)是可以接受的。大范圍的查詢(xún)由于分布式的原因，可能在性能上有點(diǎn)影響。HBase 不適用于有 join，多級(jí)索引，表關(guān)系復(fù)雜的數(shù)據(jù)模型。

• 對(duì)性能和可靠性要求非常高的應(yīng)用。

• 由于 HBase 本身沒(méi)有單點(diǎn)故障，可用性非常高。

• 適合數(shù)據(jù)量較大，而且增長(zhǎng)量無(wú)法預(yù)估的應(yīng)用，需要進(jìn)行優(yōu)雅的數(shù)據(jù)擴(kuò)展的應(yīng)用。HBase 支持在線擴(kuò)展，即使在一段時(shí)間內(nèi)，數(shù)據(jù)量呈井噴式增長(zhǎng)，也可以通過(guò) HBase 橫向擴(kuò)展來(lái)滿(mǎn)足功能。

• 存儲(chǔ)結(jié)構(gòu)化和半結(jié)構(gòu)化的數(shù)據(jù)。

圖（Graph-Oriented）數(shù)據(jù)庫(kù)

圖形數(shù)據(jù)庫(kù)應(yīng)用圖形理論存儲(chǔ)實(shí)體之間的關(guān)系信息。最常見(jiàn)例子就是社會(huì)網(wǎng)絡(luò)中人與人之間的關(guān)系。關(guān)系型數(shù)據(jù)庫(kù)用于存儲(chǔ)這種關(guān)系型數(shù)據(jù)的效果并不好，其查詢(xún)復(fù)雜、緩慢、超出預(yù)期。
圖形數(shù)據(jù)庫(kù)的獨(dú)特設(shè)計(jì)彌補(bǔ)了這個(gè)缺陷，解決關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)和處理復(fù)雜關(guān)系型數(shù)據(jù)功能較弱的問(wèn)題。

常見(jiàn)圖形數(shù)據(jù)庫(kù)?：Neo4j、ArangoDB

Neo4j

Neo4j 是一個(gè)高性能的，NOSQL 圖形數(shù)據(jù)庫(kù)，它將結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)在 “圖形網(wǎng)絡(luò)上” 而不是“表中”。它是一個(gè)嵌入式的、基于磁盤(pán)的、具備完全的事務(wù)特性的 Java 持久化引擎。Neo4j 也可以被看作是一個(gè)高性能的圖引擎。

最佳應(yīng)用場(chǎng)景：適用于圖形一類(lèi)數(shù)據(jù)。這是 Neo4j 與其他 nosql 數(shù)據(jù)庫(kù)的最顯著區(qū)別

例如：社會(huì)關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜

ArangoDB

ArangoDB 是一個(gè)原生多模型數(shù)據(jù)庫(kù)系統(tǒng)。數(shù)據(jù)庫(kù)系統(tǒng)支持三個(gè)重要的數(shù)據(jù)模型（鍵 / 值，文檔，圖形）。ArangoDB 包含一個(gè)數(shù)據(jù)庫(kù)核心和統(tǒng)一查詢(xún)語(yǔ)言 AQL（ArangoDB 查詢(xún)語(yǔ)言）。查詢(xún)語(yǔ)言是聲明性的，允許在單個(gè)查詢(xún)中組合不同的數(shù)據(jù)訪問(wèn)模式。ArangoDB 是一個(gè) NoSQL 數(shù)據(jù)庫(kù)系統(tǒng)，但 AQL 在很多方面與 SQL 都類(lèi)似。

相關(guān)特性

優(yōu)點(diǎn)

• 高性能表現(xiàn)：圖的遍歷是圖數(shù)據(jù)結(jié)構(gòu)所具有的獨(dú)特算法，即從一個(gè)節(jié)點(diǎn)開(kāi)始，根據(jù)其連接的關(guān)系，可以快速和方便地找出它的鄰近節(jié)點(diǎn)。這種查找數(shù)據(jù)的方法不受數(shù)據(jù)量大小的影響，因?yàn)猷徑樵?xún)始終查找的是有限的局部數(shù)據(jù)，不會(huì)對(duì)整個(gè)數(shù)據(jù)庫(kù)進(jìn)行搜索。利用圖結(jié)構(gòu)相關(guān)算法。比如最短路徑尋址，N 度關(guān)系查找等。

• 設(shè)計(jì)的靈活性：數(shù)據(jù)結(jié)構(gòu)的自然伸展特性，以及其非結(jié)構(gòu)化的數(shù)據(jù)格式，讓圖數(shù)據(jù)庫(kù)設(shè)計(jì)可以具有很大的伸縮性和靈活性。因?yàn)殡S著需求的變化而增加的節(jié)點(diǎn)、關(guān)系及其屬性，并不會(huì)影響到原來(lái)數(shù)據(jù)的正常使用。

• 開(kāi)發(fā)的敏捷性：數(shù)據(jù)模型直接明了，從需求的討論開(kāi)始，到程序開(kāi)發(fā)和實(shí)現(xiàn)，基本上不會(huì)有大的變化。

• 完全支持 ACID：不像別的 NoSQL 數(shù)據(jù)庫(kù)，Neo4j 還完全具有事務(wù)管理特性，完全支持 ACID 事務(wù)管理。

缺點(diǎn)

• 節(jié)點(diǎn)，關(guān)系和它們的屬性的數(shù)量被限制。

• 不支持拆分，圖數(shù)據(jù)庫(kù)結(jié)構(gòu)不太好做分布式的集群方案。

應(yīng)用場(chǎng)景

適用場(chǎng)景

專(zhuān)注于構(gòu)建關(guān)系圖譜，善于處理大量復(fù)雜、互連接、低結(jié)構(gòu)化的數(shù)據(jù)，數(shù)據(jù)往往變化迅速，且查詢(xún)頻繁。（1）在一些關(guān)系性強(qiáng)的數(shù)據(jù)應(yīng)用，例如社交網(wǎng)絡(luò)。（2）推薦引擎，將數(shù)據(jù)以圖的形式表現(xiàn)，非常有益于推薦的制定。

不適用場(chǎng)景

• 記錄大量基于事件的數(shù)據(jù)，如日志記錄、傳感器數(shù)據(jù)。

• 對(duì)大規(guī)模分布式數(shù)據(jù)進(jìn)行處理，類(lèi)似于 Hadoop。

• 不適用于應(yīng)該保存在關(guān)系型數(shù)據(jù)庫(kù)中的結(jié)構(gòu)化數(shù)據(jù)。

• 二進(jìn)制數(shù)據(jù)存儲(chǔ)。

面向文檔（Document-Oriented）數(shù)據(jù)庫(kù)

文檔數(shù)據(jù)庫(kù)用于將半結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)為文檔的一種數(shù)據(jù)庫(kù)。文檔數(shù)據(jù)庫(kù)通常以 JSON 或 XML 格式存儲(chǔ)數(shù)據(jù)。（1）由于文檔數(shù)據(jù)庫(kù)的 no-schema 特性，可以存儲(chǔ)和讀取任意數(shù)據(jù)。（2）由于使用的數(shù)據(jù)格式是 JSON 或者 BSON，因?yàn)?JSON 數(shù)據(jù)是自描述的，無(wú)需在使用前定義字段，讀取一個(gè) JSON 中不存在的字段也不會(huì)導(dǎo)致 SQL 那樣的語(yǔ)法錯(cuò)誤，可以解決關(guān)系型數(shù)據(jù)庫(kù)表結(jié)構(gòu) schema 擴(kuò)展不方便的問(wèn)題。

常見(jiàn)文檔數(shù)據(jù)庫(kù)?：MongoDB、ArangoDB

MongoDB

MongoDB 是一個(gè)基于分布式文件存儲(chǔ)的數(shù)據(jù)庫(kù)。由 C++ 語(yǔ)言編寫(xiě)。旨在為 WEB 應(yīng)用提供可擴(kuò)展的高性能數(shù)據(jù)存儲(chǔ)解決方案。MongoDB 是一個(gè)介于關(guān)系數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫(kù)當(dāng)中功能最豐富，最像關(guān)系數(shù)據(jù)庫(kù)的 NoSQL。

最佳應(yīng)用場(chǎng)景：適用于需要?jiǎng)討B(tài)查詢(xún)支持；需要使用索引而不是 map/reduce 功能；需要對(duì)大數(shù)據(jù)庫(kù)有性能要求；需要使用 CouchDB 但因?yàn)閿?shù)據(jù)改變太頻繁而占滿(mǎn)內(nèi)存的應(yīng)用程序。

例如：你本打算采用 MySQL 或 PostgreSQL，但因?yàn)樗鼈儽旧碜詭У念A(yù)定義欄讓你望而卻步。

CouchDB

CouchDB 是用 Erlang 開(kāi)發(fā)的面向文檔的分布式數(shù)據(jù)庫(kù)，用于存儲(chǔ)半結(jié)構(gòu)化的數(shù)據(jù)，比較類(lèi)似 lucene 的 index 結(jié)構(gòu)。CouchDB 支持 RESTful API，它使用 JSON 作為存儲(chǔ)格式，JavaScript 作為查詢(xún)語(yǔ)言，MapReduce 和 HTTP 作為 API 的 NoSQL 數(shù)據(jù)庫(kù)。其中一個(gè)顯著的功能就是多主復(fù)制功能。除此之外，CouchDB 構(gòu)建在強(qiáng)大的 B - 樹(shù)儲(chǔ)存引擎之上。

最佳應(yīng)用場(chǎng)景：適用于數(shù)據(jù)變化較少，執(zhí)行預(yù)定義查詢(xún)，進(jìn)行數(shù)據(jù)統(tǒng)計(jì)的應(yīng)用程序。適用于需要提供數(shù)據(jù)版本支持的應(yīng)用程序。

例如：CRM、CMS 系統(tǒng)。master-master 復(fù)制對(duì)于多站點(diǎn)部署是非常有用的。

相關(guān)特性

文檔型數(shù)據(jù)庫(kù)的相關(guān)特性，以 MongoDB 為例進(jìn)行說(shuō)明：

優(yōu)點(diǎn)

• 新增字段簡(jiǎn)單不需要像關(guān)系型數(shù)據(jù)庫(kù)一樣，先執(zhí)行 DDL 語(yǔ)句修改表結(jié)構(gòu)，程序代碼直接讀寫(xiě)即可。

• 容易兼容歷史數(shù)據(jù)。對(duì)于歷史數(shù)據(jù)，即使沒(méi)有新增的字段，也不會(huì)導(dǎo)致錯(cuò)誤，只會(huì)返回空值，此時(shí)代碼兼容處理即可。

• 易存儲(chǔ)復(fù)雜數(shù)據(jù)。JSON 是一種強(qiáng)大的描述語(yǔ)言，能夠描述復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。

缺點(diǎn)

• Atomicity（原子性）：僅支持單行 / 文檔級(jí)原子性，不支持多行、多文檔、多語(yǔ)句原子性。

• Isolation（隔離性）：隔離級(jí)別僅支持已提交讀（Read committed）級(jí)別，可能導(dǎo)致不可重復(fù)讀，幻讀的問(wèn)題。

• 不支持復(fù)雜查詢(xún)。例如 join 查詢(xún)，如果需要 join 查詢(xún)，需要多次操作數(shù)據(jù)庫(kù)。

應(yīng)用場(chǎng)景

適用場(chǎng)景

• 數(shù)據(jù)量很大或者未來(lái)會(huì)變得很大。

• 表結(jié)構(gòu)不明確，且字段在不斷增加，例如內(nèi)容管理系統(tǒng)，信息管理系統(tǒng)。

不適用場(chǎng)景

• 在不同的文檔上需要添加事務(wù)。Document-Oriented 數(shù)據(jù)庫(kù)并不支持文檔間的事務(wù)。

• 多個(gè)文檔之間需要復(fù)雜的查詢(xún)，例如 join 操作。

source:https://morning-pro.github.io/archives/7475b55d.html

喜歡，在看