本篇內(nèi)容介紹了“NOSQL是什么”的有關(guān)知識,在實(shí)際案例的操作過程中,不少人都會(huì)遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
讓客戶滿意是我們工作的目標(biāo),不斷超越客戶的期望值來自于我們對這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴,公司提供的服務(wù)項(xiàng)目有:空間域名、網(wǎng)絡(luò)空間、營銷軟件、網(wǎng)站建設(shè)、安岳網(wǎng)站維護(hù)、網(wǎng)站推廣。
NoSQL 其名
在給 NoSQL 下定義之前,我們先來試著從它的名字上做一下解讀。顧名思義,NoSQL 系統(tǒng)的數(shù)據(jù)操作接口應(yīng)該是非 SQL 類型的。但在 NoSQL 社區(qū),NoSQL 被賦予了更具有包容性的含義,其意為 Not Only SQL,即 NoSQL 提供了一種與傳統(tǒng)關(guān)系型數(shù)據(jù)庫不同的存儲(chǔ)模式,這為開發(fā)者提供了關(guān)系型數(shù)據(jù)庫之外的另一種選擇。
NoSQL 的啟示
NoSQL 運(yùn)動(dòng)受到了很多相關(guān)研究論文的啟示,在所有資料中,最核心的有兩個(gè):Google 的 BigTable 論文和 Amazon 的 Dynamo 論文。
特性概述
NoSQL 系統(tǒng)舍棄了一些 SQL 標(biāo)準(zhǔn)中的功能,取而代之的是一些簡單靈活的功能。NoSQL 的構(gòu)建思想就是盡量簡化數(shù)據(jù)操作,盡量讓操作的執(zhí)行效率可預(yù)估。當(dāng)你去考查一個(gè) NoSQL 系統(tǒng)時(shí),下面的幾點(diǎn)是值得注意的。
數(shù)據(jù)模型及操作模型:你的應(yīng)用層數(shù)據(jù)模型是行、對象還是文檔型的呢?這個(gè)系統(tǒng)是否能支持你進(jìn)行一些統(tǒng)計(jì)工作呢?
可靠性:當(dāng)你更新數(shù)據(jù)時(shí),新的數(shù)據(jù)是否立刻寫到持久化存儲(chǔ)中去了?新的數(shù)據(jù)是否同步到多臺(tái)機(jī)器上了?
擴(kuò)展性:你的數(shù)據(jù)量有多大,單機(jī)是否能容下?你的讀寫量需求單機(jī)是否能支持?
分區(qū)策略:考慮到對擴(kuò)展性、可用性或者持久性的要求,你是否需要一份數(shù)據(jù)被存在多臺(tái)機(jī)器上?你是否需要知道或者說你能否知道數(shù)據(jù)在哪臺(tái)機(jī)器上?
一致性:你的數(shù)據(jù)是否被復(fù)制到了多臺(tái)機(jī)器上?這些不同節(jié)點(diǎn)的數(shù)據(jù)如何保證一致性?
事務(wù)機(jī)制:業(yè)務(wù)是否需要 ACID 事務(wù)機(jī)制?
單機(jī)性能:如果你打算持久化的將數(shù)據(jù)存在磁盤上,哪種數(shù)據(jù)結(jié)構(gòu)能滿足你的需求(你的需求是讀多還是寫多)?寫操作是否會(huì)成為磁盤瓶頸?
負(fù)載可評估:對于一個(gè)讀多寫少的應(yīng)用,諸如響應(yīng)用戶請求的網(wǎng)絡(luò)應(yīng)用,我們總會(huì)花很多精力來關(guān)注負(fù)載情況。你可能需要進(jìn)行數(shù)據(jù)規(guī)模的監(jiān)控,對多個(gè)用戶的數(shù)據(jù)進(jìn)行匯總統(tǒng)計(jì)。你的應(yīng)用場景是否需要這樣的功能呢?
NoSQL 數(shù)據(jù)模型及操作模型
數(shù)據(jù)庫的數(shù)據(jù)模型指的是數(shù)據(jù)在數(shù)據(jù)庫中的組織方式,數(shù)據(jù)庫的操作模型指的是存取這些數(shù)據(jù)的方式。通常數(shù)據(jù)模型包括關(guān)系模型、鍵值模型以及各種圖 結(jié)構(gòu)模型。操作語言可能包括 SQL、鍵值查詢及 MapReduce 等。NoSQL 通常結(jié)合了多種數(shù)據(jù)模型和操作模型,提供不一樣的架構(gòu)方式。
基于Key值存儲(chǔ)的NoSQL數(shù)據(jù)模型
在鍵值型系統(tǒng)中,復(fù)雜的聯(lián)合查詢以及滿足多個(gè)條件的數(shù)據(jù)查詢操作就不那么容易實(shí)現(xiàn)了,需要換一種思維來建立和使用鍵名。比如要獲取部門號為 20 的所有員工的信息,應(yīng)用層可以先獲取 Key 為 employee_departments:20的這個(gè)列表,然后再循環(huán)地拿這個(gè)列表中的 ID 通過獲取 employee:ID 得到所有員工的信息。
Key-Value 存儲(chǔ)
Key-Value 存儲(chǔ)可以說是最簡單的 NoSQL 存儲(chǔ),每個(gè) Key 值對應(yīng)一個(gè)任意的數(shù)據(jù)值。對 NoSQL 系統(tǒng)來說,這個(gè)任意的數(shù)據(jù)值是什么,它并不關(guān)心。比如在員工信念數(shù)據(jù)庫里,employee:30這個(gè) Key 對應(yīng)的可能就是一段包含員工所有信息的二進(jìn)制數(shù)據(jù)。這個(gè)二進(jìn)制的格式可能是 Protocol Buffer、Thrift 或者 Avro 都無所謂。
Key-結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)
Key-結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的典型代表是 redis,Redis 將 Key-Value 存儲(chǔ)的 Value 變成了結(jié)構(gòu)化的數(shù)據(jù)類型。Value 的類型包括數(shù)字、字符串、列表、集合以及有序集合。除了 set/get/delete 操作以為,Redis 還提供了很多針對以上數(shù)據(jù)類型的特殊操作,比如針對數(shù)字可以執(zhí)行增、減操作,對 list 可以執(zhí)行 push/pop 操作,通過提供這種針對單個(gè) Value 進(jìn)行的特定類型的操作,Redis 可以說實(shí)現(xiàn)了功能與性能的平衡。
Key-文檔存儲(chǔ)
Key-文檔存儲(chǔ)的代表有 CouchDB、MongoDB 和 Riak。這種存儲(chǔ)結(jié)構(gòu)下 Key-Value 的 Value 是結(jié)構(gòu)化的文檔,通常這些文檔是被轉(zhuǎn)換成 JSON 或者類似于 JSON 的結(jié)構(gòu)進(jìn)行存儲(chǔ)。文檔可以存儲(chǔ)列表,鍵值對以及層次結(jié)構(gòu)復(fù)雜的文檔。
BigTable 的列簇式存儲(chǔ)
HBase 和 Cassandra 的數(shù)據(jù)模型都借鑒自 Google 的 BigTable。這種數(shù)據(jù)模型的特點(diǎn)是列式存儲(chǔ),每一行數(shù)據(jù)的各項(xiàng)被存儲(chǔ)在不同的列中(這些列的集合稱作列簇)。而每一列中每一個(gè)數(shù)據(jù)都包含一個(gè)時(shí)間戳 屬性,這樣列中的同一個(gè)數(shù)據(jù)項(xiàng)的多個(gè)版本都能保存下來。
列式存儲(chǔ)可以這樣理解:將行 ID、列簇號,列號以及時(shí)間戳一起,組成一個(gè) Key,然后將 Value 按 Key 的順序進(jìn)行存儲(chǔ)。Key 值的結(jié)構(gòu)化使這種數(shù)據(jù)結(jié)構(gòu)能夠?qū)崿F(xiàn)一些特別的功能,最常用的就是將一個(gè)數(shù)據(jù)的多個(gè)版本存成時(shí)間戳不同的幾個(gè)值,這樣就能方便地保存歷史數(shù)據(jù)。這種結(jié)構(gòu)也能 天然地進(jìn)行高效的松散列數(shù)據(jù)(在很多行中并沒有某列的數(shù)據(jù))存儲(chǔ)。當(dāng)然,對于那些很少有某一行有 NULL 值的列,由于每一個(gè)數(shù)據(jù)必須包含列標(biāo)識,這又會(huì)造成空間的浪費(fèi)。
圖結(jié)構(gòu)存儲(chǔ)
圖結(jié)構(gòu)存儲(chǔ)是 NoSQL 的另一種存儲(chǔ)實(shí)現(xiàn)。其指導(dǎo)思想是:數(shù)據(jù)并非對等的,關(guān)系型的存儲(chǔ)或者鍵值對的存儲(chǔ),可能都不是***的存儲(chǔ)方式。圖結(jié)構(gòu)是計(jì)算機(jī)科學(xué)的基礎(chǔ)結(jié)構(gòu)之一,Neo4j 和 HyperGraphDB 是當(dāng)前***的圖結(jié)構(gòu)數(shù)據(jù)庫。
復(fù)雜查詢
在 NoSQL 存儲(chǔ)系統(tǒng)中,有很多比鍵值查找更復(fù)雜的操作。比如 MongoDB 可以在任意數(shù)據(jù)行上建立索引,可以使用 Javascript 語法設(shè)定復(fù)雜的查詢條件。BigTable 型的系統(tǒng)通常支持對單獨(dú)某一行的數(shù)據(jù)進(jìn)行遍歷,允許對單列的數(shù)據(jù)進(jìn)行按特定條件的篩選。CouchDB 允許你創(chuàng)建同一份數(shù)據(jù)的多個(gè)視圖,通過運(yùn)行 MapReduce 任務(wù)來實(shí)現(xiàn)一些更為復(fù)雜的查詢或者更新操作。很多 NoSQL 系統(tǒng)都支持與 Hadoop 或者其他 MapReduce 框架結(jié)合來進(jìn)行一些大規(guī)模數(shù)據(jù)分析工作。
事務(wù)機(jī)制
與關(guān)系型數(shù)據(jù)庫不同的是,NoSQL 系統(tǒng)通常注重性能和擴(kuò)展性,而非事務(wù)機(jī)制。傳統(tǒng)的 SQL 數(shù)據(jù)庫的事務(wù)通常都是支持 ACID 的強(qiáng)事務(wù)機(jī)制。ACID 的支持使得應(yīng)用者能夠很清楚他們當(dāng)前的數(shù)據(jù)狀態(tài)。對很多 NoSQL 系統(tǒng)來說,對性能的考慮遠(yuǎn)在 ACID 的保證之上。通常 NoSQL 系統(tǒng)僅提供行級別的原子性保證,也就是說同時(shí)對同一個(gè) Key 下的數(shù)據(jù)進(jìn)行的兩個(gè)操作,在實(shí)際執(zhí)行時(shí)是會(huì)串行的,保證了每一個(gè) Key-Value 對不會(huì)被破壞。
Schema-free 的存儲(chǔ)
還有一個(gè)很多 NoSQL 的共同點(diǎn),就是它通常并沒有強(qiáng)制的數(shù)據(jù)結(jié)構(gòu)約束。即使是在文檔型存儲(chǔ)或者列式存儲(chǔ)上,也不會(huì)要求某一個(gè)數(shù)據(jù)列在每一行數(shù)據(jù)上都必須存在。
數(shù)據(jù)可靠性
最理想的狀態(tài)是,數(shù)據(jù)庫會(huì)把所有寫操作立刻寫到持久化存儲(chǔ)的設(shè)備,同時(shí)復(fù)制多個(gè)副本到不同地理位置的不同節(jié)點(diǎn)上,以防止數(shù)據(jù)丟失。但這種對數(shù)據(jù)安全性的要求對性能是有影響的,所以不同的 NoSQL 系統(tǒng)在自身性能的考慮下,在數(shù)據(jù)安全上采取了不太一樣的策略。
單機(jī)可靠性
單機(jī)可靠性理解起來非常簡單,它的定義是寫操作不會(huì)由于機(jī)器重啟或者斷電而丟失。通常單機(jī)可靠性的保證是通過把數(shù)據(jù)寫到磁盤來完成的,而這通常會(huì)造成磁盤I/O成為整個(gè)系統(tǒng)的瓶頸。下面我們談?wù)勔恍┰趩螜C(jī)可靠性的保證下提高性能的方法。
控制fsync的調(diào)用頻率
Redis 提供了幾種對 fsync 調(diào)用頻率的控制方法。應(yīng)用開發(fā)者可以配置 Redis 在每次更新操作后都執(zhí)行一次 fsync,這樣會(huì)比較安全,當(dāng)然也就比較慢。Redis 也可以設(shè)置成N秒種調(diào)用一次 fsync,這樣性能會(huì)更好一點(diǎn)。但這樣的后果就是一旦出現(xiàn)故障,最多可能導(dǎo)致N秒內(nèi)的數(shù)據(jù)丟失。而對一些可靠性要求不太高的場合(比如僅僅把 Redis 當(dāng) Cache 用的時(shí)候),應(yīng)用開發(fā)者甚至可以直接關(guān)掉 fsync 的調(diào)用:讓操作系統(tǒng)來決定什么時(shí)候需要把數(shù)據(jù) flush 到磁盤(譯者注:這只是 Redis append only file 的機(jī)制,Redis 是可以關(guān)閉 aof 日志的,另外,Redis 本身支持將內(nèi)存中數(shù)據(jù) dump 成 rdb 文件的機(jī)制,和上面說的不是一回事)。
使用日志型的數(shù)據(jù)結(jié)構(gòu)
Cassandra、HBase、Redis 和 Riak 都會(huì)把寫操作順序的寫入到一個(gè)日志文件中。相對于存儲(chǔ)系統(tǒng)中的其他數(shù)據(jù)結(jié)構(gòu),上面說到的日志文件可以頻繁地進(jìn)行 fsync 操作,這樣就把對磁盤的隨機(jī)寫變成順序?qū)懥恕?/p>
通過合并寫操作提高吞吐性能
Cassandra 有一個(gè)機(jī)制,它會(huì)把一小段時(shí)間內(nèi)的幾個(gè)并發(fā)的寫操作放在一起進(jìn)行一次 fsync 調(diào)用,這種做法叫 group commit。
多機(jī)可靠性
由于硬件層面有時(shí)會(huì)造成無法恢復(fù)的損壞,單機(jī)可靠性的保證在這時(shí)就鞭長莫及了。對于一些重要數(shù)據(jù),跨機(jī)器做備份保存是必備的安全措施。一些 NoSQL 系統(tǒng)提供了多機(jī)可靠性的支持。
Redis 采用傳統(tǒng)的主從數(shù)據(jù)同步的方式。
MongoDB 提供了一種叫 Replica Sets 高可用架構(gòu)。
Riak、Cassandra 和 Voldemort 提供了一些更靈活的可配置策略,并提供一個(gè)可配置的參數(shù)N,代表每一個(gè)數(shù)據(jù)會(huì)被備份的份數(shù)。為了應(yīng)對整個(gè)數(shù)據(jù)中心出現(xiàn)故障的情況,需要實(shí)現(xiàn)跨數(shù)據(jù)中心的多機(jī)備份功能。
橫向擴(kuò)展帶來性能提升
橫向擴(kuò)展的目標(biāo)是達(dá)到線性的效果,即如果你增加一倍的機(jī)器,那么負(fù)載能力應(yīng)該也能相應(yīng)的增加一倍。其主要需要解決的問題是如何讓數(shù)據(jù)在多臺(tái)機(jī)器間分布,這里面涉及到分片技術(shù)。
分片的意思,就是沒有任何一臺(tái)機(jī)器可以處理所有寫請求,也沒有任何一臺(tái)機(jī)器可以處理對所有數(shù)據(jù)的讀請求。下面我們將會(huì)對 hash 分片和范圍分片兩種分片方式進(jìn)行描述。
如非必要,請勿分片
分片會(huì)導(dǎo)致系統(tǒng)復(fù)雜程度大增,所以,如果沒有必要,請不要使用分片。普通情況下,我們可以使用讀寫分離和構(gòu)建緩存的方式來緩解我們的數(shù)據(jù)讀壓力。但如果寫操作達(dá)到單點(diǎn)無法承擔(dān)的程度,那我們可能就真的需要進(jìn)行分片了。
通過協(xié)調(diào)器進(jìn)行數(shù)據(jù)分片
一種分片策略是通過引入一個(gè)中間代理層來實(shí)現(xiàn),該代理層記錄數(shù)據(jù)在各個(gè)節(jié)點(diǎn)的分布狀況,所有讀寫請求都通過代理層來做路由。比如與 CouchDB 的兩個(gè)項(xiàng)目:Lounge 和 BigCouch。類似的,Twitter 自己也實(shí)現(xiàn)了一個(gè)叫 Gizzard 的協(xié)調(diào)器,可以實(shí)現(xiàn)數(shù)據(jù)分片和備份功能。
一致性 hash 環(huán)算法
一致性 hash 是一種被廣泛應(yīng)用的技術(shù),其最早在一個(gè)叫 distributed hash tables(DHTs)的系統(tǒng)中進(jìn)行使用。那些類 Dynamo 的應(yīng)用,比如 Cassandra、Voldemort 和 Riak,基本上都使用了一致性 hash 環(huán)算法。
如圖 1 所示,一致性 hash 環(huán)算法有一個(gè) hash 函數(shù)H,所有存儲(chǔ)數(shù)據(jù)的節(jié)點(diǎn)和數(shù)據(jù)本身都可以通過這個(gè)函數(shù)算出一個(gè) hash 值,作為自己在下面環(huán)上的位置。然后每個(gè)節(jié)點(diǎn)會(huì)負(fù)責(zé)存儲(chǔ)其 hash 值到下一個(gè)節(jié)點(diǎn)間的所有數(shù)據(jù)的存儲(chǔ)。這樣使得即使節(jié)點(diǎn)數(shù)變化了,大部分?jǐn)?shù)據(jù)并不需要進(jìn)行遷移。
圖 1 一致性 hash 環(huán)算法的 hash 函數(shù)
連續(xù)范圍分區(qū)
使用連續(xù)范圍分區(qū)的方法進(jìn)行數(shù)據(jù)分片,需要我們保存一份映射關(guān)系表,標(biāo)明哪一段 Key 值對應(yīng)存在哪臺(tái)機(jī)器上。與一致性 hash 類似,連續(xù)范圍分區(qū)會(huì)把 Key 值按連續(xù)的范圍分段,每段數(shù)據(jù)會(huì)被指定保存在某個(gè)節(jié)點(diǎn)上,然后會(huì)被冗余備份到其他節(jié)點(diǎn)。
BigTable 的處理方式
Google BigTable 論文中描述了一種范圍分區(qū)方式,它將數(shù)據(jù)切分成一個(gè)個(gè)的 tablet 數(shù)據(jù)塊。每個(gè) tablet 保存一定數(shù)量的鍵值對。然后存儲(chǔ)在 Tablet 服務(wù)器上。tablet 塊的大小會(huì)保持在一定范圍,太大的塊會(huì)分裂成兩個(gè),太小的塊又會(huì)合并成一個(gè)。BigTable 通過一個(gè)叫 Chubby 的模塊來實(shí)現(xiàn)節(jié)點(diǎn)狀態(tài)檢測。類似的在 Hadoop 中有一個(gè)叫 ZooKeeper 的工具實(shí)現(xiàn)此功能。
一致性
上面講到了通過將數(shù)據(jù)冗余存儲(chǔ)到不同的節(jié)點(diǎn)來保證數(shù)據(jù)安全和減輕負(fù)載,下面我們來看看這樣做引發(fā)的一個(gè)問題:保證數(shù)據(jù)在多個(gè)節(jié)點(diǎn)間的一致性是非常困難的。在多個(gè)點(diǎn)間保持?jǐn)?shù)據(jù)的一致性的問題,也就是本章的主題。下面我們首先來看一下在著名的 CAP 理論。
一致性(C):在分布式系統(tǒng)中的所有數(shù)據(jù)備份,在同一時(shí)刻是否同樣的值。
可用性(A):在集群中一部分節(jié)點(diǎn)故障后,集群整體是否還能響應(yīng)客戶端的讀寫請求。
分區(qū)容忍性(P):集群中的某些節(jié)點(diǎn)在無法聯(lián)系后,集群整體是否還能繼續(xù)進(jìn)行服務(wù)。
而 CAP 理論就是說在分布式存儲(chǔ)系統(tǒng)中,最多只能實(shí)現(xiàn)上面的兩點(diǎn)。再加之當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問題,所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。結(jié)果就是我們只能在一致性和可用性之間進(jìn)行權(quán)衡,沒有 NoSQL 系統(tǒng)能同時(shí)保證這三點(diǎn)。
對一致性的保證,通常有強(qiáng)一致性和弱一致性的選擇,而在弱一致性里,又以最終一致性的實(shí)現(xiàn)較為普遍。
如果我們采用 NRW 的設(shè)定,N為數(shù)據(jù)需要備份的份數(shù),R為讀操作需要讀到的不同節(jié)點(diǎn)上的數(shù)據(jù)份數(shù),W為寫操作需要成功寫到不同節(jié)點(diǎn)的數(shù)據(jù)份數(shù),那么當(dāng)R+W>N時(shí),既 是強(qiáng)一致性的保證,當(dāng)R+W
“NoSQL是什么”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
文章名稱:NoSQL是什么
文章網(wǎng)址:http://chinadenli.net/article42/ppcoec.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供微信小程序、微信公眾號、服務(wù)器托管、做網(wǎng)站、ChatGPT、網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)