That No SQL Thing – Key/Value stores
The simplest No SQL databases are the Key/Value stores.
Concurrency –In Key/Value Store, concurrency is only applicable on a single key, and it is usually offered as either optimistic writes or as eventually consistent. In highly scalable systems, optimistic writes are often not possible, because of the cost of verifying that the value haven’t changed (assuming the value may have replicated to other machines), there for, we usually see either a key master (one machine own a key) or the eventual consistency model.
Queries – there really isn’t any way to perform a query in a key value store, except by the key. Even range queries on the key are usually not possible.
Transactions – while it is possible to offer transaction guarantees in a key value store, those are usually only offer in the context of a single key put. It is possible to offer those on multiple keys, but that really doesn’t work when you start thinking about a distributed key value store, where different keys may reside on different machines. Some data stores offer no transaction guarantees.
Scaling Up – In Key Value stores, there are two major options for scaling, the simplest one would be to shard the entire key space. That means that keys starting in A go to one server, while keys starting with B go to another server. In this system, a key is only stored on a single server. That drastically simplify things like transactions guarantees, but it expose the system for data loss if a single server goes down. At this point, we introduce replication.
Replication – In key value stores, the replication can be done by the store itself or by the client (writing to multiple servers). Replication also introduce the problem of divergent versions. In other words, two servers in the same cluster think that the value of key ‘ABC’ are two different things. Resolving that is a complex issue, the common approaches are to decide that it can’t happen (Scalaris) and reject updates where we can’t ensure non conflict or to accept all updates and ask the client to resolve them for us at a later date (Amazon Dynamo, Rhino DHT).
That No SQL Thing – Key / Value stores – Operations
复习Amazon Dynamo设计的一点分享
Eventual consistency其实是对一致性的一种延展，过程中允许部分不一致，但是在事务处理结束或者有限的时间内保持事务的一致性。一句话简单概括就是：“过程松，结果紧，最终结果必须保持一致性”。
load balance的几种模式
客户端实施load balance。采用客户端包来实现分发算法，同时配置分发节点情况。Memcached Cache客户端使用的一种基本方式。
b. 服务端硬件实现load balance。
c. 客户端改进模式。配制节点以及算法都可以采用集中的Master来管理和维护，包括心跳检测等手段由Master来实现。当然支持Master失效的容错性策略实施。
d. 服务端模式改进。采用preference list来分离接受和处理任务的节点。
首先采用A模式可以防止B模式在单点的情况下出现的不可用风险，也可以减轻高并发下单点的压力，提高效率（这点淘宝的同学有和我提到过，他们采用的“软负载”方式）。但是A模式会增加对于客户端包的依赖性，对于扩展和升级都会有一定的限制。
其次B模式是最省心的方式，扩展性也比较好，但是就是在上面提到的单点问题会有所限制。
C方式是对于A方式的一种改进，我以前的一篇文章中提到过，这样可以提高A的可扩展性以及可维护性，减小对于客户端包的依赖，但是增加了系统复杂度，同时Master也是会有单点的问题，不过问题不大（失效的情况下就是退化到了A模式）。
D方式是解决服务端简单的分发而导致处理的不均衡性，其实这种模式也可以改进客户端的算法。因为通过Hash算法未必能够将压力分摊均匀，就好比一些处理需要耗时比较久一些处理耗时比较少，系统对于key的映射不均衡等等问题，不过在Dynamo中描述的并不很明确，其中的算法还是要根据实际情况来做的。
How I learned to say ‘No’ to SQL
consistent-hashing算法
High Performance Scalable Data Stores
I Can’t Wait for NoSQL to Die
NoSQL DZone Poll Results
