总体来说，CAP原理决定了鱼肉熊掌不可兼得，必须有所取舍。数据库ACID模型保证了强一致性，但是对于大部分网站类型的应用，并不需要如此强的一致性，保证用户感知一致性就可以了，即在用户下次访问之前保证数据最终一致。还有一些应用要求Read your writes consistency，即用户对自己所做的修改即时可见，而对别人的数据则允许出现一定时间的延迟。
vector clock
vector clock相当于在数据上增加了一个版本控制。wiki上的解释：“Vector clocks is an algorithm for generating a partial ordering of events in a distributed system and detecting causality violations.”
有Sx,Sy,Sz三个节点，N=3，W=1，R=3，数据分别初始为(Sx:0),(Sy:0),(Sz:0)，数据在Sx节点发生变更，变成了D1(Sx:1)，然后又被更新变为D2(Sx:2)，此时D2(Sx:2)可以覆盖D1(Sx:1)，假设数据已经被同步到另外两个节点，这时有两个请求分别在Sy和Sz节点上更新数据，产生了新的版本D3(Sx:2,Sy:1)和D4(Sx:2,Sz:1)。此时，如果发生读操作，从三个节点上读取到不同的版本，发现D1版本不是最新的数据，而D3和D4版本都是最新的数据，这时就需要应用自己去进行合并，并由Sx节点产生了新的版本D5（Sx:3,Sy:1,Sz:1)。
存储实现
NoSQL的存储实现非常多，个人觉得比较有代表性的有：Memcachedb采用Berkley DB，TC底层采用Hash table和B-tree的结构，Bigtable和Cassandra采用的Memtable和SStable存储机制。
我想说一下Cassandra的存储机制，和数据库类似，每次写操作之前，必须首先记录到日志中，Cassandra的日志称为commitlog。Memtable是一个按照key排序的内存结构，当Memtable写满后，会刷新到磁盘上存储起来，称为SStable，SStable一旦写入，就不能修改，只能读取和追加。这种方式的优势在于将随机IO变成了顺序IO，大大提高了系统的IO能力。当读取数据时，可能需要将Memtable和SStable的数据进行合并，Cassandra使用bloom filter来快速判定一个key是否落在某个SStable中。而一旦出现Memtable中的数据丢失，则可以通过commitlog来恢复，这点很象传统的数据库。
数据库和NoSQL
能否用数据库实现NoSQL类似的应用？事实上就有人这样做，Friendfeed就用MySQL数据库来实现的。但是用关系型数据库来实现，存在几个问题：1.性能问题；2.schema无法灵活定义；3.扩展性的问题。
首先是性能问题，所有的数据库都基于存储优化，而不是基于内存优化的，也就是说数据库的最佳应用场景是具有少量内存，而具有大量外部IO的情况。就算你有足够大的cache，把所有的数据都cache到内存中，与专门设计的内存数据库或者Key-Value cache相比，依然要慢几个数量级。这是数据库内部的算法决定的，所以不要指望把数据库当cache来用，当然专门的内存数据库除外，比如Oracle timesten.
第二个问题是schema不够灵活，关系型数据库中schema是无法灵活定义的，而Cassandra这类NoSQL数据库，You can add and remove arbitrary fields on the fly。其中最根本的原因是数据库是关系型的，新增或删除列都必须影响到每个表中的每一行。而NoSQL则不需要，每一行的column都可以不同，可以说根本就不存在schema的概念。根据Bigtable的定义：A Bigtable is a sparse, distributed, persistent multidimensional sorted map。相对于Bigtable“稀疏”的概念，我们认为关系型数据库中的表是“密集”的，也可以把Bigtable理解为一张满是空洞的table。
第三扩展性问题，数据库基于ACID模型设计，保证了强一致性，必然牺牲了扩展性，虽然可以用sharding或功能分区做横向扩展，但是也让数据库退化成为一个简单的key value store。
NoSQL会取代数据库吗？
未来NoSQL会取代数据库吗？传统的关系型数据库还有优势吗？我个人认为关系型数据库至少在相当长的一段时间内，依然是主流，而且还有很大的发展空间。
首先，NoSQL的应用场景非常局限，某个类型的NoSQL仅仅针对特定类型的应用场景而设计，Cassandra在facebook用来承担inbox的搜索功能，而关系型数据库则要通用的多，也就是说NoSQL很难拿来就用，首先你必须搞清楚自己的应用场景，所以说NoSQL对于很多人来说是此之蜜糖，彼之砒霜。
第二，利用关系型数据库一样可以搭建出可以灵活扩展的架构，根据CAP原理，只要有所取舍，利用关系型数据库同样可以做到。
第三，关系型数据库厂家依然很强大，全世界有大量的用户。同时，硬件的发展更是日新月异，比如SSD的出现，就可以作为内存和磁盘之间的一层cache，甚至在不远的将来，完全替换磁盘。随着IO能力的巨大提升，数据库的性能也随着得到了更大的提升，很多现在面临的IO问题都不再是问题。而且，针对数据库的扩展性，厂家也提出了很多解决的方案，在一定程度上说，关系型数据库依然是最好的解决方案之一。
作为一名DBA，我并不担心数据库的未来，但我也不忽视NoSQL的巨大力量。有人将NoSQL解释成为Not only SQL，我想就是这个原因吧。
没有一种解决方案是完美的，架构就是有所取舍，世界也因为多样才美丽。
文章来源于领测软件测试网 https://www.ltesting.net/
