大數(shù)據(jù)體系概念有哪些

本篇內(nèi)容介紹了“大數(shù)據(jù)體系概念有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

        1： 簡(jiǎn)單的數(shù)據(jù)模型

            這個(gè)不同于分布式數(shù)據(jù)庫(kù)，大多數(shù)的NoSQL系統(tǒng)采用了更加簡(jiǎn)單的數(shù)據(jù)模型，不管是MongoDB，Hbase，Redis，Memcache，還是其他的Nosql，都采取了【簡(jiǎn)單數(shù)據(jù)模型】，怎么簡(jiǎn)單？ 通常而言，每一個(gè)記錄都擁有唯一的Key，查詢的結(jié)果也就是Value，而且系統(tǒng)對(duì)于查詢的支持也緊緊只到了記錄級(jí)別的原子級(jí)，很少有Nosql支持外鍵和跨記錄，跨segment的關(guān)系維護(hù)，這種一次操作獲取單個(gè)記錄的約定極大的增強(qiáng)了系統(tǒng)的可擴(kuò)展性，消除了分布式事務(wù)的開銷

        2：元數(shù)據(jù)和應(yīng)用數(shù)據(jù)的分離

        ? 通常而言，Nosql需要維護(hù)兩種數(shù)據(jù): 元數(shù)據(jù)和應(yīng)用數(shù)據(jù)，元數(shù)據(jù)是用于系統(tǒng)管理的，用來(lái)描述整個(gè)集群中間的狀態(tài)的信息，如整個(gè)Nsql 機(jī)群的節(jié)點(diǎn)數(shù)和數(shù)據(jù)映射。而應(yīng)用數(shù)據(jù)，就是通常你的業(yè)務(wù)系統(tǒng)，實(shí)際需求使用的數(shù)據(jù)，看場(chǎng)合不同而不同。

        3：弱一致性

            弱一致性？ 為什么一致性還需要分強(qiáng)弱？究竟一致性分幾種，Nosql 是如何實(shí)現(xiàn)的？

        3：高水平擴(kuò)展能力和低端硬件集群

            有效的降低成本，擴(kuò)大的集群整體能力。

數(shù)據(jù)一致性理論

        1：CAP理論

                     1.1：CAP 概念

                       構(gòu)圖如下：

                     1.1.1 一致性：

                        用簡(jiǎn)單的話語(yǔ)來(lái)解析一致性，就是系統(tǒng)在執(zhí)行某項(xiàng)的操作以后還處于一致

的狀態(tài)，比如：你更新以后，所有的用戶都該讀取到最新的值，這樣的系統(tǒng)被認(rèn)為具有強(qiáng)一致性。

                    1.1.2：可用性

                      可用性：這個(gè)更簡(jiǎn)單了，什么是可用？我找你NoSQL取一個(gè)值，你不能三分鐘轉(zhuǎn)圈圈還不給我吧

，這個(gè)就叫不可用，可不可用有兩個(gè)最基本的判定：

                        在“一定時(shí)間”，“返回一定的結(jié)果”。

                        在“一定的時(shí)間之內(nèi)”這個(gè)是相當(dāng)?shù)挠斜匾玫?，要不然任何支付啊，交易啊，?shù)據(jù)信息傳遞都是超時(shí)的存在。

                        “返回結(jié)果”，這個(gè)更加重要了，你不可能告訴前端，嘿，底層肯定會(huì)在一定時(shí)間內(nèi)有動(dòng)作的，但是這個(gè)動(dòng)作

不給你數(shù)據(jù)，給你“excetpion...”

                    1.1.3：分區(qū)的容錯(cuò)性：

                        分區(qū)這個(gè)功能你可以完全的理解為一張大餅，被劃分為多塊，對(duì)數(shù)據(jù)的讀取仿佛就是在吃這張大餅，本質(zhì)上是若干個(gè)獨(dú)立的分區(qū)，而分區(qū)之間互相連通但是沒(méi)有依賴，可以動(dòng)態(tài)的加入和離開。

                    1.2：令人頭疼的滿足關(guān)系

                            CAP這三大性質(zhì)，是在分布式系統(tǒng)環(huán)境之中設(shè)計(jì)和部署時(shí)所需要考慮的單個(gè)重要的系統(tǒng)需求，通常而言，不能夠同時(shí)的滿足這三大性，舉一個(gè)小小的例子：來(lái)說(shuō)明，看圖說(shuō)話：

A，B就是兩Client，真?zhèn)€系統(tǒng)目前只有2臺(tái)機(jī)器，V0為數(shù)據(jù)，2臺(tái)機(jī)器上都有V0，是一個(gè)副本存在。

1：首先 A 更新了一下VO的值，比如更新為字符串：newString

2：既然V0跟新了，那么作為一個(gè)副本的存在，在G2上的V0也需要更新

3：正式更新：G1開始不斷的發(fā)射消息到G2

4：G2中的值被改變，并且B開始讀取到最新的一個(gè)值：newString. 圖中表示為 v1：代表 value1

ok,一切順利。如下圖所示

而現(xiàn)實(shí)總是太殘酷，你在更新的過(guò)程之中，過(guò)程3被中斷了。也就是數(shù)據(jù)沒(méi)有正確的被發(fā)射過(guò)去 ，此時(shí)數(shù)據(jù)就處于了一個(gè)不一致的狀態(tài)。B讀取到的數(shù)據(jù)就不是一個(gè)最新版的數(shù)據(jù)。

    CAP的模型告訴了我們一個(gè)事實(shí)，要想保證容錯(cuò)性質(zhì)，那么就很有可能不能保證一致性。有的人會(huì)說(shuō)，解決這個(gè)問(wèn)題很簡(jiǎn)單，我們對(duì)于這個(gè)傳遞更新的操作做一個(gè) 同步操作不就好了？

        事實(shí)上來(lái)說(shuō)，如果不加同步，G1-》G2的更新是不可知的。完全可能處于延遲，中斷的狀態(tài)。能保證“A“，”P”

當(dāng)是是不能保證一直性“C">

大的情況之下，當(dāng)節(jié)點(diǎn)的數(shù)量成百上千的時(shí)候，這個(gè)開銷被放大了，以至于服務(wù)是可用，但是沒(méi)有使用的價(jià)值了。也就是說(shuō)

“A“可用性不能保證了。

三個(gè)不能同時(shí)滿足，那么我們就看看是否能夠保證簡(jiǎn)單的滿足2個(gè)：

                 1.3：CAP的取舍    

                      1.3.1：放棄P -犧牲分區(qū)容錯(cuò)性

                            如果你想避免容錯(cuò)性問(wèn)題，最簡(jiǎn)單的方式，當(dāng)然是將所有的數(shù)據(jù)都放置在一臺(tái)機(jī)器之上，雖然無(wú)法保證

                    100%系統(tǒng)都可用，但是至少不會(huì)出現(xiàn)由分區(qū)帶來(lái)的效果。

                      1.3.2：放棄A-放棄可用性

                                    放棄可用性是指在遇到了容錯(cuò)性的問(wèn)題的過(guò)程之中，好不猶豫的以保證容錯(cuò)，一致性為先，即便服務(wù)不                                  能提供，即便服務(wù)肯定會(huì)超時(shí)。                        

                      1.3.3：放棄C-放棄-一致性

                             放棄一致性在這里并不是指不再保證我們的多個(gè)副本之間的一致，而是指只是暫時(shí)允許不一致的狀態(tài)，在                             供服務(wù)使用之前來(lái)保證最終的一致性就可以了。

“大數(shù)據(jù)體系概念有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！