解讀NoSQL數(shù)據(jù)庫(kù)的四大家族
在目前的企業(yè)IT架構(gòu)中，系統(tǒng)管理員以及DBA都會(huì)考慮使用NoSQL數(shù)據(jù)庫(kù)來(lái)解決RDBMS所不能解決的問(wèn)題，特別是互聯(lián)網(wǎng)行業(yè)。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)主要以表(table)的形式來(lái)存儲(chǔ)數(shù)據(jù)，而無(wú)法應(yīng)對(duì)非結(jié)構(gòu)化數(shù)據(jù)的挑戰(zhàn)。在進(jìn)行數(shù)據(jù)標(biāo)準(zhǔn)化的過(guò)程中，關(guān)系型數(shù)據(jù)庫(kù)性能遭遇了瓶頸。
NoSQL顧名思義就是Not-Only SQL，它可以作為關(guān)系型數(shù)據(jù)庫(kù)的良好補(bǔ)充。在TechTarget數(shù)據(jù)庫(kù)之前的報(bào)道中，我們也對(duì)NoSQL數(shù)據(jù)庫(kù)的應(yīng)用場(chǎng)景做了詳細(xì)的介紹。NoSQL不像傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，其種類繁多，且各有各的優(yōu)勢(shì)和缺點(diǎn)，對(duì)于DBA來(lái)說(shuō)如何區(qū)分彼此的不同是一件比較頭痛的工作。在本文中，我們就將進(jìn)一步為您接受關(guān)于NoSQL數(shù)據(jù)庫(kù)的分類以及各自的優(yōu)缺點(diǎn)。
NoSQL數(shù)據(jù)庫(kù)的四大家族
- 鍵值(Key-Value)存儲(chǔ)數(shù)據(jù)庫(kù)
這一類數(shù)據(jù)庫(kù)主要會(huì)使用到一個(gè)哈希表，這個(gè)表中有一個(gè)特定的鍵和一個(gè)指針指向特定的數(shù)據(jù)。Key/value模型對(duì)于IT系統(tǒng)來(lái)說(shuō)的優(yōu)勢(shì)在于簡(jiǎn)單、易部署。但是如果DBA只對(duì)部分值進(jìn)行查詢或更新的時(shí)候，Key/value就顯得效率低下了。
|
相關(guān)數(shù)據(jù)庫(kù) |
Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB |
|
典型應(yīng)用 |
內(nèi)容緩存，適合混合工作負(fù)載并擴(kuò)展大的數(shù)據(jù)集 |
|
數(shù)據(jù)模型 |
一系列鍵值對(duì) |
|
優(yōu)勢(shì) |
快速查詢 |
|
劣勢(shì) |
存儲(chǔ)的數(shù)據(jù)缺少結(jié)構(gòu)化 |
- 列存儲(chǔ)數(shù)據(jù)庫(kù)
這部分?jǐn)?shù)據(jù)庫(kù)通常是用來(lái)應(yīng)對(duì)分布式存儲(chǔ)的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點(diǎn)是指向了多個(gè)列。這些列是由列家族來(lái)安排的。
|
相關(guān)數(shù)據(jù)庫(kù) |
Cassandra, HBase, Riak |
|
典型應(yīng)用 |
分布式的文件系統(tǒng) |
|
數(shù)據(jù)模型 |
以列簇式存儲(chǔ)，將同一列數(shù)據(jù)存在一起 |
|
優(yōu)勢(shì) |
查找速度快，可擴(kuò)展性強(qiáng)，更容易進(jìn)行分布式擴(kuò)展 |
|
劣勢(shì) |
功能相對(duì)局限 |
- 文檔型數(shù)據(jù)庫(kù)
文檔型數(shù)據(jù)庫(kù)的靈感是來(lái)自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲(chǔ)相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結(jié)構(gòu)化的文檔以特定的格式存儲(chǔ)，比如JSON。文檔型數(shù)據(jù)庫(kù)可 以看作是鍵值數(shù)據(jù)庫(kù)的升級(jí)版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫(kù)比鍵值數(shù)據(jù)庫(kù)的查詢效率更高。
|
相關(guān)數(shù)據(jù)庫(kù) |
CouchDB、MongoDB |
|
典型應(yīng)用 |
Web應(yīng)用 |
|
數(shù)據(jù)模型 |
一系列鍵值對(duì) |
|
優(yōu)勢(shì) |
數(shù)據(jù)結(jié)構(gòu)要求不嚴(yán)格 |
|
劣勢(shì) |
查詢性能不高，而且缺乏統(tǒng)一的查詢語(yǔ)法 |
- 圖形(Graph)數(shù)據(jù)庫(kù)
圖形結(jié)構(gòu)的數(shù)據(jù)庫(kù)同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫(kù)不同，它是使用靈活的圖形模型，并且能夠擴(kuò)展到多個(gè)服務(wù)器上。NoSQL數(shù)據(jù)庫(kù)沒(méi)有標(biāo)準(zhǔn)的查詢語(yǔ)言(SQL)，因此進(jìn)行數(shù)據(jù)庫(kù)查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫(kù)都有REST式的數(shù)據(jù)接口或者查詢API。
|
相關(guān)數(shù)據(jù)庫(kù) |
Neo4J、InfoGrid、Infinite Graph |
|
典型應(yīng)用 |
社交網(wǎng)絡(luò)，推薦系統(tǒng)等。專注于構(gòu)建關(guān)系圖譜 |
|
數(shù)據(jù)模型 |
圖結(jié)構(gòu) |
|
強(qiáng)項(xiàng) |
利用圖結(jié)構(gòu)相關(guān)算法。 |
|
弱項(xiàng) |
需要對(duì)整個(gè)圖做計(jì)算才能得出結(jié)果，不容易做分布式的集群方案。 |
因此，我們總結(jié)NoSQL數(shù)據(jù)庫(kù)在以下的這幾種情況下比較適用：1、數(shù)據(jù)模型比較簡(jiǎn)單；2、需要靈活性更強(qiáng)的IT系統(tǒng)；3、對(duì)數(shù)據(jù)庫(kù)性能要求較高；4、不需要高度的數(shù)據(jù)一致性；5、對(duì)于給定key，比較容易映射復(fù)雜值的環(huán)境。
【編輯推薦】
