NoSQL运动，令人激动的发散性思维

今天我们迎来了令人激动的NoSQL运动，叫它是NoSQL或者是Not Only SQL,这个运动有一个目标，不是所有应用都是以同样方式存储和处理数据的。

存储也应该被纳入架构考虑（不是一种默认根本不需要讨论的话题），直到今天，我们还总是希望靠一种技术打遍天下，无论我们是如何处理数据，我们总是传统地将他们按关系数据库的行和列存储。

当我们讨论一个大型的写可伸缩的应用时，关系数据库把问题搞大了，规范化的数据，joins, acid事务都是在写可伸缩性上是反模式.

你也许考虑将数据库碎片sharding会解决问题（也就是将大数据划分为小数据块），当实际中最大的问题是：关系数据库并不是为这个目标设计的。

Sharding会消耗很多关系数据库本身的优点，Sharding侵扰了业务逻辑，对业务逻辑设计进行了干涉。

将多个碎片数据整合在一起并不是一件容易的事情。你只有通过增加数据库这个盒子的大小才能实现你的数据模型的垂直伸缩性。这有很多路要走，即使你能够垂直伸缩你的数据库，试图移植一下真实的巨大的MySQL数据库？
它可能花费你数天时间，这也是一些公司为什么移植到没有表结构的数据库系统原因。

对于水平伸缩，如果我们牺牲了关系数据库的规范表结构 joins和ACID，那么我们为什么还要使用关系数据库呢？

Digg正在从MySQL迁移到key-value存储Cassandra.写伸缩性在你的程序处理数据同时完成，而不是象过去程序专门处理数据，用关系数据库保存数据。

你还是能够通过实时在将主数据库复制到一个只读的从数据库，设置一个在你客户端和数据库之间智能路由。

NoSQL运动最令人激动的是每一个NOSQL数据库都代表不同的设计思维，这不像RDBMS 使用统一单一的SQL每个应用都只能采取单一的持久化方案。当然还有另外一个方向：ORM Object Relational Mapper,对象关系数据库映射。

最后，Web碎片数据的动机使我们意识到所有数据并不是一样的被处理，适合你桌面系统的存储系统并一定适合一个大型社交网站的数据处理，比如大量图片NOSQL社区提供Neo4J, 一个专门用于存储图片和查找图片的数据库。

如果你希望获得一个更大的写伸缩性，只能采取分散去集中化计算，实现最终一致性(容忍一致性上的延迟 CAP原理)， 你不可能完全满足三个条件：一致性 consistency, 可用性availability 和网络分区容错 network partition tolerance 最多只能满足其中两个，MYSQL 5就曾经试图满足这三个，但实际应用中，这三个都无法真正满足。

(关于Cassandra CouchDB MongoDB介绍)

还有其他一些方案能够满足你各种各样的架构需求，如缓存Caching, 需要支持原子push/pop 操作的的worker queues , 过程活动处理流processing activity streams, 记录数据logging data

另外一个有趣的现象是这些key-value存储数据库之间互操作性。Riak是否可以作为CouchDB 后端备份存储呢？等等，非常令人振奋地看到，这些社区的每一个产品通过协作，使整个生态系统的更有意义和更加繁荣。

翻墙看新思想原文：NOSQL Movement - Excited with the coexistence of Divergent Thoughts
[该贴被banq于2009-11-03 15:23修改过]
[该贴被admin于2009-11-03 16:40修改过]