四类NoSQL数据库适用场景总结.docx
文本预览下载声明
键值 HYPERLINK /base/14 \o MySQL知识库 \t _blank 数据库
适用案例
现在讲几个适合使用键值数据库的情况。
1 存触会话信息
通常来说,每一次网络会话都是唯一的,所以分配给它们的session id 值也各不相同。如果应用程序原来要把session id 存在磁盘上或关系型数据库中,那么将其迁移到键值数据库之后, 会获益良多, 因为全部会话内容都可以用一条PUT 请求来存放,而且只需一条GET 请求就能取得。由于会话中的所有信息都放在一个对象中,所以这种 单请求操作 (single-request operation ) 很迅速。许多网络应用程序都使用像Memcached 这样的解决方案。如果可用性 较为重要,可使用Riak .2 用户配置信息几乎每位用户都有userld 、usemame 或其他独特的属性, 而且其配置信息也各自独立, 诸如语言、颜色、时区、访问过的产品等。这些内容可全部放在一个对象里,以便只用一次GET 操作即获取某位用户的全部配置信息。同理,产品信息也可如此存放。3 购物车数据
电子商务网站的用户都与其购物车相绑定。由于购物车的内容要在不同时间、不同浏览器、不同电脑、不同会话中保持一致,所以可把购物信息放在value 属性中,并将其绑定到userid 这个键名上。此类应用程序最宜使用Riak 集群了。
不适用场合键值数据库在某些场合下并不是最佳方案。1 数据间关系如果要在不向数据集之间建立关系,或是将不同的关键字集合联系起来, 那么即使某些键值数据库提供了链接遍历等功能,它们也不是最佳选择了。2 含有多项操作的事务如果在保存多个键值对时,其中有一个关键字出错,而你又需要复原或回攘其余操作,那么键值数据库就不是最好的解决方案。3 查询数据如果要根据键值对的某部分值来搜寻关键字,那么键值数据库就不是很理想了。我们无法直接检视键值数据库中的值,除非使用某些类似Riak Search 的产品或是像Lucene、Solr这样的检索引擎 ( indexing engine) 。4 操作关键字集合由于键值数据库一次只能操作一个键,所以它无法同时操作多个关键字。假如需要操作多个关键字,那么最好在客户端处理此问??。文档数据库适用案例1 事件记录应用程序对事件记录各有需求。在企业级解决方案中,许多不同的应用程序都需要记录事件。文档数据库可以把所有这些不同类型的事件都存起来, 并作为事件存储的中心数据库 (central data store) 使用。如果事件捕获的数据类型一直在变,那么就更应该用文档数据库了。可以按照触发事件的应用程序名分片飞也可以按照order processed 或customer_logged e 等事件类型分片。2 内容管理系统及博窑平台由于文档数据库没有预设模式 ( predefined schema) , 而且通常支持JSON 文挡,所以它们很适合用在内容管理系统 (content management system ) 及网站发布程序上,也可以用来管理用户评论、用户注册、用户配景和面向Web 文档( web document ) 。3 网站分析与实时分析文档数据库可存储实时分析数据。由于可以只更新部分文档内容,所以用它来存储页面浏览量 ( page view ) 或 独立访客数 (unique visitor ) 会非常方便,而且无需改变模式即可新增度量标准。4 电子商务应用程序电子商务类应用程序通常需要较为灵活的模式,以存储产品和订单。同时,它们也需要在不做高戚本数据库重构及数据迁移的前提下进化其数据模型。
不适用场合某些场合文档数据库井非最佳方案。1 包含多项操作的复杂事务文档数据库也许不适合执行跨文挡的原子操作 (atomic cross-document operation) ,然而像RavenDB 等文档数据库其实也支持此类操作。2 查询持续变化的聚合结构灵活的模式意味着数据库对模式不施加任何限制。数据以应用程序实体(application entity) 的形式存储。如果要即时查询这些持续改变的实体,那么所用的查询命令也得不停变化( 用关系型数据库的术语讲,就是:用JOIN 语句将数据表按查询标准连接起来时,待连接的表一直在变)。由于数据保存在聚合中, 所以假如聚合的设计持续变动,那么就需要以 最低级别的粒度 ( lowest level of granularity ) 来保存聚合了, 这实际上就等于要统一数据格式了。在这种情况下,文档数据库也许不合适。
列族数据库
适用案例现在讨论几个适合用列族数据库解决的问题。1 事件记录由于列族数据库可存放任意数据结构,所以它很
显示全部