⑴ 什麼是CAP原理
分布式領域CAP理論，
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取捨。
關系資料庫的ACID模型擁有 高一致性 + 可用性 很難進行分區：
Atomicity原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。
Consistency一致性. 在事務開始或結束時，資料庫應該在一致狀態。
Isolation隔離層. 事務將假定只有它自己在操作資料庫，彼此不知曉。
Durability. 一旦事務完成，就不能返回。
跨資料庫事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支持2PC。因為2PC是反模式，盡量不要使用2PC，使用BASE來迴避。
BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性：
Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分資料庫)
Soft state軟狀態 狀態可以有一段時間不同步，非同步。
Eventually consistent最終一致，最終數據是一致的就可以了，而不是時時高一致。
BASE思想的主要實現有
1.按功能劃分資料庫
2.sharding碎片
BASE思想主要強調基本的可用性，如果你需要High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性為犧牲，BASE思想的方案在性能上還是有潛力可挖的。
現在Nosql運動豐富了拓展了BASE思想，可按照具體情況定製特別方案，比如忽視一致性，獲得高可用性等等，NOSQL應該有下面兩個流派：
1. Key-Value存儲，如Amaze Dynamo等，可根據CAP三原則靈活選擇不同傾向的資料庫產品。
2. 領域模型 + 分布式緩存 + 存儲 （Qi4j和NoSQL運動），可根據CAP三原則結合自己項目定製靈活的分布式方案，難度高。
這兩者共同點：都是關系資料庫SQL以外的可選方案，邏輯隨著數據分布，任何模型都可以自己持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲可以是非同步或同步，取決於對一致性的要求程度。
不同點：NOSQL之類的Key-Value存儲產品是和關系資料庫頭碰頭的產品BOX，可以適合非Java如PHP RUBY等領域，是一種可以拿來就用的產品，而領域模型 + 分布式緩存 + 存儲是一種復雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。
⑵ 什麼是NoSQL資料庫
1 理解ACID與BASE的區別（ACID是關系型資料庫強一致性的四個要求，而BASE是NoSQL資料庫通常對可用性及一致性的弱要求原則，它們的意思分別是，ACID：atomicity, consistency, isolation, rability;BASE：Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語里意為酸，BASE意思為鹼）
2 理解持久化與非持久化的區別。這么說是因為有的NoSQL系統是純內存存儲的。
3 你必須意識到傳統有關系型資料庫與NoSQL系統在數據結構上的本質區別。傳統關系型資料庫通常是基於行的表格型存儲，而NoSQL系統包括了列式存儲（Cassandra）、key/value存儲（Memcached）、文檔型存儲（CouchDB）以及圖結構存儲（Neo4j）
4與傳統關系資料庫有統一的SQL語言操作介面不同，NoSQL系統通常有自己特有的API介面。
5 在架構上，你必須搞清楚，NoSQL系統是被設計用於成百上千台機器的集群中的，而非共享型資料庫系統的架構。
6在NoSQL系統中，可能你得習慣一下不知道你的數據具體存在何處的情況。
7 在NoSQL系統中，你最好習慣它的弱一致性。」eventually consistent」(最終一致性)正是BASE原則中的重要一項。比如在Twitter，你在Followers列表中經常會感受到數據的延遲。
8 在NoSQL系統中，你要理解，很多時候數據並不總是可用的。
9 你得理解，有的方案是擁有分區容忍性的，有的方案不一定有。
⑶ 創建資料庫的五個屬性
創建資料庫的五個屬性：比如學生表存學號，姓名、年齡、性別、班級等。
選擇開始菜單中→程序→【Management SQL Server 2008】→【SQL Server Management Studio】命令，打開【SQL Server Management Studio】窗口，並使用Windows或 SQL Server身份驗證建立連接。
在【對象資源管理器】窗口中展開伺服器，然後選擇【資料庫】節點，右鍵單擊【資料庫】節點，從彈出來的快捷菜單中選擇【新建資料庫】命令。
非關系型資料庫：
隨著近些年技術方向的不斷拓展，大量的NoSql資料庫如MongoDB、Redis、Memcache出於簡化資料庫結構、避免冗餘、影響性能的表連接、摒棄復雜分布式的目的被設計。
指的是分布式的、非關系型的、不保證遵循ACID原則的數據存儲系統。NoSQL資料庫技術與CAP理論、一致性哈希演算法有密切關系。所謂CAP理論，簡單來說就是一個分布式系統不可能滿足可用性、一致性與分區容錯性這三個要求。
以上內容參考：網路-資料庫
⑷ 分布式資料庫CAP原理
C: Consistency 強一致性
A：Availability 可用性
P：Pattition tolerance 分區容錯性
一個分布式系統不可能同時滿足CAP，只能滿足兩個
CAP只能三選二
CP:單點集群，滿足一致性，可用性的系統，通常再可擴展性上不太強大 RABMS (mysql)
CP：滿足一致性，分區容忍的系統，通常性能不是特別高 redis
AP：滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些
在分布式系統中，P肯定是要滿足的；所以只會有CP AP
AP:高可用，大部分系統架構的選擇
CP：強一致性 redis MongoDb
⑸ 系統架構師知識：什麼是CAP
系統架構師知識：什麼是CAP
CAP、BASE理論是當前在互聯網領域非常流行的NoSQL的理論基礎。那麼什麼是CAP呢?我們一起來了解一下!
1、什麼是CAP
著名的CAP理論是由Brewer提出的，所謂CAP，即一致性(Consistency)、可用性(Availability)和分區容錯性(Partition Tolerance)。
(1)、Consistency(一致性)：更新操作成功並返回客戶端完成後,分布式的所有節點在同一時間的數據完全一致(All nodes see the same data at the same time)。
這里的一致性，一定要和傳統的RDBMS中的事務一致性區分開。
在傳統的RDBMS中，事務具有ACID4個屬性，即原子性(Atomicity)，一致性(Consistency)，隔離性(Isolation)和持久性(Durable)。
ACID是關系型資料庫的最基本原則，遵循ACID原則強調一致性，對成本要求很高，對性能影響很大。
a、原子性(Atomicity)：事務是一個原子操作單元，其對數據的修改，要麼全都執行，要麼全都不執行。
b、一致性(Consistency)：在事務開始和完成時，數據都必須保持一致狀態。這意味著所有相關的數據規則都必須應用於事務的修改，以保持數據的完整性;事務結束時，所有的.內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。
c、隔離性(Isolation)：資料庫系統提供一定的隔離機制，保證事務在不受外部並發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的，反之亦然。
d、持久性(Durability)：事務完成之後，它對於數據的修改是永久性的，即使出現系統故障也能夠保持。
MIT的Gilbert和Lynch在證明CAP的過程中改變了Consistency的概念，也就是將Consistency轉化為Atomic。Gilbert認為這里所說的Consistency其實就是資料庫系統中提到的ACID的另一種表述：一個用戶請求要麼成功、要麼失敗，不能處於中間狀態(Atomic);一旦一個事務完成，將來的所有事務都必須基於這個完成後的狀態(Consistent);未完成的事務不會互相影響(Isolated);一旦一個事務完成，就是持久的(Durable)。
(2)、Availability(可用性)：讀和寫操作都能成功(Reads and writes always succeed)。
可用性是說服務能一直保證是可用的狀態，當用戶發出一個請求，服務能在有限時間內返回結果，所有的請求都能“成功”拿到對應的響應。
(3)、Partition Tolerance(分區容錯性)：在出現網路故障導致分布式節點間不能通信時，系統能否繼續服務(The system continues to operate despite arbitrary message loss or failure of part of the system)。
直觀感受就是系統中節點crash或者網路分片都不應該導致一個分布式系統停止服務。
2、如何證明CAP?
CAP的證明很簡單：
假設兩個節點集{G1, G2}，由於網路分片導致G1和G2之間所有的通訊都斷開了。
如果在G1中寫，在G2中讀剛寫的數據， G2中返回的值不可能是剛剛在G1中的寫值。
對於分布式數據系統而言，分區容錯性(Partition Tolerance)是基本要求，否則就不稱其為分布式系統。
由於可用性(Availability)的要求，G2一定要返回這次讀請求，因為分區容錯性(Partition Tolerance)的存在，導致一致性(Consistency)一定是不可滿足的。
CAP理論告訴我們，一個分布式系統不可能同時滿足一致性，可用性和分區容錯性這三個需求，三個要素中最多隻能同時滿足兩點。
顯然,任何橫向擴展策略都要依賴於數據分區，軟體架構通常必須在一致性(Consistency)與可用性(Availability)之間做出選擇。
3、CAP的延伸BASE
BASE是Basically Available、Soft state、Eventually consistent三個片語的簡寫，是對CAP中C 和A的延伸。
(1)Basically Available：基本可用，即數據一致性能夠基本滿足二八定律，即至少保證80%一致性，剩下20%就不要過於糾結。
(2)Soft-state：軟狀態/柔性事務，即狀態可以有一段時間的不同步。
在不過分追求數據一致性(強一致性)前提下可考慮軟狀態策略，例如把數據(State)緩存在客戶端一段時間，在一段時間過後，如果客戶端沒有再次刷新狀態的請求的話，就清除此緩存(Soft)，這個狀態就會消失。
(3)Eventual consistency：最終一致性，即在某一段短時間內允許數據不一致，但經過一段較長時間(這里的一段時間多數是業務能夠容忍的延遲)，等所有節點上數據的拷貝都整合在一起的時候，數據會最終達到完全一致。我用自己的經驗和親身實踐證明，最終一致性貫穿著互聯網尤其是電子商務類型的主要應用的生命周期。
BASE來自於互聯網的電子商務領域的實踐，它是基於CAP理論逐步演化而來，核心思想是即便不能達到強一致性(Strong Consistency)，但可以根據應用特點採用適當的方式來達到最終一致性(Eventual consistency)的效果。BASE是反ACID的，它完全不同於ACID模型，犧牲強一致性，獲得基本可用性和柔性可靠性並要求達到最終一致性。
;⑹ 資料庫中存放的數據可以是數字也可以是文字，但不可以存放圖像和聲音，這句話對么
access資料庫中是可以存放圖像的，有一個「OLE 對象」數據類型可以存放圖片。所以這個問題如果沒有指定哪種資料庫的話，是錯的。
NoSQL資料庫技術與CAP理論、一致性哈希演算法有密切關系。所謂CAP理論，簡單來說就是一個分布式系統不可能滿足可用性、一致性與分區容錯性這三個要求，一次性滿足兩種要求是該系統的上限。
而一致性哈希演算法則指的是NoSQL資料庫在應用過程中，為滿足工作需求而在通常情況下產生的一種數據演算法，該演算法能有效解決工作方面的諸多問題但也存在弊端。
(6)資料庫cap理論擴展閱讀：
一般具有存儲、截取、安全保障、備份等基礎功能。資料庫管理系統可以依據它所支持的資料庫模型來作分類，例如關系式、XML；或依據所支持的計算機類型來作分類，例如伺服器群集、行動電話。
或依據所用查詢語言來作分類，例如SQL、XQuery；或依據性能沖量重點來作分類，例如最大規模、最高運行速度；亦或其他的分類方式。不論使用哪種分類方式，一些DBMS能夠跨類別，例如，同時支持多種查詢語言。
⑺ 關於NewSQL資料庫對於CAP的再解釋
作者 石默研
關於CAP的討論已經很多，包括作者的另一篇文章「對CAP的初步解釋」，基本已經即定思維的理解就是：分布式系統必須遵循CAP，一個分布式系統的設計只能同時滿足其中兩個，不可能同時滿足；傳統關系資料庫選擇A與C，代表了互聯網新興技術的NoSQL資料庫則選擇A與P（或者C與P，雖然這種情況其實需要詳細討論）。
但是，近年來，新興的NewSQL資料庫（TiDB或者OceanBase），則是一種在分布式環境下，保證的ACID強事務特徵的強一致性資料庫，並且很顯然，它同時也滿足了高可用性與優秀的分區可容忍性（很好的可擴展特性便是其一個層面的證明），似乎看起來，C、A、P都同時保證了，這不是違反了已經經過嚴格證明的CAP理論嗎？
這個問題初看起來，似乎是比較神奇，但仔細分析，其實答案是很明顯的。
首先，需要讀者區分「分布式」與CAP中所提到的分區可容忍性Paritition Tolerance並不是一回事。分區可容忍性P是指以下兩種分布式的情況：
. 同一份數據的多個副本的可分布性
. 有相互關聯的數據的可分布性（操作中表現為保證ACID的強分布式事務）
即使是分庫分表，如果不存在以上兩種情況，只是獨立數據在同一個節點上的情況，雖然也是分布式，但跟CAP中的P沒有半毛錢關系。
那麼，還是回到上面的問題，NewSQL資料庫，確實也是在保證了同一份數據多副本的強讀寫一致性、以及強分布式事務特性這樣的C的情況下，同時保證了A與P呀！事實確實如此，但這還是要仔細分析：
無論是TiDB，還是OceanBase，其在保證數據多副本的強一致性時，都採用了Paxos協議或者Raft，它們簡單來講就是多數選舉的原則，即寫不需要全部副本都完成，就能保證讀的強一致性，反過來也是一樣。因此，其在分布式情況下，保證數據讀寫強一致性的效率還是很高的，就是說，在同一個數據中心的網路環境下，雖然這種分布可容忍性的滿足理論上講也會比單節點多一點點效率損失，但實際上是可以忽略不計的。但需要指出的是，在跨數據中心、跨城市的分布式情況下，如果要保證數據多副本的強一致性，即保證分區可容忍性，對效率（實際上是可用性A）的影響那還是不可忽略的。因此，在這種情況下，CAP理論依然成立。
再來看相互關聯數據的可分布性，這就涉及到了分布式事務。現有的NewSQL資料庫，即使在同一數據中心，為了保證強的分布式事務，對效率的折衷都是不可忽略的，所謂的樂觀事務，只是因為客觀問題本身沖突就少，並不改變沖突很多時效率明顯受影響的現實。因此，NewSQL資料庫雖然提供強分布式事務的能力，但在現實應用中，都是提倡盡量避免大量的分布式事務出現。如果你所遇到的應用場景是確實需要大量的分布式事務執行，又不做應用優化全交給資料庫執行，那麼，現有的NewSQL分布式資料庫，依然會遇到明顯的性能問題，其實就是可用性A降低了。同學仔細去研究應用中的實際情況就會發現，很多互聯網應用，當其所需要的QPS很高很高，而對讀寫一致性與強分布式事務的要求又不那很高時候，其實，NewSQL資料庫還是不能滿足他們的需求的，他們仍然需要根據自己的情況改造或者選用NoSQL資料庫，這也是CAP理論並沒有被NewSQL打破的現實證明。
因此，總結來講，NewSQL資料庫，也是遵循CAP理論的，只不過，在同中心數據多副本情況下，保證P的同時對A的影響微乎其微；而在分布式事務的情況下，又採用了與應用特性相關的策略（其實樂觀、悲觀事務本質上就有根本應用特性區分的意思）來保證性能而已。當然，隨著網路與計算機性能的提高，CAP三個特徵中，保證其中兩個，折衷另外一個，所帶來的影響也會逐漸變小，但其理論依然是正確的。
⑻ 現在主流資料庫
主流的資料庫有：
1、MySQL
MySQL是一個關系型資料庫管理系統，由瑞典MySQL AB 公司開發，屬於Oracle旗下產品。
MySQL 是最流行的關系型資料庫管理系統之一，在 WEB 應用方面，MySQL是最好的RDBMS(Relational Database Management System，關系資料庫管理系統) 應用軟體之一。
2、SQL Server
SQL Server是Microsoft 公司推出的關系型資料庫管理系統。
具有使用方便可伸縮性好與相關軟體集成程度高等優點，可跨越從運行Microsoft Windows 98 的膝上型電腦到運行Microsoft Windows 2012 的大型多處理器的伺服器等多種平台使用。
3、Oracle Database
Oracle Database，是甲骨文公司的一款關系資料庫管理系統。
它是在資料庫領域一直處於領先地位的產品。系統可移植性好、使用方便、功能強，適用於各類大、中、小、微機環境。它是一種高效率、可靠性好的、適應高吞吐量的資料庫方案。
(8)資料庫cap理論擴展閱讀
資料庫的類型
1、關系資料庫
關系型資料庫，存儲的格式可以直觀地反映實體間的關系。關系型資料庫和常見的表格比較相似，關系型資料庫中表與表之間是有很多復雜的關聯關系的。 常見的關系型資料庫有Mysql，SqlServer等。
在輕量或者小型的應用中，使用不同的關系型資料庫對系統的性能影響不大，但是在構建大型應用時，則需要根據應用的業務需求和性能需求，選擇合適的關系型資料庫。
2、非關系型資料庫
非關系型資料庫，指的是分布式的、非關系型的、不保證遵循ACID原則的數據存儲系統。非關系型資料庫技術與CAP理論、一致性哈希演算法有密切關系。
所謂CAP理論，簡單來說就是一個分布式系統不可能滿足可用性、一致性與分區容錯性這三個要求，一次性滿足兩種要求是該系統的上限。
而一致性哈希算則指的是非關系型資料庫在應用過程中，為滿足工作需求而在通常情況下產生的一種數據演算法，該演算法能有效解決工作方面的諸多問題但也存在弊端，即工作完成質量會隨著節點的變化而產生波動，當節點過多時，相關工作結果就無法那麼准確。
⑼ cap是什麼意思譯
1、n． 帽子；蓋子；頂；上限
2、vt． 超過；加蓋於；戴帽；覆蓋；完成；設限
3、vi． 脫帽致意
cap的用法
1、讀音
英 ［kæp］；美 ［kæp］
2、例句
1）用作名詞 （n．）
The cap goes well with your suit．
這頂帽子跟你的衣服很相稱。
2）用作及物動詞S＋～＋ n．／pron．
The clouds capped the mountains．
雲籠罩了山頂。
3、短語
cock one＇s cap 歪戴帽子
lift one＇s cap 舉帽致意
put on one＇s cap 戴帽
one＇s cap 舉帽致意
(9)資料庫cap理論擴展閱讀
同近義詞hat的用法
1、讀音
英 ［hæt］；美 ［hæt］
2、短語
have one＇s hat on 戴著帽子
pull one＇s hat over one＇s eyes 用帽子遮住眼睛
put on a hat 戴上帽子
raise one＇s hat to （脫帽）向…致敬
3、區別
cap指無邊的便帽，表示職業的帽子，如運動帽、軍帽等。hat指有邊的帽子，尤指禮帽。
This hat becomes you.
這頂帽子你戴很合適。
⑽ 如何正確理解CAP理論
常見的理解及分析
目前流行的、對CAP理論解釋的情形是從同一數據在網路環境中的多個副本出發的。為了保證數據不會丟失，在企業級的數據管理方案中，一般必須考慮數據的冗餘存儲問題，而這應該是通過在網路上的其他獨立物理存儲節點上保留另一份、或多份數據副本來實現的（如附圖所示）。因為在同一個存儲節點上的數據冗餘明顯不能解決單點故障問題，這與通過多節點集群來提供更好的計算可用性的道理是相同的。
附圖 CAP理論示意圖
其實，不用做嚴格的證明也可以想見，如附圖的情況，數據在節點A、B、C上保留了三份，如果對節點A上的數據進行了修改，然後再讓客戶端通過網路對該數據進行讀取。那麼，客戶端的讀取操作什麼時候返回呢？
有這樣兩種情況：一種情況是要求節點A、B、C的三份數據完全一致後返回。也就是說，這時從任何一個網路節點讀取的數據都是一樣的，這就是所謂的強一致性讀。很明顯，這時數據讀取的Latency要高一些（因為要等數據在網路中的復制），同時A、B、C三個節點中任何一個宕機，都會導致數據不可用。也就是說，要保證強一致性，網路中的副本越多，數據的可用性就越差；
另一種情況是，允許讀操作立即返回，容忍B節點的讀取與A節點的讀取不一致的情況發生。這樣一來，可用性顯然得到了提高，網路中的副本也可以多一些，唯一得不到保證的是數據一致性。當然，對寫操作同樣也有多個節點一致性的情況，在此不再贅述。
可以看出，上述對CAP理論的解釋主要是從網路上多個節點之間的讀寫一致性出發考慮問題的。而這一點，對於關系型資料庫意味著什麼呢？當然主要是指通常所說的Standby（關於分布式事務，涉及到更多考慮，隨後討論）情況。對此，在實踐中我們大多已經採取了弱一致性的非同步延時同步方案，以提高可用性。這種情況並不存在關系型資料庫為保證C、A而放棄P的情況；而對海量數據管理的需求，關系型資料庫擴展過程中所遇到的性能瓶頸，似乎也並不是CAP理論中所描述的那種原因造成的。那麼，上述流行的說法中所描述的關系型資料庫為保證C、A而犧牲P到底是在指什麼呢？
因此，如果根據現有的大多數資料對CAP理論的如上解釋，即只將其當作分布式系統中多個數據副本之間的讀寫一致性問題的通用理論對待，那麼就可以得出結論：CAP既適用於NoSQL資料庫，也適用於關系型資料庫。它是NoSQL資料庫、關系型資料庫，乃至一切分布式系統在設計數據多個副本之間讀寫一致性問題時需要遵循的共同原則。
更深入的探究：兩種重要的分布式場景
在本文中我們要說的重點與核心是：關於對CAP理論中一致性C的理解，除了上述數據副本之間的讀寫一致性以外，分布式環境中還有兩種非常重要的場景，如果不對它們進行認識與討論，就永遠無法全面地理解CAP，當然也就無法根據CAP做出正確的解釋。但可惜的是，目前為止卻很少有人提及這兩種場景：那就是事務與關聯。
先來看看分布式環境中的事務場景。我們知道，在關系型資料庫的事務操作遵循ACID原則，其中的一致性C，主要是指一個事務中相關聯的數據在事務操作結束後是一致的。所謂ACID原則，是指在寫入/異動資料的過程中，為保證交易正確可靠所必須具備的四個特性：即原子性（Atomicity，或稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）和持久性（Durability）。
例如銀行的一個存款交易事務，將導致交易流水表增加一條記錄。同時，必須導致賬戶表余額發生變化，這兩個操作必須是一個事務中全部完成，保證相關數據的一致性。而前文解釋的CAP理論中的C是指對一個數據多個備份的讀寫一致性。表面上看，這兩者不是一回事，但實際上，卻是本質基本相同的事物：數據請求會等待多個相關數據操作全部完成才返回。對分布式系統來講，這就是我們通常所說的分布式事務問題。
眾所周知，分布式事務一般採用兩階段提交策略來實現，這是一個非常耗時的復雜過程，會嚴重影響系統效率，在實踐中我們盡量避免使用它。在實踐過程中，如果我們為了擴展數據容量將數據分布式存儲，而事務的要求又完全不能降低。那麼，系統的可用性一定會大大降低，在現實中我們一般都採用對這些數據不分散存儲的策略。
當然，我們也可以說，最常使用的關系型資料庫，因為這個原因，擴展性（分區可容忍性P）受到了限制，這是完全符合CAP理論的。但同時我們應該意識到，這對NoSQL資料庫也是一樣的。如果NoSQL資料庫也要求嚴格的分布式事務功能，情況並不會比關系型資料庫好多少。只是在NoSQL的設計中，我們往往會弱化甚至去除事務的功能，該問題才表現得不那麼明顯而已。
因此，在擴展性問題上，如果要說關系型資料庫是為了保證C、A而犧牲P，在盡量避免分布式事務這一點上來看，應該是正確的。也就是說：關系型資料庫應該具有強大的事務功能，如果分區擴展，可用性就會降低；而NoSQL資料庫乾脆弱化甚至去除了事務功能，因此，分區的可擴展性就大大增加了。
再來看看分布式環境中的關聯場景。初看起來，關系型資料庫中常用的多表關聯操作與CAP理論就更加不沾邊了。但仔細考慮，也可以用它來解釋資料庫分區擴展對關聯所帶來的影響。對一個資料庫來講，採用了分區擴展策略來擴充容量，數據分散存儲了，很顯然多表關聯的性能就會下降，因為我們必須在網路上進行大量的數據遷移操作，這與CAP理論中數據副本之間的同步操作本質上也是相同的。
因此，如果要保證系統的高可用性，需要同時實現強大的多表關系操作的關系型資料庫在分區可擴展性上就遇到了極大的限制（即使是那些採用了各種優秀解決方案的MPP架構的關系型資料庫，如TeraData，Netezza等，其水平可擴展性也是遠遠不如NoSQL資料庫的），而NoSQL資料庫則乾脆在設計上弱化甚至去除了多表關聯操作。那麼，從這一點上來理解「NoSQL資料庫是為了保證A與P，而犧牲C」的說法，也是可以講得通的。當然，我們應該理解，關聯問題在很多情況下不是並行處理的優點所在，這在很大程度上與Amdahl定律相符合。
所以，從事務與關聯的角度來關系型資料庫的分區可擴展性為什麼受限的原因是最為清楚的。而NoSQL資料庫也正是因為弱化，甚至去除了像事務與關聯（全面地講，其實還有索引等特性）等在分布式環境中會嚴重影響系統可用性的功能，才獲得了更好的水平可擴展性。
那麼，如果將事務與關聯也納入CAP理論中一致性C的范疇的話，問題就很清楚了：關於「關系型資料庫為了保證一致性C與可用性A，而不得不犧牲分區可容忍性P」的說法便是正確的了。但關於「NoSQL選擇了C與P，或者A與P」的說法則是錯誤的，所有的NoSQL資料庫在設計策略的大方向上都是選擇了A與P（雖然對同一數據多個副本的讀寫一致性問題的設計各有不同），從來沒有完全選擇C與P的情況存在。
結論
現在看來，如果理解CAP理論只是指多個數據副本之間讀寫一致性的問題，那麼它對關系型資料庫與NoSQL資料庫來講是完全一樣的，它只是運行在分布式環境中的數據管理設施在設計讀寫一致性問題時需要遵循的一個原則而已，卻並不是NoSQL資料庫具有優秀的水平可擴展性的真正原因。而如果將CAP理論中的一致性C理解為讀寫一致性、事務與關聯操作的綜合，則可以認為關系型資料庫選擇了C與A，而NoSQL資料庫則全都是選擇了A與P，但並沒有選擇C與P的情況存在。這才是用CAP理論來支持NoSQL資料庫設計正確認識。
其實，這種認識正好與被廣泛認同的NoSQL的另一個理論基礎相吻合，即與ACID對著乾的BASE（基本可用性、軟狀態與最終一致性）。因為BASE的含義正好是指「NoSQL資料庫設計可以通過犧牲一定的數據一致性和容錯性來換取高性能的保持甚至提高」，即NoSQL資料庫都應該是犧牲C來換取P，而不是犧牲A。可用性A正好是所有NoSQL資料庫都普遍追求的特性。