纯粹的键/值
纯粹的键值数据库实际上已经存在很长时间了。甚至在SQL数据库流行之前，dbm(一个纯粹的键/值数据库)就在世界上的很多UNX系统中使用了。之后是 Berkeley DB，目前仍然是一个维护中的富有生命活力的数据库解决方案。今天，这些纯粹的键值存储库正在重新流行起来，部分原因是所有的 NOSQL数据库都在变得流行起来，但也是因为开发了一些速度更快、更为现代的数据库实现，如 Tokyo Cabinet、 Kyoto Cabinet、 Memcachedb。
正是它们的简单性定义了这组数据库。向数据库存入一个键和一个值，然后用同一个键查询数据库，则会得到相同的值。没有结构或类型系统一一通常所处理的只是字节或字符串。因为这种简单性，这些数据库的开销极小，所以非常快。事实上，这些数据库通常都是实现为磁盘上的B树或哈希表。
对一个纯粹的键值数据库进行分片是直截了当的一一简单地选一个哈希算法，以键作为参数运行该算法，输出就是要查询或写入的数据库节点。另一方面，对于复杂查询就完全不是这么简单了。醫如对于这样的查询:年龄大于50的用户，就无法直接查询，不得不维持另外一个键/值对，其中值是一个序列化的用户键列表，这些用户的年龄大于50，每次要创建新用户或更新用户信息，都要更新这个列表。
对于纯料的键/值存储库，可能的应用包括HTTP会话、用户喜好以及URL缩写(shorteners)。我在前面已经描述过HTTP会话，HTTP会话应该以一种非常直接的方式存储在能/值摩中。其中键就是用户的会话关键字( session key)，而值是包含用户会话信息的一个序列化了的对象。对于用户喜好，可以这样来实现:键是用户1D连接上用户喜好的名称，值就是用户实际的喜好。对于URL缩写，URL路径就是键，而值就是路径重定向的位置。
数据结构
数据结构数据库对键/值数据库做了些修改。在纯粹键值数据库中，通常只是将键和值作为字符串或字节来存储，而数据结构数据库则将其存储为特定的数据结构，如列表、集合或哈希表。由于有了这些附加的结构，就可以对值执行一些原子操作。对于列表，可以对值进行压入或弹出操作。对于集合，可以执行并集和交集操作。可以对数据库执行在应用程序中对数据结构进行的各种操作。本质上，这些都是应用程序已经在使用的数据结构只不过由外部进程维护而已。
实际上这个领域唯一的竞争者就是Redis。某些实现细节使得Redis很有。Redis默认是在内存中存储其全部内容的，只是周期性地将内容的快照存储到磁盘。这使得Redist出奇得快，但假如数据库崩溃了，就会对数据造成一些损失。同时也意味着必须有足够的内存(RAM)存储整个数据库。值得指出的是，这些默认设置是可以改变的一可以以速度为代价来增加数据的可持续性，还可以使用虚拟内存模式，这样就可以存储比实际内存更多的数据(虽然仍然是有限制的)。
数器、任务队列或趋势分析，是很理想的。想象一下，给每个登录进来的用户一个唯一的鍵，映射到一张空表上，该用户访问的每个页面的每个URL都从尾部压人这张表。然后就可以获取任何用户的这些信息，观察该用户的访问路径，并对该路径进行分析。通过这张表的长度就可以得出该用户的活跃程度。这是一个人为的例子，但仍然展示了极快的内存操作和丰富的数据结构能做什么事情。
图
图数据库几乎就是数据结构数据库的一个特定实现，因为图本就是一种数据结构。区别是图数据库不再是基于键/值，数据是作为图的节点和边存储的。图数据库不是用键来查询值，而是给出根节点的句柄，然后就可以遍历整个图以找到需要的节点或者边。这会非常有价值，因为很多应用程序都大量使用了图这种数据结构，将这些数据结构映射为图数据库上的操作是相当容易的。就像数据结构数据库一样，数据库的图也跟应用程序使用的图是一样的，只不过是由外部进程维护的而已。
这个领域的主要竞争者是Neo4j，这是是一个嵌入式的ava图数据库，但可以用好几种语言进行访同。除了Neo4之外，其他开源的图数据库包括Hypergraphdb、Infogrid、Vertexdb Hypergraphdb定位在对图的一种更为通用的表示上，其中之一就是边可以指向多个节点。Vertex的有趣之处是呈现了一个RESTFULL的HTTPAPI，通过这个API可以直接访问数据库，而其他几种数据库主要都是通过Java方法来访问的。
图数据库的优势应该正是你所期望的:存储图或树形的数据。例如，假如网站想要维护一个社交图(social graph)，则使用图数据库会产生一些有趣的应用。警如，发现或向用户推荐新朋友，传统上实现起来既复杂，速度又慢，而使用图数据库则既简单，效率又高一一仅仅运行一下宽度优先搜索或最短路径遍历，事情就搞定了。
面向文档
面向文档的数据库又类似于键值数据库，但值不再是字节、字符串、列表、集合，而是文档”。什么是文档?在我们要谈到的两个面向文档数据库 COUCHDB和MONGODB中，文档是作为JSON(或类似于JSON)对象存储的，本质上是一种哈希表或字典。这些值都有相同的结构，意味着可以用查询来探测这种结构，并只返回所需要的文档。要记住的是，这种查询能力是建立在通过键来查找文档的能力之上的。
COUCHDB是一个面向文档的数据库，是用 Erlang开发的，有一些有趣的实现细节，警如说是一种只附加(append-only)的数据结构，并且能够在数据库中直接向应用程序提供服务。Mongodb是另一个面向文档的数据库，是用C++开发的，在速度上做了很多优化，提供了一个更加传统的查询层。虽然这两个系统在纸上看起来很像，但目标却是不同的。在我写这些东西的时候，COUCHDB的趋势是作为桌面数据库或浏览器中的数据库，由用户下载安装，而Mongodb则趋向于更多地用在数据中心。
在不能确切地知道能获得什么数据时，如在生活串流应用中那样，面向文档的数据库就非常合适了。在这样的应用中，从一个流行的照片网站上检索的文档应该包含照片属性，而来自微博网站的文档可能有一些地理属性，而来自博客网站的文档将不会有这些信息。面向文档数据库的另一个不错的应用是内容管理系统，在这样的系统中，每个文档都表示一个页面，或页面的一部分。
高度分布
高度分布的数据库多少有些不同一一有些本质上更接近于键/值存储，其他则更像大型的多维哈希图。它们的共同点是都为多节点部署优化过。在这些系统中，简单地在集群中增加一个新节点就会增加更多的容量。其中一个节点失效并不会导致数据损失，但会失掉一些容量。多数这种系统都会允许用户牺牲掉一些一致性而保证高可用性和分区容错性。
Hbase是一个高度分布式的数据库，源自于Hadoop-项目，并且受到Big Table(Google专有的高度分布式数据库)的直接影响。 Cassandra是另一个高度分布式数据库，最初是在Facebook开发的，虽然数据模型非常类似于Hbase，但集中在不产生单点故障以及写操作性能上。Hbase和Cassandra都将数据存储为大型的多维哈希图。 Basho公司的Riak是另个高度分布式数据库，使用Erlang开发，可以通过RESTFULL的HTTPAPE来访问，和Hibase与Cassandra比起来，是一个更加简单的键值模型。Voldemort和Hypertable项目是另外两个值得提及的高度分布式数据库。
为什么要使用高度分布的网站建设数据库呢?噢，通常都是没有其他选择的结果。这些数据库都是用在这样的场合，就是其他的数据库(基于SQL的数据库或其他数据库)或者对数据无法处理，或者无法处理那些查询。几乎每个问题领域(problem domain)都可以用这些数据库系统来建模，但有时候会比许多传统数据库更为诡异。
本文地址：//cosda.cn//article/3357.html
