详解 NoSQL 数据库使用实例

编者注：本文为历史博文归档；涉及 JDK、框架与工具链版本请以当前官方文档为准。引用外链图片可能失效，阅读时请注意时效性。

本文将为大家讲述 NoSQL 数据库的使用实例。最近这段时间，NoSQL 技术持续受到关注，但它究竟有什么样的优点？我们可以通过下面的实例来深入了解。

NoSQL 基础知识

关于 NoSQL

"NoSQL"一词实际上是由 Rackspace 的一位同事创造的，当时 Johan 等人组织了一次活动来讨论开源的分布式数据库，这个名称和概念由此而来。

有些人反对 NoSQL 这个术语，因为它听起来像是在定义我们“不是什么”。但在一定程度上，这个术语仍然有价值。因为当关系数据库是唯一的工具时，你知道，每一个问题看起来都像是一颗钉子（而手里只有锤子）。NoSQL 让人们知道还有其他选择。但我们并不反对关系数据库，因为当关系数据库确实是工作的最佳工具时，它依然不可替代。

与 NoSQL 名称真正相关的是，它是一个“大帐篷”（Big Tent），涵盖了非常不同的设计空间。如果这一点不在讨论中厘清，会导致各种产品的混乱。因此，我建议沿着三个轴来思考很多数据库选项：可扩展性、数据和查询模型以及持久性设计。

前所未有的数据量正推动企业关注传统关系数据库技术的替代品，这些技术已服务了 30 多年。总的来说，这些替代品已被称作"NoSQL 数据库”。

最根本的问题是关系数据库不能处理很多现代的工作负载。有三个具体的问题：

  1. 扩展性：面向像 Digg 新闻评论网站（3TB 数据）、Facebook（50TB 收件箱搜索）或 eBay（整体 2PB）这样的规模。
  2. 每服务器性能。
  3. 严格的架构设计。
备注：Digg 概念源自美国 Digg 公司。它完全是依靠真实的网民自己的力量。网站上所有内容都是由网民自己发布，并且内容的位置也是由网民自己来决定。当内容的顶数、评论等达到一定的数字，这些内容就有可能从众多的信息中脱颖而出。

我最近写了邮件给 Cassandra 社区，关于非关系型数据库的资源。我们承诺后，还有其他非关系型数据库在工作，我们称之为"NoSQL 运动”。

一个简单的 NoSQL 实例

我选择了一些 NoSQL 数据库作为例子。这不是一个详尽的清单，但讨论的概念对于衡量其他数据库也至关重要。

可伸缩性

缩放读取与复制容易，当我们在这方面缩放时，我们的意思是写操作缩放到多台机器自动分区的数据。我们称这种制度为“分布式数据库”。其中包括 Cassandra、HBase、Riak、Scalaris、Voldemort 等等。如果你写入卷或数据容量超过一台机器可处理，那么这些是你的唯一选择，如果你不想手动分区管理。

有两件事情看在分布式数据库：

  1. 支持多种数据中心。
  2. 能够添加新的机器到现场集群的应用程序的透明性。

NoSQL 数据库使用

数据和查询模型

非分布式 NoSQL 数据库包括 CouchDB、MongoDB、Neo4j、Redis 和 Tokyo Cabinet。这些可以作为分布式系统持久层；MongoDB 提供有限的分片支持，CouchDB 项目独立出来，而 Tokyo Cabinet 可作为 Voldemort 存储引擎使用。

数据和查询模型

在 NoSQL 里有很多不同的数据模型和数据库的查询 API。一些重点如下：

  • 列族模型（Column Family）：Cassandra 共享和 HBase 的模型是由谷歌的 Bigtable 文件第 2 节描述的启发。（Cassandra 下降历史版本，并添加超级列。）在这两个系统，你必须像你行和列习以为常，但稀疏行：每一行可以有许多或尽可能少列的需要，以及列不必须提前定义。
  • 键/值模型（Key/Value）：是最简单和最容易实现的，但效率低，只有当你在查询或更新的值的一部分感兴趣。这也是难以执行的分布式圈顶更复杂的结构/价值。
  • 文档数据库（Document）：基本上是下一阶段重点/值，允许嵌套的值与每个键关联。文件数据库支持查询的效率比每次返回了整个 BLOB 更简单。
  • 图数据库（Graph）：Neo4j 有一个真正独特的数据模型，对象存储在图和节点和边的关系。对于查询适合这个模型（例如，分层数据），它们可以是 1000 倍速度比替代品。
  • 分布式事务：Scalaris 是独特的，提供跨多个键分布式事务。（讨论与贸易之间的一致性和可用性权衡超出了这个职位的范围，但另一个方面就是要牢记在评价分布式系统。）

持久性设计

通过持续的设计我的意思是，“如何在内部存储的数据？”持久性模型告诉我们很多这些数据库能够善于什么样的工作量。

持久性设计

  • 内存数据库：是非常、非常快的（Redis 达到每秒超过 100,000 操作一台计算机上），但不能与数据集的工作，超出可用的 RAM。耐久性（保留数据，即使服务器崩溃或断电）也将是一个问题的数据量，可以预期损失之间的冲（复制数据到磁盘）可能非常大。Scalaris、其他内存数据库，我们的名单上，意向处理与复制耐久性问题，但由于它不支持多个数据中心的数据将仍然容易受到停电的事情一样。
  • Memtables 和 SSTables：缓存在内存中写入（1"memtable"）后，以书面追加只承诺为耐久性日志。当写够已被接受的 memtable 排序并写入到磁盘上的所有一次作为"sstable。”这提供近内存中的表现，因为没有涉及要求，同时避免了纯粹的耐久性问题，在内存的方法。（这是详细描述在第 5.3 和先前提及的 5.4 Bigtable 的文件，以及在该日志结构合并树。）
  • B 树（B-Tree）：已被用于从数据库中实际上是时间的起点。索引他们提供强大的支持，但表现欠佳的旋转盘（这仍然是迄今为止最具有成本效益，因为多）要求读或写什么工作。
  • 追加只读 B 树：一个有趣的变体是 CouchDB 的追加，只有 B 树，它避免了管理费用的目的在限制 CouchDB 一写一时间成本。

结论

该 NoSQL 运动在 2009 年爆炸地为越来越多的企业全力对付大量数据。在 Rackspace 云高兴地发挥了 NoSQL 运动的早期作用，并继续投入资源，Cassandra 像 NoSQL 支持事件。

说明：本文内容主要反映 2009-2010 年左右的技术背景与观点。文中提及的部分数据库版本、性能数据及行业案例（如 Digg）具有历史时效性，当前 NoSQL 生态已发生显著变化，请以各数据库官方最新文档为准。