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

四类NoSQL数据库适用场景总结
键值数据库
现在讲几个适合使用键值数据库的情况。
8.3.1 存触会话信息
通常来说,每一次网络会话都是唯一的,所以分配给它们的sess i o n i d 值也各不相同。如果应用程序原来要把s e ss i on id 存在磁盘上或关系型数据库中,那么将其迁移到键值数据库之后, 会获益良多, 因为全部会话内容都可以用一条PU T 请求来存放,而且只需一条GET 请求就能取得。由于会话中的所有信息都放在一个对象中,所以这种" 单请求操作" (s ing le-request op e rat i on ) 很迅速。许多网络应用程序都使用像Mem ca c hed 这样的解决方案。如果"可用性" 较为重要,可使用R iak .
8.3.2 用户配置信息
几乎每位用户都有userld 、usemame 或其他独特的属性, 而且其配置信息也各自独立, 诸如语言、颜色、时区、访问过的产品等。这些内容可全部放在一个对象里,以便只用一次GET 操作即获取某位用户的全部配置信息。同理,产品信息也可如此存放。
8.3.3 购物车数据
电子商务网站的用户都与其购物车相绑定。由于购物车的内容要在不同时间、不
同浏览器、不同电脑、不同会话中保持一致,所以可把购物信息放在value 属性中,并将其绑定到userid 这个键名上。此类应用程序最宜使用Riak 集群了。
8.4 不适用场合
键值数据库在某些场合下并不是最佳方案。
8.4.1 数据间关系

8.4.2 含有多项操作的事务
如果在保存多个键值对时,其中有一个关键字出错,而你又需要复原或回攘其余
操作,那么键值数据库就不是最好的解决方案。
8.4.3 查询数据
如果要根据键值对的某部分值来搜寻关键字,那么键值数据库就不是很理想了。
我们无法直接检视键值数据库中的值,除非使用某些类似Riak Search 的产品或是像Lucene[Lucene] 、So lr[S olr] 这样的"检索引擎" ( indexing engine) 。
8.4.4 操作关键字集合
由于键值数据库一次只能操作一个键,所以它无法同时操作多个关键字。假如需
要操作多个关键字,那么最好在客户端处理此问题。


文档数据库
9.3 适用案例
9.3.1 事件记录
应用程序对事件记录各有需求。在企业级解决方案中,许多不同的应用程序都需
要记录事件。文档数据库可以把所有这些不同类型的事件都存起来, 并作为事件存储的"中心数据库" (central data store) 使用。如果事件捕获的数据类型一直在变,那么就更应该用文档数据库了。可以按照触发事件的应用程序名"分片飞也可以按照order processed 或c ustomer_l ogged e 等事件类型"分片"。
9.3.2 内容管理系统及博窑平台
由于文档数据库没有"预设模式" ( predefined schema) , 而且通常支持JSON 文挡,所以它们很适合用在"内容管理系统" (content management system ) 及网站发布程序上,也可以用来管理用户评论、用户注册、用户配景和面向Web 文梢( web也cing document ) 。
9.3.3 网站分析与实时分析
文档数据库可存储实时分析数据。由于可以只更新部分文档内容,所以用它来存
储"页面浏览量" ( page view ) 或" 独立访客数" (unique v isitor ) 会非常方便,而且无需改变模式即可新增度量标准。
9.3.4 电子商务应用程序
电子商务类应用程序通常需要较为灵活的模式,以存储产品和订单。同时,它们
也需要在不做高戚本数据库重构及数据迁移(参见1 2 .3 节)的前提下进化其数据模型。
9.4 不适用场合
某些场合文档数据库井非最佳方案。
9.4.1 包含多项操作的复杂事务
文档数据库也许不适合执行"跨文挡的原子操作" (atomic cross-document
operation) ,然而像RavenDB 等文档数据库其实也支持此类操作。
9.4.2 查询持续变化的聚合结构
灵活的模式意味着数据库对模式不施加任何限制。数据以"应用程序实体"
(application ent ity) 的形式存储。如果要即时查询这些持续改变的实体,那么所用的查询命令也得不停变化( 用关系型数据库的术语讲,就是:用JOIN 语句将数据表按查询标准连接起来时,待连接的表一直在变)。由于数据保存在聚合中, 所以假如聚合的设计持续变动,那么就需要以" 最低级别的粒度" ( lowest level of granularity ) 来保存聚合了, 这实际上就等于要统一数据格式了。在这种情况下,文档数据库也许不合适。



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

10.3.3 计数器
在网络应用程序中,通常要统计某页面的访问人数并对其分类,以算出分析数据。
此时可使用CounterCo lum nType 来创建列族。
CREATE COLUMN FAMILY visit counter
WITH default_validation_class=CounterColumnType
AND key--va l Ida t lorIECla sszUTF8Type AND c。mpara 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 home = home + 1 WHERE KEY= 'mfowler '
10.3.4 限期使用
我们可能需要向用户提供试用版,或是在网站上将某个广告条显示一定时间。这
些功能可以通过" 带过期时限的列" ( e x piring co1umn ) 来完成。这种列过了给定时限后,就会由Cassandra 自动删除。这个时限叫做TTL (Time To Live ,生存时间),以秒为单位。经过TTL 指定的时长后,这种列就被删掉了。程序若检测到此列不存在,则可收回用户访问权限或移除广告条。
SET Customer( ' mfowler ' ) ( ' demo access ' ) = ' a llowe d ' WITH ttl=2592000;
10.4 不适用场合
有些问题用列族数据库来解决并不是最佳选择,例如需要以" ACI D 事务"执行写人及读取操作的系统。如果想让数据库根据查询结果来聚合数据( 例如SUM (求和〉或AVG ( 求平均值) ) , 那么得把每一行数据都读到客户端, 并在此执行操作。在开发早期原型或刚开始试探某个技术方案时,不太适合用Cassandra. 开发初期无法确定查询模式的变化情况,而查询模式一旦改变,列族的设计也要随之修改。这将阻碍产品创新团队的工作并降低开发者的生产能力。在关系型数据库中,数据模式的修改成本很高,而这却降低了查询模式的修改成本; Cassandra 则与之相反,改变其查询模式要比改变其数据模式代价更高。


图数据库

11 .3 适用案例
接下来讲一些适合使用图数据库的用例。
11.3. 1 互联数据
部署并使用图数据库来处理社交网络非常高效。社交图里并不是只能有"朋友"

11.3.2 安排运输路线、分派货物和基于位置的服务
投递过程中的每个地点或地址都是一个节点, 可以把送货员投递货物时所经全部节点建模为一张节点图。节点间关系可带有距离属性,以便高效投递货物。距离与位置属性也可用在名胜图(graph of places of interest ) 中, 这样应用程序就可向用户推荐其附近的好餐馆及娱乐场所了。还可将书店、餐馆等销售点( point of sales) 做成节点, 当用户靠近时通知他们,以提供基于位置的服务。
11.3.3 推荐引擎
在系统中创建节点与关系时, 可以用它们为客户推荐信息,例如"您的朋友也买了这件产品"或"给这些货品开发票时,通常也要为那些货品一并开票"。还可以用它们向旅行者提议: 来巴塞罗那旅游的人一般都会去看看安东尼· 高迪@ 所设计的建筑。用图数据库推荐信息时,有个副作用值得注意: 随着数据量变多,推荐信息所用的节点及关系数也激增。同一份数据可以挖掘出不同信息。例如,既可以从中看出客户总是将其与哪些产品一并购买,也可以查出与此产品一并开发票的其余产品。若两者不匹配,则可发出警示。因数据库与其他" 推荐引擎" ( recommendation engine ) 一样,也可以根据关系间的模式侦测交易欺诈( fraud in trans acti on ) 。
11 .4 不适用场合
图数据库在某些情形下也许不适用。在更新全部或某子集内的实体时就是这样。比如,在某个" 数据分析解决方案" (analytiω solution ) 中, 只要一个属性变了,全部实体就都得更新。此时图数据库的效果就不理想了,因为投有哪个简单的操作能一次性改变所有节点中的某个属性。即便数据模型适合问题领域, 某些图数据库可能也无法处理那么大的数据盘, 尤其在执行"全局图操作" (global graph operation,涉及整张图的操作)时更是如此。


相关内容推荐