数据模型

 数据模型

什么是数据模型？

 访问数据库中数据的方式取决于此数据库所采用的数据模型。数据模型 影响着 客户端处理数据所能使用的操作 以及 可以使用的API。不同的数据模型都或多或少的提供了一些原始功能。通常，数据模型提供越少的功能，那么客户端应用程序就必须做更多的事。
 数据模型决定了 在数据存储时客户端编码数据的方式。应用程序 将有一些自然模型 能够映射到 存储技术支持的事情。
 直到现在，占据主导地位的数据模型还是 关系型数据模型，参考文档也已经十分健全。我这里将会重点介绍除关系型数据模型之外的一些数据模型，但是为了保持完整性，我还是会对关系型数据模型做个简单的描述，毕竟它为其他的数据模型做了一个很好的参照。

数据模型

1、关系型数据存储

 关系型模型通过“元”的概念来存储记录。记录存在于表（table）中。表由schema所定义，schema决定了表中有哪些列。每一列均有一个私有的名字和类型。表中所有的数据均按照表的定义来存储。SQL就是专门为了查询表中的数据而设计的一种查询语言。SQL提供了相关语法来寻找符合查询要求的数据，同时也支持通过“join”字段来将一个表关联另一个表来进行查询，join所操作的数据基于这两个表的数据存在。
 记录可以被创建或者删除。一条记录中的字段可以单独的被更新。
 关系型模型的实现通常提供“事务”这一概念，它支持 原子性的处理多条记录。
 至于 这是由哪种编程语言提供的，表更像是 array、list 或者是 struct。为了更高性能的访问，表可以增加b-tree或者散列表型的索引来实现。

2、键值存储。

 Key-value形式的存储支持根据key来访问value的数据访问形式。
 Key-value键值对可以被创建或者删除。与指定的key相关联的value可以被更新。
 Key-value存储通常不支持 “事务”。
 从编程语言方面来说，key-value类似于散列表(hash tables),比如 java中的hashmap，Perl中的hash，Python中的dict，php中的关联数组，c++中的boost::unordered_map<...> 等等。
 key-value存储 支持基于key的隐形索引。
 key-value存储听起来貌似不是那么有用的东西，但是大量的信息可以存储在value中，比如一个value可以为xml文档、json、或者系列化后的文本内容。由于存储引擎不太关心value中存储的内容，所以，key就显得比较重要了。value的格式根据客户端应用程序来决定，但是必须作为一个整体被写入。如果客户端将一个value存储为json形式，但是想更改其中的一个字段，那只能取出value，解析，更改字段值内容，然后重新回写。
 如果通过一个key想随意的访问数据，这恐怕不行，但是也有变通方法。如果应用程序提供一个次级索引，那么应用程序就可做到这点。为了做这个，可以为第一级value中的某字段增加一个二级索引，而应用程序则管理由这些二级索引所组成的一个‘二级集合’，而这二级索引key所指定的value为指定的目标字段所对应的一级索引key。因为没有“事务”来保证二级索引与原始集合的同步，所以，应用程序必须明确执行一个周期性的同步程序，在任何局部更新后来进行清理操作，否则可能会引起bug或者垃圾等等。

3、文件存储。

 文件存储支持记录结构化的数据，但是不同于关系型模型，它没有一个强行执行的模式（schema）。本质上，应用以key-value键值对的形式来存储数据包。为了在这种环境下操作，应用定义了一些规则，规定了对检索到的不同数据包所采用的不同的处理方式，或者采取存储引擎所支持的一些高级能力 去将不同的文档放入不同的 “合集”中，在这些合集中，数据将会被有效的管理。
 不同于关系型数据存储，文件存储通常支持嵌套结构。比如，文件存储支持对xml和json的保存，其中每个字段的值均可以为其他的结构。文件存储同样支持array或者list-valued的key。
 不同于key-value键值存储，文件存储的内部结构是对外透明的。这就支持了存储引擎可以直接支持第二索引，使得针对任何字段的查询更有效率。这个能力 使得 文件存储引擎所支持的查询语言可以对任何嵌套的结构进行查询， XQuery就是这样的一个例子。 MongoDB也支持类似的功能，不过是对针对指定规范的json格式中的字段进行查询。

 

4、列存储

 列存储和关系型存储比较像，除了他们替换数据的方式。和关系型存储 对 记录进行保存相比，列存储将某一列中的所有数据都存储在一个流中。列存储的索引 支持从列中获取任意特定的值。
 MapReduce实现的，比如Hadoop，如果对数据支持流，那么它的效率会更高。列存储很好的做到了这一点。总结，Hbase和Hypertable通常被当做非关系型数据仓库来进行mapreduce分析。
 一个关系型的列向量恐怕不太适用于分析，所以用户通常在列中存储更多复杂的结构。比如 Cassandra，实现了一个“列族”的概念，好比是一个“超级列”。
 面向列的存储支持检索记录，但是仅支持从他们的私有列中读取数据，然后再重新拼装记录。

 

5、图数据库

 图数据库存储 点和链接各点的边的数据。一些还支持为点 或 边 增加注释。这就好比 社交网络模型（每个人好比点，人与人之间的关系就好比链接点的边），或者现实中的真实物品（组件好比点，每个组件之间的关系就好比边）。IMDB（互联网电影数据库）中的内容就被图所联系：电影和演员相关联，而演员也和他们所参演的电影相关联，这就形成了一个大型复杂图。图数据库的数据访问和查询语言和我们之前讨论的都不大一样。图数据库的查询通常根据 点 或者 点与点间路径的约束来进行，比如 SPARQL.

选择一个数据模型

 为什么有这么多种模型？我们同样可以问：“为什么我们需要这么多种不同的数据结构？” 在数据结构这一领域，有很多文献演示了各种不同性能特性并优化的实例，比如 list、tree、以及 hash table。在持续数据存储这一领域，关系型数据库因为他们的广泛性涵盖了一大片区域。一些非关系型存储舍弃了关系型存储的一些特性 用来换取更加简单的模式 和 数据分布。然而，一些非关系型数据存储提出了一些不同的数据模型 从而使 对非关系结构化数据的解决 更加容易。
 选择一个数据模型并不是一件容易的事。将关系型数据存储用来进行多方面问题的解决 使得 他看上去更像是一个 一对多的解决方案，但是有很多领域已经证实关系型数据存储并不能很好的支持。这并不是说关系型存储不能使用，只是不会像解决某些类型的数据那么有效。非关系型存储的逐渐流行证明了一个趋势，就是 人们选择不同的数据格式来执行不同的目的操作。因为没有任何一个数据模型能够做到十全十美，使用非关系型存储的使用者通常使用不止一样数据模型来做不同的事情。一个应用可能使用Hbase来进行数据分析，同时使用MongoDb来进行空间查询。还有一些应用将关系型存储与非关系型存储联合使用，因为他们可能需要使用关系型数据库的事务概念来监视货币交换，利用其它数据模型来处理非结构化内容的数据，或者使用其它实用特性的数据库来处理实时的数据。
 为了能更好的选择一个数据存储，你应该考虑你的应用所需要的数据存取模式，以及如何来定义你处理的这个领域。当选择了一个数据存储，你将会发现，使用这个数据存储来存储你所有的数据不是那么自然顺理，于是，你想到了使用其它不同的数据存储来 适用于 不同的子系统，就像我们之前讨论过的一样。