首页 > 代码库 > NoSQL数据模型详解（二）の文档模型
NoSQL数据模型详解（二）の文档模型
背景
“文档”是文档数据库中的主要概念。此类数据库可存放并获取文档、其格式可以是XML、JSON、BSON等。这些文档具备子属性、呈现树状数据结构，可以包含映射表、集合和纯量值。数据库中的文档彼此相似，但不必完全相同。文档数据库所存放的文档，就相当于键值数据库所存放的“值”。文档数据库可以视为其值可查的键值数据库。流行的文档数据库有：MongoDB、CouchDB、Terrastore、OrientDB、RavenDB。
一致性
为了在Mongodb数据库中确保“一致性”，可以配置“副本集”也可以规定写入操作必须等待缩写数据复制到全部或给定数量的从节点之后，才可以返回。每次写入数据时，可以指定写入操作返回之前，必须将所写数据传播到多少个服务器节点上。
事务
从传统的关系型数据库角度讲，“事务”一词意味着我们先用insert、Update、delete等命令做操不同的表，然后用commit提交修改或以rollback命令回滚。NoSQL数据库通常没有这些机制：其写入操作要么成功，要么失败。“单文档级别”的“事务”叫做“原子事务”。此类数据库的“事务”一般无法执行多个操作。默认情况，所有写入操作都将顺利执行。使用WriteConcern参数可以对此微调。
可用性
“CAP定理”断言：“一致性”（consistency）、“可用性”（availability）和“分区耐受性”（Partition Tolerance）三者只可有其二。文档数据库试图用主从式数据复制技术来增强“可用性”。多个节点都保有同一份数据，即便主节点故障，客户端也依然能获取数据。应用程序代码一般不需检测主节点是否可用。mongodb通过“副本集”实现“复制”，以提供较高的“可用性”。
查询功能
各种文档数据库提供了不同的查询功能。CouchDB可通过视图查询：可用“物化视图”或“动态视图”（相当于关系型数据库中的视图，不在乎是否物化）实现复杂的文档查询。如果查询请求比较多，就不要再每次处理查询请求时进行
可扩展性
这里“扩展”一词指的是不讲数据库迁移到更大电脑的前提下，向其中新增节点或修改其内容。此处不谈如何让应用程序处理更多负载，我们关心的是数据库本身有哪些功能可提升负载处理能力。增加更多的““读取从节点”将全部读取操作都导引到从节点上，这样就可以扩展数据库应对频繁读取的能力了。
适用案例
事件记录（在企业级解决方案中，许多不同的应用程序都需要记录事件。如果事件捕获的数据类型一直在变，那么就更应该用文档数据库了）、内容管理系统及博客平台（可以用来管理用户评论、用户注册、用户配置和面向Web文档。）网站分析与实时分析（页面浏览量、独立访问客数）、电子商务应用程序。
不适用场合
包含多项操作的复杂事务（文档数据库不适合执行跨文档的原子操作，而然像RavenDB等文档数据库其实也支持此类操作）、查询持续变化的聚合结构。
NoSQL数据模型详解（二）の文档模型
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。