電子發(fā)燒友App
今天和大家聊聊數(shù)據(jù)庫。
什么是數(shù)據(jù)庫？
這個(gè)問題相信對學(xué)編程的朋友們來說過于簡單了，大家想必都是增刪改查的好手。
但如果讓你說出 10 種不同類型的數(shù)據(jù)庫，閣下該如何應(yīng)對？
這篇文章，是對數(shù)據(jù)庫技術(shù)的一個(gè)小科普，希望能幫大家了解到更多元化的數(shù)據(jù)庫，便于拓寬學(xué)習(xí)思路和項(xiàng)目的技術(shù)選型。
關(guān)系型數(shù)據(jù)庫
首先是我們接觸最多的、也是入門后端必學(xué)的 關(guān)系型數(shù)據(jù)庫 。
在關(guān)系型數(shù)據(jù)庫中，數(shù)據(jù)以 表 的形式進(jìn)行組織和存儲，每個(gè)表就像一個(gè) Excel 表格，包含多個(gè) 行 和多個(gè) 列 。
就比如我們經(jīng)典的學(xué)生管理系統(tǒng)，把學(xué)生信息存儲到關(guān)系型數(shù)據(jù)庫中，結(jié)構(gòu)大概是這樣的：
| 學(xué)號 | 學(xué)生姓名 | 所屬班級號 |
|---|---|---|
| 1 | 小李 | 1 |
| 2 | 小魚 | 2 |
| 3 | 小皮 | 3 |
?
上述學(xué)生表格中，每一行代表一個(gè)學(xué)生的信息，每一列代表學(xué)生的一個(gè)屬性。我們可以使用結(jié)構(gòu)化查詢語言 SQL 來對關(guān)系型數(shù)據(jù)庫表的數(shù)據(jù)進(jìn)行靈活地查詢、選擇、過濾等。
而關(guān)系型數(shù)據(jù)庫最大的特點(diǎn)，就是表和表之間可以 存在關(guān)系 。比如學(xué)生管理系統(tǒng)中還可以有班級表，結(jié)構(gòu)如下：
?
| 班號 | 班級名稱 |
|---|---|
| 1 | 快樂班 |
| 2 | 泰酷班 |
| 3 | 躺平班 |
?
那如果我想知道某個(gè)學(xué)生所屬的班級信息，只需要在查詢時(shí)將學(xué)生表的 所屬班級號 和班級表的 班號 進(jìn)行關(guān)聯(lián)，而不用把所有表格的列存儲在一起，非常靈活。
通過 SQL 可以連接查詢多張表，得到下面的查詢結(jié)果：
| 學(xué)號 | 學(xué)生姓名 | 所屬班級號 | 班級名稱 |
|---|---|---|---|
| 1 | 小李 | 1 | 快樂班 |
| 2 | 小魚 | 2 | 泰酷班 |
| 3 | 小皮 | 3 | 躺平班 |
除了查詢靈活、數(shù)據(jù)表間存在關(guān)系外，關(guān)系型數(shù)據(jù)庫還具有很多其他的優(yōu)點(diǎn)。
比較重要的是 數(shù)據(jù)一致性 ，關(guān)系型數(shù)據(jù)庫遵循 ACID 原則（原子性、一致性、隔離性和持久性），支持事務(wù)，可以保證多個(gè)操作同時(shí)進(jìn)行時(shí)，數(shù)據(jù)的狀態(tài)保持一致。比如 A 給 B 轉(zhuǎn)賬，A 扣錢 的同時(shí) B 也會加錢，不會出現(xiàn) A 扣了錢 B 卻沒收到錢的情況。
兼顧查詢的靈活和寫入的準(zhǔn)確性，使得關(guān)系型數(shù)據(jù)庫幾乎可以被應(yīng)用于任何項(xiàng)目中！比如 CRM（客戶關(guān)系管理）和 HRM（人力資源管理）等各類管理系統(tǒng)、數(shù)據(jù)分析系統(tǒng)、金融銀行系統(tǒng)等。
比較經(jīng)典的關(guān)系型數(shù)據(jù)庫產(chǎn)品有 MySQL、Oracle、PostgreSQL、Microsoft SQL Server 等。其中，MySQL 由于開源又易學(xué)，已經(jīng)成為后端開發(fā)同學(xué)必學(xué)的數(shù)據(jù)庫技術(shù)。
關(guān)系型數(shù)據(jù)庫的底層核心實(shí)現(xiàn)是 基于關(guān)系模型的數(shù)學(xué)理論 ，最常見的實(shí)現(xiàn)方式是使用 B+ 樹來存儲索引結(jié)構(gòu)，基于其平衡性，能夠在存儲大量數(shù)據(jù)時(shí)保持高效的查詢性能，并且兼顧增刪改操作的性能。
對于大多數(shù)項(xiàng)目，用 MySQL 等關(guān)系型數(shù)據(jù)庫來存儲數(shù)據(jù)就足夠了。但關(guān)系型數(shù)據(jù)庫不是銀彈！在某些場景下，比如要存儲的數(shù)據(jù)間沒有關(guān)系時(shí)，它并不是最佳的選擇。
舉個(gè)例子，當(dāng)我們要寫一篇文章，沒有必要把數(shù)據(jù)存儲到 Excel 表格里，可能直接將單篇文本放到 Word 里會更方便閱讀和修改。
這個(gè)時(shí)候，我們就需要與之互補(bǔ)的 非關(guān)系型數(shù)據(jù)庫 。
非關(guān)系型數(shù)據(jù)庫
非關(guān)系型數(shù)據(jù)庫又叫 NoSQL。最簡單的理解方式：關(guān)系型數(shù)據(jù)庫適用于存儲相互之間 存在關(guān)系的數(shù)據(jù)表 ，那么非關(guān)系型數(shù)據(jù)庫適用于關(guān)系不強(qiáng)的、結(jié)構(gòu)相對靈活的、需要被快速訪問的數(shù)據(jù)，比如字符串、JSON 等。
實(shí)際項(xiàng)目開發(fā)中，最常用的非關(guān)系型數(shù)據(jù)庫當(dāng)屬 KV 數(shù)據(jù)庫。
KV 即 Key-Value，數(shù)據(jù)是以 鍵值對 的方式存儲在數(shù)據(jù)庫中的?？梢岳斫鉃橐粋€(gè) HashMap，數(shù)據(jù)庫中存儲的每個(gè)鍵都 唯一對應(yīng) 一個(gè)值。鍵和值都可以是任意類型的數(shù)據(jù)，例如字符串、數(shù)字、數(shù)組等，非常靈活。
比如存儲每位用戶的個(gè)人信息，結(jié)構(gòu)大概是這樣的：
由于 KV 存儲的結(jié)構(gòu)簡單清晰，我們能夠很輕松地根據(jù)某個(gè)鍵查找出對應(yīng)的值，無論是讀寫數(shù)據(jù)性能都非常高。
此外，KV 數(shù)據(jù)庫還具備良好的可擴(kuò)展性，由于數(shù)據(jù)間不存在直接關(guān)聯(lián)，我們可以把鍵值對放到多個(gè)機(jī)器上存儲，通過數(shù)據(jù)分片、負(fù)載均衡等策略來支持海量數(shù)據(jù)的高并發(fā)訪問。
由于高性能和高可擴(kuò)展性，KV 數(shù)據(jù)庫被廣泛應(yīng)用于緩存、分布式會話、分布式鎖、實(shí)時(shí)統(tǒng)計(jì)等場景。
最經(jīng)典的 KV 數(shù)據(jù)庫當(dāng)屬 Redis 了，它是開源的、基于內(nèi)存的、高性能的數(shù)據(jù)庫，不僅支持豐富的數(shù)據(jù)類型和功能，還有持久化等重要特性，也是后端同學(xué)必學(xué)的技術(shù)。其他的常用 KV 數(shù)據(jù)庫有 LevelDB、RocksDB、Apache Cassandra 等。
KV 數(shù)據(jù)庫的底層實(shí)現(xiàn)比較靈活，常見的實(shí)現(xiàn)方式是使用哈希表來存儲鍵值對。不同類型的值對應(yīng)的實(shí)現(xiàn)方式也不同，比如 Redis 的字符串存儲采用簡單動態(tài)字符串（SDS）實(shí)現(xiàn)。
解決特定問題的數(shù)據(jù)庫
相信很多同學(xué)對數(shù)據(jù)庫的印象就停留在 MySQL 和 Redis。的確，以上兩類數(shù)據(jù)庫幾乎已經(jīng)可以解決所有問題！
但是，未必是最適合的。
就像你完全可以用電腦自帶的記事本軟件來查看和編輯 HTML 網(wǎng)頁文件，但是往往會選擇一個(gè)更專業(yè)的開發(fā)工具來替代它。
數(shù)據(jù)庫也是一樣，除了傳統(tǒng)的關(guān)系和非關(guān)系型數(shù)據(jù)庫之外，還有很多用于解決特定問題的數(shù)據(jù)庫。它們往往針對特定的數(shù)據(jù)結(jié)構(gòu)和應(yīng)用場景進(jìn)行了專門的優(yōu)化和設(shè)計(jì)，能夠提供更高效快捷的數(shù)據(jù)查詢和存儲，滿足特定領(lǐng)域的需求。
比如下面 8 種數(shù)據(jù)庫：
搜索引擎數(shù)據(jù)庫
顧名思義，搜索引擎數(shù)據(jù)庫是為了實(shí)現(xiàn)搜索引擎功能的數(shù)據(jù)庫。
它適用于存儲和管理大量的文本內(nèi)容數(shù)據(jù)，并提供更快速、準(zhǔn)確、靈活的全文檢索功能。
比如想要讓用戶更輕松地在你的博客內(nèi)搜索文章，就可以使用搜索引擎數(shù)據(jù)庫。
為什么它能做到更快更靈活的搜索呢？這是因?yàn)樵谒阉饕鏀?shù)據(jù)庫中，數(shù)據(jù)一般是以 倒排索引 的方式存儲的。
倒排索引和傳統(tǒng)的關(guān)系表有什么區(qū)別呢？
以存儲博客文檔為例，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫存儲結(jié)構(gòu)是：
?
| 文檔 id | 文檔內(nèi)容 |
|---|---|
| 1 | 感謝關(guān)注魚皮 |
| 2 | 魚皮是一名程序員 |
| 3 | 感謝關(guān)注菜鳥教程 |
?
我們能夠根據(jù) id 來查找到對應(yīng)的單篇文檔，也可以通過搜索精確的關(guān)鍵詞，來查找到多篇文檔。
比如搜索 “魚皮”，能搜出文檔 1、2。
但是，如果你搜索 “魚皮程序員”，是無法得到搜索結(jié)果的，因?yàn)闆]有任何一個(gè)文檔的內(nèi)容，完全包含 “魚皮程序員” 這個(gè)詞（文檔內(nèi)容 2 只有 “魚皮”、“程序員” 這兩個(gè)詞）。
而在搜索引擎數(shù)據(jù)庫中，首先會將文檔內(nèi)容按照單詞進(jìn)行分割，也就是 分詞 。然后再構(gòu)建單詞到文檔 id 的映射，示例結(jié)構(gòu)如下：
?
| 單詞 | 文檔 id |
|---|---|
| 感謝 | 1, 3 |
| 關(guān)注 | 1, 3 |
| 魚皮 | 1, 2 |
| 程序員 | 2 |
?
有了上述的倒排索引，當(dāng)用戶搜索 “魚皮程序員” 時(shí)，搜索引擎數(shù)據(jù)庫會先對搜索詞進(jìn)行分詞，得到 “魚皮” 和 “程序員”，然后根據(jù)這兩個(gè)詞匯就能找到文檔 id 1、2 了。不用再去遍歷表內(nèi)所有的數(shù)據(jù)，實(shí)現(xiàn)了更靈活、快速的 模糊搜索 。
此外，搜索引擎數(shù)據(jù)庫還支持 相關(guān)性排序 ，能夠根據(jù)用戶的搜索詞對所有搜索結(jié)果進(jìn)行打分，把最接近的文檔排到最上面。
主流的搜索引擎數(shù)據(jù)庫技術(shù)有 Elasticsearch、Apache Solr、Apache Lucene 等，一般更建議大家學(xué)習(xí) Elasticsearch，這玩意更新迭代得老快了。
文檔數(shù)據(jù)庫
顧名思義，文檔數(shù)據(jù)庫適用于存儲和管理 半結(jié)構(gòu)化的 文檔數(shù)據(jù)，比如存儲 JSON 格式。
相比于關(guān)系型數(shù)據(jù)庫中明確定義的表格行列，文檔數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)是類似于文檔的層次化結(jié)構(gòu)，每個(gè)文檔都是獨(dú)立的，可以包含多個(gè)不同類型和格式的數(shù)據(jù)。
比如存儲博客文章，示例結(jié)構(gòu)如下：
?
| 文檔 ID | 文檔數(shù)據(jù) |
|---|---|
| 1 | {"_id": 1, "title": "文章標(biāo)題1", "content": "這是文章1的內(nèi)容"} |
| 2 | {"_id": 2, "title": "文章標(biāo)題2", "author": "程序員魚皮"} |
?
當(dāng)我們要給某個(gè)文檔新增一個(gè)字段時(shí)，不需要像關(guān)系型數(shù)據(jù)庫一樣改變表結(jié)構(gòu)，非常靈活！
除了靈活之外，文檔數(shù)據(jù)庫也有很高的可擴(kuò)展性，適用于內(nèi)容管理系統(tǒng)（比如博客）、文檔協(xié)同編輯系統(tǒng)等。
個(gè)人比較推薦學(xué)習(xí)的文檔數(shù)據(jù)庫是 MongoDB，入門難度極低，對前端同學(xué)也很友好。當(dāng)然，Couchbase 也是不錯(cuò)的。
時(shí)序數(shù)據(jù)庫
時(shí)序數(shù)據(jù)庫是一種專門用于高效存儲和處理 時(shí)間序列 的數(shù)據(jù)庫系統(tǒng)。
時(shí)間序列是指以時(shí)間作為主要維度的數(shù)據(jù)序列，即每個(gè)數(shù)據(jù)單元都包含 時(shí)間戳 。
舉個(gè)例子，在實(shí)時(shí)溫度監(jiān)測系統(tǒng)中，我們需要 每分鐘連續(xù) 收集并觀察當(dāng)前的溫度，數(shù)據(jù)結(jié)構(gòu)示例如下：
?
| 時(shí)間戳 | 設(shè)備ID | 溫度值 |
|---|---|---|
| 2023-07-01 10:00 | Device001 | 25.5 |
| 2023-07-01 10:01 | Device001 | 25.7 |
| 2023-07-01 10:02 | Device001 | 25.8 |
| 2023-07-01 10:03 | Device001 | 26.2 |
| 2023-07-01 10:04 | Device001 | 26.5 |
| 2023-07-01 10:05 | Device001 | 26.3 |
?
有了這些數(shù)據(jù)，我們就能夠按照時(shí)間范圍進(jìn)行高效查詢、聚合分析、數(shù)據(jù)可視化。
因此，時(shí)序數(shù)據(jù)庫非常適用于物聯(lián)網(wǎng)（比如傳感器數(shù)據(jù)）、日志監(jiān)控、金融交易數(shù)據(jù)分析等場景。
主流的時(shí)序數(shù)據(jù)庫技術(shù)有 InfluxDB、TimescaleDB 等。一般情況下，建議將時(shí)序數(shù)據(jù)庫配合 Grafana 監(jiān)控看板一起使用，實(shí)現(xiàn)數(shù)據(jù)存儲 + 快速可視化。
不同時(shí)序數(shù)據(jù)庫底層的存儲方式也不同，我們可以簡單理解為，時(shí)序數(shù)據(jù)庫會根據(jù) 時(shí)間 字段構(gòu)建索引，查詢時(shí)通過索引去定位實(shí)際數(shù)據(jù)。比如 InfluxDB 使用 TSM（Time-Structured Merge Tree）作為存儲引擎，底層使用 B+ 樹來存儲時(shí)間索引。
向量數(shù)據(jù)庫
向量數(shù)據(jù)庫是專門用于存儲和處理 高維向量數(shù)據(jù) 的數(shù)據(jù)庫系統(tǒng)。
什么是向量？每個(gè)向量可以表示一個(gè)實(shí)體，并且包含多個(gè)維度的數(shù)值。
舉個(gè)例子，在人臉識別系統(tǒng)中，我們可以通過人臉的 特征 來判斷是否為熟人。每張人臉圖像，都對應(yīng)一個(gè)向量；每個(gè)人臉向量有可能包含成百上千個(gè)特征，比如鼻子大小、眼睛大小等，每個(gè)特征就是一個(gè)維度。
對應(yīng)的數(shù)據(jù)結(jié)構(gòu)示例如下：
| 人臉 ID | 人臉特征向量 |
|---|---|
| 1 | [0.1, 0.2, 0.3, ..., 0.5] |
| 2 | [0.1, 0.3, 0.2, ..., 0.4] |
在上述表格中，人臉特征向量是一個(gè)浮點(diǎn)數(shù)數(shù)組。數(shù)組的每個(gè)下標(biāo)就表示一個(gè)特征（維度），比如下標(biāo) 0 的數(shù)值表示鼻子的大小，下標(biāo) 1 的數(shù)值表示眼睛大小，以此類推。。。
我們只需要對比向量，就能夠判斷出人臉的相似度。
向量數(shù)據(jù)庫能夠高效存儲多維向量數(shù)據(jù)、計(jì)算向量的相似度、并實(shí)現(xiàn)各種不同算法的相似性搜索，適用于圖像識別、特征提取和匹配、推薦系統(tǒng)等場景。值得一提的是，AI 技術(shù)的發(fā)展也帶來了一波向量數(shù)據(jù)庫技術(shù)的熱潮，可以利用向量數(shù)據(jù)庫存儲投喂給 AI 的訓(xùn)練 Embeddings 數(shù)據(jù)。
主流的向量數(shù)據(jù)庫技術(shù)有 Milvus、Pinecone、Faiss 等，有些數(shù)據(jù)庫（比如 PostgreSQL）可能也支持存儲向量類型的字段。
關(guān)于向量數(shù)據(jù)庫的底層實(shí)現(xiàn)，還是比較復(fù)雜的。類似于上面提到的時(shí)序數(shù)據(jù)庫，向量數(shù)據(jù)庫的實(shí)現(xiàn)關(guān)鍵也是索引的設(shè)計(jì)。常見的向量索引結(jié)構(gòu)有倒排索引、KD 樹、球樹等，可以理解為對相似的向量數(shù)據(jù)進(jìn)行了分組和編碼，從而實(shí)現(xiàn)更快速地檢索匹配相似向量。此外，向量數(shù)據(jù)庫往往也會采用并行計(jì)算來加速處理。
空間數(shù)據(jù)庫
空間數(shù)據(jù)庫是專門用于存儲和處理 地理空間數(shù)據(jù) 的數(shù)據(jù)庫系統(tǒng)。
地理空間數(shù)據(jù)是指基于地理 坐標(biāo)系 的 幾何對象 ，比如某個(gè)物體所處的經(jīng)緯度或三維坐標(biāo)（點(diǎn)）、某個(gè)物體的輪廓（線）、某個(gè)物體的表面（面）等。
舉個(gè)例子，假如你想存儲自己房間內(nèi)每個(gè)物體的位置信息，對應(yīng)的數(shù)據(jù)結(jié)構(gòu)可能是：
| 物體 ID | X 坐標(biāo) | Y 坐標(biāo) | Z 坐標(biāo) |
|---|---|---|---|
| 1 | 2.5 | 3.0 | 1.8 |
| 2 | 1.0 | 4.2 | 2.3 |
| 3 | 3.7 | 2.1 | 1.5 |
使用空間數(shù)據(jù)庫，能夠高效地存儲、查詢和分析空間數(shù)據(jù)，比如計(jì)算兩個(gè)空間是否相交、對路徑進(jìn)行規(guī)劃、可視化地理空間等。
空間數(shù)據(jù)庫不僅是地理信息系統(tǒng)（GIS）的核心組件，還能用于實(shí)現(xiàn)位置導(dǎo)航、城市路面規(guī)劃等場景。
對于具體的空間數(shù)據(jù)庫技術(shù)，我了解得不多，只知道可以用 PostGIS 插件來為 PostgreSQL 支持空間數(shù)據(jù)管理能力，朋友們可以幫忙補(bǔ)充下。
?
至于空間數(shù)據(jù)庫的底層實(shí)現(xiàn)，最關(guān)鍵的部分依然是索引。常見的 空間索引 結(jié)構(gòu)有 R 樹、Quadtree 等，這些結(jié)構(gòu)可以對空間數(shù)據(jù)進(jìn)行劃分、聚合和編碼，從而加速空間范圍的查詢處理。此外，空間數(shù)據(jù)庫涉及大量的空間分析算法，比如最近鄰查詢、空間關(guān)系查詢等。時(shí)間有限，不做展開說明了。
圖形數(shù)據(jù)庫
圖形數(shù)據(jù)庫是專門用于存儲和處理 圖形結(jié)構(gòu)數(shù)據(jù) 的數(shù)據(jù)庫系統(tǒng)。
注意，這里的圖形可不是三角形、長方形，而是指 由節(jié)點(diǎn)和邊構(gòu)成 的圖形結(jié)構(gòu)。
比如我們要存儲一個(gè)朋友圈關(guān)系網(wǎng)（即 FoF：朋友的朋友），對應(yīng)的圖形可能是：
上圖中，每個(gè)用戶可以表示為一個(gè)節(jié)點(diǎn)，用戶之間的好友關(guān)系可以表示為邊。
在圖形數(shù)據(jù)庫中，需要 2 個(gè)表格來存儲。
節(jié)點(diǎn)信息表：
| 節(jié)點(diǎn) id | 節(jié)點(diǎn)名 |
|---|---|
| 1 | 小王 |
| 2 | 小李 |
| 3 | 小劉 |
邊信息表：
| 邊 id | 邊類型 | 起始節(jié)點(diǎn) | 結(jié)束節(jié)點(diǎn) |
|---|---|---|---|
| 1 | 好友 | 1 | 2 |
| 2 | 好友 | 1 | 3 |
?
通過存儲這些節(jié)點(diǎn)和邊的信息，圖形數(shù)據(jù)庫就能實(shí)現(xiàn)快速 查詢及分析 朋友圈網(wǎng)中的用戶關(guān)系，并且挖掘出用戶的社交情況、和其他用戶的隱藏關(guān)系等。
由此，圖形數(shù)據(jù)庫非常適于構(gòu)建社交網(wǎng)絡(luò)關(guān)系圖譜、推薦系統(tǒng)、知識圖譜等。
比較主流的圖形數(shù)據(jù)庫有 Neo4j、TigerGraph 等，都支持復(fù)雜的圖形操作和算法、以及分布式擴(kuò)展，能夠通過并行計(jì)算加速圖形處理。
圖形數(shù)據(jù)庫的核心實(shí)現(xiàn)相信學(xué)過算法的朋友們并不陌生，主要是用了類似鄰接表、鄰接矩陣等方式實(shí)現(xiàn)節(jié)點(diǎn)和邊數(shù)據(jù)的存儲，并且通過構(gòu)建圖形索引進(jìn)行加速。
列存數(shù)據(jù)庫
這是一種 非常主流 的數(shù)據(jù)庫！區(qū)別于傳統(tǒng)的行式數(shù)據(jù)庫，列存數(shù)據(jù)庫以列作為基本的存儲單位，把每列的數(shù)據(jù)存儲在一起。
拿某公司每天的收入來舉個(gè)例子，傳統(tǒng)的行式（關(guān)系型）數(shù)據(jù)庫是這么存儲的：
| 日期 | 銷售額 | 成本 | 利潤 |
|---|---|---|---|
| 2022-01-01 | 500 | 600 | -100 |
| 2022-01-02 | 280 | 450 | -170 |
| 2022-01-03 | 290 | 480 | -190 |
而在列存數(shù)據(jù)庫中，底層大概是這么存儲的，相當(dāng)于對矩陣做了一次轉(zhuǎn)置：
| 日期 | 2022-01-01 | 2022-01-02 | 2022-01-03 |
|---|---|---|---|
| 銷售額 | 500 | 280 | 290 |
| 成本 | 600 | 450 | 480 |
| 利潤 | -100 | -170 | -190 |
這樣一來，如果我們要統(tǒng)計(jì)這幾天公司的總利潤，不需要依次讀取每一行的數(shù)據(jù)，直接 讀取所需 的利潤那一列進(jìn)行計(jì)算即可，從而提高了數(shù)據(jù)分析和聚合操作的效率。
此外，從計(jì)算機(jī)底層來分析，把相同類型的數(shù)據(jù)在同一列中連續(xù)存儲，可以實(shí)現(xiàn)更好的數(shù)據(jù)壓縮效果、節(jié)約空間。
因此，列存數(shù)據(jù)庫適用于實(shí)時(shí)數(shù)據(jù)分析、OLAP、大規(guī)模數(shù)據(jù)倉庫等場景。
比較主流的列存數(shù)據(jù)庫技術(shù)有 Apache HBase、ClickHouse、Druid 等，都是大數(shù)據(jù)方向同學(xué)的必修課。
ClickHouse 官方演示
多模數(shù)據(jù)庫
最后要講的數(shù)據(jù)庫也最特別，區(qū)別于上面所有存儲單一數(shù)據(jù)模型的數(shù)據(jù)庫，多模數(shù)據(jù)庫能夠 同時(shí)存儲處理多種不同類型的數(shù)據(jù) ，比如關(guān)系型數(shù)據(jù)、文檔數(shù)據(jù)、圖形數(shù)據(jù)等，非常靈活。
就拿大家學(xué)編程時(shí)最常做的電商系統(tǒng)來舉例。如果沒有多模數(shù)據(jù)庫，你要用關(guān)系型數(shù)據(jù)庫來存儲商品簡略信息（比如商品名稱、價(jià)格），要用文檔數(shù)據(jù)庫來存儲可能長達(dá)幾十頁的商品詳情，要用圖數(shù)據(jù)庫來存儲商品推薦關(guān)系。每次看數(shù)據(jù)庫信息時(shí)，要分別到三個(gè)數(shù)據(jù)庫中查看。
如果使用多模數(shù)據(jù)庫，可以直接在同一個(gè)數(shù)據(jù)庫里統(tǒng)一存儲和管理不同類型的數(shù)據(jù)，非常方便。
此外，多模數(shù)據(jù)庫還支持事務(wù)，能夠更輕松地實(shí)現(xiàn)數(shù)據(jù)的一致性和完整性，不需要手動實(shí)現(xiàn)跨庫事務(wù)、跨庫數(shù)據(jù)同步等等。
比較常用的多模態(tài)數(shù)據(jù)庫技術(shù)有 ArangoDB、OrientDB 等，不過一般情況下，我們在開發(fā)中也很少會用到這種數(shù)據(jù)庫，感興趣的話再學(xué)習(xí)即可。
編輯：黃飛
?
工商網(wǎng)監(jiān)
評論