溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“大數據體系概念有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
這個不同于分布式數據庫，大多數的NoSQL系統采用了更加簡單的數據模型，不管是MongoDB，Hbase，Redis，Memcache，還是其他的Nosql，都采取了【簡單數據模型】，怎么簡單？ 通常而言，每一個記錄都擁有唯一的Key，查詢的結果也就是Value，而且系統對于查詢的支持也緊緊只到了記錄級別的原子級，很少有Nosql支持外鍵和跨記錄，跨segment的關系維護，這種一次操作獲取單個記錄的約定極大的增強了系統的可擴展性，消除了分布式事務的開銷
? 通常而言，Nosql需要維護兩種數據: 元數據和應用數據，元數據是用于系統管理的，用來描述整個集群中間的狀態的信息，如整個Nsql 機群的節點數和數據映射。而應用數據，就是通常你的業務系統，實際需求使用的數據，看場合不同而不同。
弱一致性？ 為什么一致性還需要分強弱？究竟一致性分幾種，Nosql 是如何實現的？
有效的降低成本，擴大的集群整體能力。
構圖如下：
用簡單的話語來解析一致性，就是系統在執行某項的操作以后還處于一致
的狀態，比如：你更新以后，所有的用戶都該讀取到最新的值，這樣的系統被認為具有強一致性。
可用性：這個更簡單了，什么是可用？我找你NoSQL取一個值，你不能三分鐘轉圈圈還不給我吧
，這個就叫不可用，可不可用有兩個最基本的判定：
在“一定時間”，“返回一定的結果”。
在“一定的時間之內”這個是相當的有必要好的，要不然任何支付啊，交易啊，數據信息傳遞都是超時的存在。
“返回結果”，這個更加重要了，你不可能告訴前端，嘿，底層肯定會在一定時間內有動作的，但是這個動作
不給你數據，給你“excetpion...”
分區這個功能你可以完全的理解為一張大餅，被劃分為多塊，對數據的讀取仿佛就是在吃這張大餅，本質上是若干個獨立的分區，而分區之間互相連通但是沒有依賴，可以動態的加入和離開。
CAP這三大性質，是在分布式系統環境之中設計和部署時所需要考慮的單個重要的系統需求，通常而言，不能夠同時的滿足這三大性，舉一個小小的例子：來說明，看圖說話：
A，B就是兩Client，真個系統目前只有2臺機器，V0為數據，2臺機器上都有V0，是一個副本存在。
1：首先 A 更新了一下VO的值，比如更新為字符串：newString
2：既然V0跟新了，那么作為一個副本的存在，在G2上的V0也需要更新
3：正式更新：G1開始不斷的發射消息到G2
4：G2中的值被改變，并且B開始讀取到最新的一個值：newString. 圖中表示為 v1：代表 value1
ok,一切順利。如下圖所示
而現實總是太殘酷，你在更新的過程之中，過程3被中斷了。也就是數據沒有正確的被發射過去 ，此時數據就處于了一個不一致的狀態。B讀取到的數據就不是一個最新版的數據。
CAP的模型告訴了我們一個事實，要想保證容錯性質，那么就很有可能不能保證一致性。有的人會說，解決這個問題很簡單，我們對于這個傳遞更新的操作做一個 同步操作不就好了？
事實上來說，如果不加同步，G1-》G2的更新是不可知的。完全可能處于延遲，中斷的狀態。能保證“A“，”P”
當是是不能保證一直性“C">
大的情況之下，當節點的數量成百上千的時候，這個開銷被放大了，以至于服務是可用，但是沒有使用的價值了。也就是說
“A“可用性不能保證了。
三個不能同時滿足，那么我們就看看是否能夠保證簡單的滿足2個：
如果你想避免容錯性問題，最簡單的方式，當然是將所有的數據都放置在一臺機器之上，雖然無法保證
100%系統都可用，但是至少不會出現由分區帶來的效果。
放棄可用性是指在遇到了容錯性的問題的過程之中，好不猶豫的以保證容錯，一致性為先，即便服務不 能提供，即便服務肯定會超時。
放棄一致性在這里并不是指不再保證我們的多個副本之間的一致，而是指只是暫時允許不一致的狀態，在 供服務使用之前來保證最終的一致性就可以了。
“大數據體系概念有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
