在传统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技术看，充分说明了这个技术要从思想走到实现，存在非常多的技术设计难点，要搞定这些设计难点绝无易事，但值得庆幸的，已经有人做到了，而且还在不断的完善它。