四类NoSQL数据库适用场景总结

键值数据库

适用案例

现在讲几个适合使用键值数据库的情况。

1 存触会话信息
通常来说，每一次网络会话都是唯一的，所以分配给它们的session id 值也各不相同。如果应用程序原来要把session id 存在磁盘上或关系型数据库中，那么将其迁移到键值数据库之后， 会获益良多， 因为全部会话内容都可以用一条PU T 请求来存放，而且只需一条GET 请求就能取得。由于会话中的所有信息都放在一个对象中，所以这种" 单请求操作" (single-request operation ) 很迅速。许多网络应用程序都使用像Memcached 这样的解决方案。如果"可用性" 较为重要，可使用Riak .
2 用户配置信息
几乎每位用户都有userld 、usemame 或其他独特的属性， 而且其配置信息也各自独立， 诸如语言、颜色、时区、访问过的产品等。这些内容可全部放在一个对象里，以便只用一次GET 操作即获取某位用户的全部配置信息。同理，产品信息也可如此存放。
3 购物车数据

电子商务网站的用户都与其购物车相绑定。由于购物车的内容要在不同时间、不同浏览器、不同电脑、不同会话中保持一致，所以可把购物信息放在value 属性中，并将其绑定到userid 这个键名上。此类应用程序最宜使用Riak 集群了。

不适用场合
键值数据库在某些场合下并不是最佳方案。
1 数据间关系
如果要在不向数据集之间建立关系，或是将不同的关键字集合联系起来， 那么即使某些键值数据库提供了"链接遍历"等功能，它们也不是最佳选择了。
2 含有多项操作的事务
如果在保存多个键值对时，其中有一个关键字出错，而你又需要复原或回攘其余操作，那么键值数据库就不是最好的解决方案。
3 查询数据
如果要根据键值对的某部分值来搜寻关键字，那么键值数据库就不是很理想了。
我们无法直接检视键值数据库中的值，除非使用某些类似Riak Search 的产品或是像Lucene、Solr这样的"检索引擎" ( indexing engine) 。
4 操作关键字集合
由于键值数据库一次只能操作一个键