CAP的崩溃
CAP猜想可是NoSQL的基石。上图非常有意思，他从CAP,和数据库种类两个方向对NoSQL进行了分类。
Consistent, Available (CA) Systems 。在分布式方面有些问题，通常是通过复制来解决的。包括
- Traditional RDBMSs like Postgres, MySQL, etc (relational)
- Vertica (column-oriented)
- Aster Data (relational)
- Greenplum (relational)
Consistent, Partition-Tolerant (CP) Systems 。可用性上有问题但是在各节点数据保存一直。包括：
- BigTable (column-oriented/tabular)
- Hypertable (column-oriented/tabular)
- HBase (column-oriented/tabular)
- MongoDB (document-oriented)
- Terrastore (document-oriented)
- Redis (key-value)
- Scalaris (key-value)
- MemcacheDB (key-value)
- Berkeley DB (key-value)
Available, Partition-Tolerant (AP) Systems 能够使用“最终一致性”保证一直。包括
- Dynamo (key-value)
- Voldemort (key-value)
- Tokyo Cabinet (key-value)
- KAI (key-value)
- Cassandra (column-oriented/tabular)
- CouchDB (document-oriented)
- SimpleDB (document-oriented)
- Riak (document-oriented)
射人先射马，擒贼先擒王。虽然CAP只是个经验性总结，但是反NoSQL的簇拥们免不了要对CAP先下毒手。
CAP的证明。大体逻辑是如果要分布式，那么更新数据的时候，要么加锁(或其他技术)保证一致，要么不加锁保证可用；如果两个都想保证，就不能分布式了。可以看得出，这个证明很粗略，没有什么数学公式啥的。自然会被人钻牛角尖。
有人说，为什么一定要加锁才能保证一致？因为数据总是以串行的进入的，所以是一致的。如果保持数据不串行进入而且同时保证一致性呢？
数据的更新不是新数据替换掉旧数 据，就算是顺序发生错误，也是一致的。在实现上可以说是数据库有一个Agent可以以一种积极的态度来防止出现非一致更新。这种系统有如下特点：
- 支持事务，每个事物都是原子操作
- 在事务提交阶段可以发现不一致现象，并加以制止
- 事务提交算法支持分布式
我觉得也可以是一种新型的数据结构实现。
所以CAP应该称为SAP
上面这段文字是从理论层面的反驳，尽管看起来头头是道。。。。说不定是个好想法，可以试一试。比如将数据库日志化，或者根据数据修改操作的唯一ID，来识别先后。再仔细想想，说不定挺有意思的。
RDBMS不具备可扩展性的谎言
刚刚的言论是对NoSQL的攻击，这里则是自保了。
可扩展性是什么？可扩展性是不是要扩展到九重天上太上老君的兜率宫？适合的才是最好的，NoSQL的适用情况并不是太多。
你不需要为了NoSQL花费100万美元。一个中级的Dell服务器就可以满足这个世界上绝大部分的应用了。只要你的应用不是Twitter和Facebook.你可以将这些4核的服务器连起来，形成一个24核的，128GB内存的运算能力，只有$15,000。这已经强大到应付绝大部分应用了。
那些NoSQL簇拥诽谤着RDBMS不具备的扩展性，其实是徒劳的。RDBMS的扩展性实用的，不是无限的。
感觉商业机密比计算能力值钱。风云莫测啊。
引用：
Getting_Real_about_NoSQL_and_the_SQL_Isnt_Scalable_Lie
Brewer's CAP Conjecture is False
visual-guide-to-nosql-systems
有人就说，为什么一定要加锁才能保证一致？因为数据总是以串行的进入的，如果是序列化，那么版本1和版本2之间就不能直接转换，他们看起来不像同一 个数据的两个版本，而像两个不同的数据。所有更新操作必须来加锁什么的，才能保证不出现脏数据什么的。如果不是序列化呢？数据的更新不是新数据替换掉旧数 据，而是一种操作。数据库有一个Agent可以以一种积极的态度来防止出现非一致更新。这种系统有如下特点：