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

1、键值数据库适用案例现在讲几个适合使用键值数据库的情况1 存触会话信息 通常来说，每一次网络会话都是唯一的，所以分配给它们的 session id 值也各不 相同。如果应用程序原来要把 session id 存在磁盘上或关系型数据库中，那么将 其迁移到键值数据库之后， 会获益良多， 因为全部会话内容都可以用一条 PUT 请求来存放，而且只需一条 GET 请求就能取得。由于会话中的所有信息都放在 一个对象中， 所以这种 " 单请求操作 " (single-request operation ) 很迅速。 许多网 络应用程序都使用像 Memcached 这样的解决方案。如果 &q

2、uot;可用性 " 较为重要， 可使用 Riak .2 用户配置信息几乎每位用户都有 userld 、 usemame 或其他独特的属性， 而且其配置信息也 各自独立， 诸如语言、颜色、时区、访问过的产品等。这些内容可全部放在一 个对象里，以便只用一次 GET 操作即获取某位用户的全部配置信息。同理，产 品信息也可如此存放。3 购物车数据 电子商务网站的用户都与其购物车相绑定。 由于购物车的内容要在不同时间、 不 同浏览器、不同电脑、不同会话中保持一致，所以可把购物信息放在 value 属性 中，并将其绑定到 userid 这个键名上。此类应用程序最宜使用 Riak 集群了。不适用场

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

4、; ( indexing engine) 。4 操作关键字集合由于键值数据库一次只能操作一个键， 所以它无法同时操作多个关键字。 假如需 要操作多个关键字，那么最好在客户端处理此问题。文档数据库适用案例1 事件记录 应用程序对事件记录各有需求。 在企业级解决方案中， 许多不同的应用程序都需 要记录事件。文档数据库可以把所有这些不同类型的事件都存起来， 并作为事 件存储的 "中心数据库 " (central data store) 使用。如果事件捕获的数据类型一直 在变，那么就更应该用文档数据库了。可以按照触发事件的应用程序名"分片飞也可以按照 order proc

5、essed 或 customer_logged e 等事件类型 "分片 "。2 内容管理系统及博窑平台由于文档数据库没有 "预设模式 " ( predefined schema) ， 而且通常支持 JSON 文 挡，所以它们很适合用在 "内容管理系统 " (content management system ) 及网站 发布程序上，也可以用来管理用户评论、用户注册、用户配景和面向 Web 文档 ( web document ) 。3 网站分析与实时分析 文档数据库可存储实时分析数据。 由于可以只更新部分文档内容， 所以用它来存 储 &

6、quot;页面浏览量 " ( page view ) 或" 独立访客数 " (unique visitor ) 会非常方便，而 且无需改变模式即可新增度量标准。4 电子商务应用程序 电子商务类应用程序通常需要较为灵活的模式， 以存储产品和订单。 同时，它们 也需要在不做高戚本数据库重构及数据迁移的前提下进化其数据模型。不适用场合某些场合文档数据库井非最佳方案1 包含多项操作的复杂事务 文档数据库也许不适合执行 " 跨文挡的原子操作 " (atomic cross-document operation) ，然而像 RavenDB 等文档数据库其实

7、也支持此类操作。2 查询持续变化的聚合结构 灵活的模式意味着数据库对模式不施加任何限制。数据以 "应用程序实体 "(application entity) 的形式存储。如果要即时查询这些持续改变的实体，那么所 用的查询命令也得不停变化 ( 用关系型数据库的术语讲， 就是:用JOIN 语句将数 据表按查询标准连接起来时， 待连接的表一直在变 )。由于数据保存在聚合中， 所 以假如聚合的设计持续变动，那么就需要以 " 最低级别的粒度 " ( lowest level of granularity ) 来保存聚合了， 这实际上就等于要统一数据格式了。 在这种情

8、况下， 文档数据库也许不合适。列族数据库适用案例现在讨论几个适合用列族数据库解决的问题。1 事件记录 由于列族数据库可存放任意数据结构， 所以它很适合用来保存应用程序状态或运 行中遇到的错误等事件信息。 在企业级环境下， 所有应用程序都可以把事件写入 Cassandra 数据库。它们可以用 appname: timestamp (应用程序名 : 时间戳)作为 行键，并使用自己需要的列。由于 Cassa ndra 的写人能力可扩展，所以在事件 记录系统中使用它效果会很好。2 内容管理系统与博窑平台使用列族，可以把博文的 "标签" (tag) 、"类别" (

9、catelog、 "链接" ( link ) 和 "mckback" 等属性放在不同的列中。 评论信息既可以与上述内容放在同一行， 也 可以移到另一个 "键空间 "。同理，博客用户与实际博文亦可存于不同列族中。3 计数器在网络应用程序中，通常要统计某页面的访问人数并对其分类， 以算出分析数据。 此时可使用 CounterColum nType 来创建列族。CREATE COLUMN FAMILY visit counterWITH default_validation_class=CounterColumnTypeAND key-va

10、 l Ida t lorIECla sszUTF8Type AND。 cmpara t。r=UTF8Type J 创建好列族后，可以使用任意列记录网络应用程序中每个用户访问每一页面的次 数。INCR visit counter 'mfowler ' 1 home) BY 1 ;INCR visit counter 'mfow1er ' (products BY 1 ;I NCR visit counter'mfowler') (contactus) BY 1;也可以用 C QL 增加计数器的值 :UPDATE visi t counter SET

11、 home = home + 1 WHERE KEY= 'mfowler '4 限期使用我们可能需要向用户提供试用版， 或是在网站上将某个广告条显示一定时间。 这 些功能可以通过 " 带过期时限的列 " ( expiring column ) 来完成。这种列过了给定 时限后，就会由 Cassandra 自动删除。这个时限叫做 TTL (Time To Live， 生存时 间 )，以秒为单位。经过 TTL 指定的时长后，这种列就被删掉了。程序若检测到 此列不存在，则可收回用户访问权限或移除广告条。SET Customer( ' mfowler '

12、; ) ( ' demo access ' ) = ' allowed ' WITH ttl=2592000;不适用场合有些问题用列族数据库来解决并不是最佳选择，例如需要以 " ACID 事务"执行写 人及读取操作的系统。如果想让数据库根据查询结果来聚合数据 ( 例如 SUM (求 和或 AVG ( 求平均值) ) ， 那么得把每一行数据都读到客户端， 并在此执行 操作。在开发早期原型或刚开始试探某个技术方案时， 不太适合用 Cassandra. 开 发初期无法确定查询模式的变化情况， 而查询模式一旦改变， 列族的设计也要随 之修改。这将阻碍

13、产品创新团队的工作并降低开发者的生产能力。 在关系型数据 库 中，数据模式的修改成本很高， 而这却降低了查询模式的修改成本 ; Cassandra 则与之相反，改变其查询模式要比改变其数据模式代价更高。图数据库适用案例接下来讲一些适合使用图数据库的用例。1 互联数据 部署并使用图数据库来处理社交网络非常高效。 社交图里并不是只能有 "朋友 "这 种关系，例如也可以用它们表示雇员、雇员的学识， 以及这些雇员与其他雇员 在不同项目中的工作位置。任何富含链接关系的领域都很适合用图数据库表示。 假如同一个数据库含有不同领域 (像社交领域、空间领域、 商务领域等 )的领域 实体，而这

14、些实体之间又有关系， 那么图数据库提供的跨领域遍历功能， 可以让 这些关系变得更有价值。2 安排运输路线、分派货物和基于位置的服务 投递过程中的每个地点或地址都是一个节点， 可以把送货员投递货物时所经全 部节点建模为一张节点图。 节点间关系可带有距离属性， 以便高效投递货物。 距 离与位置属性也可用在名胜图 (graph of places of interest ) 中， 这样应用程序就 可向用户推荐其附近的好餐馆及娱乐场所了。还可将书店、餐馆等销售点 ( point of sales) 做成节点， 当用户靠近时通知他们，以提供基于位置的服务。3 推荐引擎 在系统中创建节点与关系时， 可以用

15、它们为客户推荐信息， 例如 "您的朋友也买 了这件产品 "或 "给这些货品开发票时，通常也要为那些货品一并开票 "。还可以 用它们向旅行者提议 : 来巴塞罗那旅游的人一般都会去看看安东尼 ·高迪 所 设计的建筑。用图数据库推荐信息时，有个副作用值得注意 : 随着数据量变多， 推荐信息所用的节点及关系数也激增。同一份数据可以挖掘出不同信息。例如， 既可以从中看出客户总是将其与哪些产品一并购买，也可以查出与 此产品一并 开发票的其余产品。若两者不匹配，则可发出警示。因数据库与其他 " 推荐引擎 " ( recommendation engine ) 一样，也可以根据关系间的模式侦测交易欺诈 ( fraud in transaction ) 。不适用场合 图数据库在某些情形下也许不适用。在更新