在傳統RDBM系統中，對於事務處理必須保證爲一個完整的邏輯處理過程，具備ACID四個特性，A Atonomy 事務處理的原子性，要麼成功，要麼失敗 ，C Consistency 一致性，數據庫必須保持原有約束的關係，數據之間必須符合數據完整性，I Isolation 事務處理必須要彼此隔離，由RDBM保證能夠併發處理事務，而不需要用戶顯示的干預，D Durability 數據能夠被持久化下來，不會出現事務涉及數據丟失的情況。此4個特性是RDBM系統的基礎要素和必須遵循的原則。
事物總是發展的，人類社會信息總量在不斷增大，對於RDBM系統管理的數據容量已經從GB級別演進到TB級別，又從TB級別演進到PB級別，數據量不斷增大，原有的RDBM已經力不從心。如何解決該問題？
軟件設計很多思想都來自於建築領域，先回到建築領域，房屋建造有2要素，建築高度、基礎構造，建築高度決定基礎構造，而基礎構造又會影響到建築高度，建設一棟三層小房，專混結構就可以了，建設十一層房子，就需要上框架結構，摩天大樓，需要採用鋼和框架的混合結構方式來支撐。軟件設計也有相同的道理，也存在2個要素，一個容量要素，軟件能夠管理多少數據規模，一個是軟件構造要素，軟件運行的物理硬件、操作系統、採用何種架構來組織軟件各功能模塊。二者對應關係，“建築高度”對應於“容量”，“基礎構造”對應於“軟件構造”，但是，二者有所不同，由於建築物需要考慮成本、實用性、安全性和各種限制，建築高度一定是有限的，總有一個極限，而軟件則有所不同，一個大容量系統數據量已經從GB級增加到了TB級，從TB級到PB級，躍升了6個數量級，軟件容量呈現指數級的增加，使得軟件設計面臨比建築領域更大的挑戰。
如何解決數據容量持續增加帶來的挑戰，第一 提升系統的計算能力，可以並行對應數據進行分區域或者分塊計算，然後對應計算結果進行彙集處理，第二 提升數據的讀取速度，單存儲節點的讀取速度必定存在限制，需要指出多存儲節點的DB系統，分佈式數據庫DDBS系統誕生了，分佈式數據庫系統可以支持多個存儲節點，從GOOGLE的BIGTBALE數據庫原理相對應的HBASE數據庫，就可以支持多個存儲節點，存儲節點的數量可以根據要求進行擴展，無理論上限。但是分佈式數據庫採用對存儲節點構造後，帶來了一個新的問題，這個問題就是CAP理論的魔咒，CAP爲英文Consistent、Availablity、Partition Tolerance 的縮寫，一致性，可用性、分區容忍性，通常認爲CAP理論是隻能滿足二個要求，不可兼得（這種限制，其實已經被GOOGLE的SPanner系統打破）。常見的DDBS系統可以保證AP，但是無法保證C，一致性，比如HBASE數據庫，就無法保證多個存儲區域的外部事務的一致性，如果數據跨了多個存儲節點，數據可能存在衝突的可能，不一致的可能，無法做到數據表外的事務支持。ACID特性是一個數據庫完美解決的要求，但DDBS要滿足ACID特性中的原子性和各存儲節點數據的外部一致性存在很大的困難，如果對二種不同的特徵描述進行關聯， AC---Consistent 事務的原子性和一致性對應於DDBS一致性屬性要求，ID---Availablity,事務的隔離性和持久化對應於DDBS可用性屬性要求，而DDBS的Partition Tolerance會帶來滿足AC或者ID屬性的困難，因此很多DDBS會進行特性取捨。
因此，如果讓DDBS系統，使之完全滿足ACID的特性，必須要解決數據Partition後帶來的困難，數據分成多個存儲節點，如何在滿足事務隔離和持久化特性的基礎上，保證這些不同存儲節點上的數據一致性可用性，讓DDBS呈現出完全的ACID特性，打破CAP的魔咒，最常用的方式是不同數據節點的同步和全局鎖控制，如果採用這種控制機制，必然會帶來系統網絡同步開銷增加，系統的Availability能力下降，而且會出現全局鎖瓶頸點，影響到系統的擴展性，出現擴展後的瓶頸點，因此這條解決方案很難走通。那我們是否能夠從不一致和不確定基礎上，構造出一個可靠和確定的DDBS系統，GOOGLE的SPanner數據庫設計思想爲解決該問題帶來的新的希望，以一種全新的視角和思路來解決該問題，在可以期待的將來，開源社區也能夠出現與SPanner方式對應的產品出現，使得DDBS系統應用範圍更加寬廣。
綜上所述，從CAP特性理論看，面對傳統的權威理論，技術上要敢於去挑戰，勇於分析，可以另闢蹊徑解決技術問題，解決這些問題最大困難還是改善軟件開發人員的認識，一旦認識成爲定勢，勢必陷入到死衚衕中，同時必須具備深厚的技術功底和高超編程技巧，從開源社區現在還缺乏類似於Spanner技術看，充分說明了這個技術要從思想走到實現，存在非常多的技術設計難點，要搞定這些設計難點絕無易事，但值得慶幸的，已經有人做到了，而且還在不斷的完善它。