我自然

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