ACM通信
实践
在关系数据库中
环境中计算设备的数量和种类正在迅速增加。真正的计算机不再与台式机绑定或锁在服务器室中。fda、高度移动的平板电脑和笔记本电脑设备、掌上电脑和移动电话手机现在为交付新的应用程序和服务提供了强大的平台。然而，这些设备只是冰山一角。支持使无处不在的计算成为可能的基础设施所需的许多计算和网络元素是看不到的。
随着如此强大的计算能力在公文包和口袋里四处流动，开发人员正在构建几年前还不可能实现的应用程序。现在的有趣服务包括文本和多媒体消息，基于位置的搜索和信息服务(例如，对附近餐馆的点播评论)，以及特别的多人游戏。在未来的几年里，今天无法预测的新型移动和个性化服务肯定会被开发出来。
虽然这些服务在主要方面有所不同，但它们也有一些重要的属性。本文的重点之一是应用程序中内置的数据存储和检索功能。消息传递应用程序需要在网络中可靠且无损失地移动消息。基于位置的服务需要将物理位置映射到逻辑位置(例如，GPS或蜂窝基站坐标映射到邮政编码)，然后查找基于位置的信息。游戏应用程序必须在分布式设备上记录和共享游戏的当前状态，并且必须实时管理内容检索和发送到每个设备。在所有这些情况下，快速、可靠的数据存储和检索是至关重要的。
一旦讨论转向数据存储和检索，就会想到关系数据库。关系数据库在过去三十年中取得了巨大的成功，SQL已经成为数据访问的通用语言。而数据管理已经几乎成为RDBMS的同义词，然而，有越来越多的应用程序更适合轻量级的替代方案。
本文首先简要回顾了关系系统是如何主导数据管理领域的，并讨论了关系技术是如何发展的。本文以数据为中心概述了当前的紧急应用程序，并深入研究了当前和未来应用程序的数据管理需求。
关系史前
关系数据库来自IBM的一项研究1，5以及加州大学伯克利分校7在1970年代。从根本上说，关系数据库是对部署和维护复杂系统的成本不断上升的一种反应。
关键的观察结果是，当数据库的内容或物理组织发生变化时，成本非常昂贵的程序员必须手工重写大量的应用程序软件。因为应用程序通常详细地知道其数据是如何存储的，包括磁盘上的布局，所以重新组织数据库或向现有数据库添加新信息将迫使访问这些数据库的代码进行大规模更改。
关系数据库通过两种方式解决了这个问题。首先，它们对应用程序隐藏了数据库的物理组织，只提供了数据的逻辑视图。其次，他们使用声明性语言来描述特定查询中感兴趣的数据，而不是强迫程序员编写函数调用的集合来获取数据。这两个更改允许程序员描述他们想要的信息，并留下优化和访问数据库管理系统的细节。这种转换减轻了程序员在数据库布局或组织发生变化时重写应用程序代码的负担。
关系数据库在全世界的IT商店和数据中心获得了巨大的成功。需要管理大量数据的业务和使用这些数据的复杂应用程序迅速采用了新技术。对关系产品的需求创造了一个每年价值数十亿美元的授权收入市场。20世纪80年代出现了几家RDBMS供应商，争夺这一利润丰厚的业务。
在随后的20年里，出现了两个相关的趋势。首先，RDBMS供应商增加了功能，以提供市场差异化，并在每个新的市场利基出现时解决这个问题。其次，很少有应用程序需要当今rdbms中所有可用的特性，因此，随着特性集大小的增加，每个应用程序使用的特性集的比例越来越小。
DBMS功能的增强伴随着复杂性的增加，现在大多数部署都需要经过数据库管理培训的专家来维持系统和应用程序的运行。由于这些系统是作为整体实体开发和销售的，即使应用程序可能只需要系统功能的一小部分，每次安装都要为整个系统的复杂性付出代价。当然，一定有更好的办法。
新前沿
我们不是第一个注意到这些变化的人。1998年，主要的数据库研究人员得出结论，数据库管理系统变得过于复杂，自动化配置和管理变得至关重要。2两年后，Surajit Chaudhuri和Gerhard Weikum提出了对数据库管理系统架构的彻底反思。4他们建议将数据库管理系统变得更加模块化，并拓宽我们关于数据管理的思路，包括相当简单的、基于组件的构建块。最近，Michael Stonebraker也加入了这个行列，他认为“一种模式不再适合所有人”，并引用了一些特定的应用实例，说明传统的RDBMS架构并不合适。8
正如Stonebraker所说，关系型供应商一直在提供一种错觉，认为RDBMS可以满足任何数据管理需求。例如，随着数据仓库和决策支持成为重要的应用领域，供应商对产品进行了调整，以满足这些新领域中出现的专门需求。为此，它们将完全不同的数据管理实现隐藏在熟悉的SQL前端之后。然而，当人们开始更深入地研究新兴的数据需求时，这个模型就会被打破。
数据仓库。零售组织现在有能力记录每一项客户交易，产生一个巨大的数据源，可以挖掘关于客户购买模式、产品流行趋势、地理偏好和无数其他现象的信息，可以利用这些信息来增加销售或降低业务成本。这个数据库是以读为主:它通过定期向集合中添加新的事务来批量更新，但在分析人员筛选数据提取有用的花絮时，它被频繁读取。这个应用程序领域的特点是大量的表(数十或数百tb)，查询只访问表中许多列中的一小部分，并且需要扫描以多种不同方式排序的表。
目录服务。随着组织越来越依赖分布的资源和人员，对目录服务的需求激增。3.目录服务器提供对分层结构组织的实体的快速查找，分层结构经常与组织的分层结构相匹配。LDAP标准出现于20世纪90年代，是为了响应重量级的ISO X.400/X。500目录服务。LDAP现在是许多供应商(例如IBM Tivoli的目录服务器、微软的Active目录服务器、Sun ONE目录服务器)的身份验证和身份管理系统的核心。与数据仓库一样，LDAP的特点是主要是读访问。查询可以是单行检索(查找与该用户对应的记录)，也可以是基于属性值的查找(查找工程部门的所有用户)。多值属性的普遍使用使得关系表示非常低效。
网络搜索。互联网搜索引擎处于数据库管理和信息检索的交汇处。它们所操作的对象通常是半结构化的(也就是说，HTML而不是原始文本)，但是所提出的查询通常是关键字查找，其中所需的响应是可能答案的排序列表。实际上，今天所有成功的搜索引擎都开发了自己的数据管理解决方案来解决这个问题，构造了高效的反向索引和高度并行的索引和查找实现。这个应用程序主要是读的，具有批量更新和非传统的索引。
移动设备缓存。小型移动设备的流行带来了另一类应用:在小型、低功能设备上缓存较大数据集的相关部分。虽然今天的用户认为他们的手机目录是他们自己的数据收集，另一种观点可能会认为它是一个全球电话和地址目录的缓存。该模型具有特别吸引人的特性，特别是在使用或需要条目时增强本地数据集的能力。移动电话基础设施需要类似的缓存功能来维护到设备的通信通道。在这些缓存中观察到的访问模式也是主要是读的，数据本身完全是临时的;如果有必要，它可以丢失并重新生成。
XML管理。在线交易越来越多地通过交换xml编码的文档进行。目前的标准解决方案包括将这些文档转换为规范的关系组织，将它们存储在RDBMS中，然后在需要使用它们时再次转换。随着使用XML创建、传输和操作的文档越来越多，这些翻译变得不必要、低效和乏味。肯定有更好的办法。具有Xquery和Xpath访问模式的原生XML数据存储代表了存储发展的下一波浪潮。虽然在XML存储库中不断添加和删除新项，但文档本身在很大程度上是只读的。
流处理。在这些数据密集型应用程序中，流处理有点像一个弃物。严格地说，流处理不是一项数据管理任务;这是一项数据过滤任务。也就是说，数据在某个源产生，并以流形式发送给接收方，接收方从流中筛选“有趣的”事件。例如，金融机构观察股票行情器，寻找交易激烈的项目和/或交易不像预期那么频繁的股票。
这里包含这些流处理应用程序的原因是语言方面的:这些环境中通常需要的过滤器看像SQL;然而，虽然SQL设计用于操作持久存储的表，但这些查询作用于实时的数据值流。斯通布雷克在一定程度上解释了这个任务的数据库设备是多么的差。也许更令人惊讶的不是数据库系统不具备处理此任务的能力，而是因为SQL似乎是“正确的”查询语言，所以开发人员将关系数据库系统用于没有持久存储的应用程序!
流处理代表了一类应用程序，这些应用程序可以受益于基于数据管理系统的类似sql的查询语言，其属性与RDBMS截然不同。由于流查询经常对一个时间窗口期间观察到的数据进行操作，因此需要一些临时的本地存储，但这种存储不需要是持久的、事务性的或支持复杂的查询处理。相反，它必须快得让人眼花缭乱。虽然关系数据库能够很好地处理相对静态或变化缓慢的数据上的动态查询，但这个应用程序类的特点是在高度动态的数据上有一个相当静态的查询集。
解决方案必须具有两个基本属性，以满足当今出现的广泛应用程序需求:模块化和可配置性。
灵活的解决方案
关系系统的设计是为了满足在线事务处理(OLTP)工作负载，其特点是临时查询、显著的写流量以及对强大的事务性和完整性保证的需求。相比之下，这里描述的应用程序几乎都是读为主的，流应用程序甚至不利用持久数据，而只是一种类似sql的查询语言。这些应用程序中很少有需要事务保证的，而且与被访问的数据几乎没有内在的关系。因此，数据管理的问题就变成了如何最好地满足这些不同类型应用程序的需求。我们声称(就像Stonebraker一样)真的没有唯一的正确答案。相反，我们必须专注于灵活的解决方案，这些解决方案可以针对特定应用程序的需求进行定制。
有几种方法可以在当今不断变化的数据环境中提供灵活性。返璞归真的方法要求每个应用程序构建自己的数据存储服务。这个选项虽然看起来很简单，但除了最简单的应用程序外，在所有应用程序中都是不切实际的。然而，目前运行的一些数据密集型应用程序是建立在简单的、自行开发的解决方案之上的。
满足灵活性需求的第二种方法是提供多种数据管理选项，每个选项处理一个特定的应用程序类。我们看到这种方法出现在传统的关系市场中，其中使用SQL贴面来隐藏OLTP和数据仓库所需的不同功能。
实现灵活性的第三种方法是创建一个更可配置的存储引擎，以便能够根据各个应用程序的需求进行调整。该方案的优点是可以集中投资于单个存储系统，提高质量。然而，可配置性对使用数据库的开发人员提出了新的要求，因为他们必须了解配置选项，然后将数据管理组件正确地集成到他们的产品设计中。
事实上，市场上出现的解决方案是拥有一些合理配置的存储系统，每个存储系统在广泛的应用程序类中都很有用。
解决方案必须具有两个基本属性，以满足当今出现的广泛应用程序需求:模块化和可配置性。很少有应用程序需要数据管理系统中所有可能的功能。如果应用程序不需要功能，它就不应该在大小(占用空间、内存消耗、磁盘利用率等)、复杂性或成本方面为该功能“付费”。因此，灵活的引擎必须允许开发人员根据应用程序是否需要使用或排除主要子系统。一旦一个系统足够模块化，可以实现真正小的占用空间，我们将发现部署在一系列硬件平台上的系统在性能上有着惊人的差异。在这些情况下，系统必须对其操作环境进行配置:特定的硬件、操作系统和使用它的应用程序。
模块化
一些人认为数据库架构需要一场革命，类似于计算机硬件的RISC革命。传统的单片数据库管理体系结构不足以适应当今的数据需求，因此我们必须在一组小的、简单的、可重用的组件基础上构建数据管理功能。例如，与其将SQL视为简单的二进制决策，Chaudhuri和Weikum认为，查询功能应该以不同的复杂级别提供:具有B+树索引的单表选择处理器，该索引支持简单的索引、更新和选择。对此，您可以添加事务。继续沿着复杂层次结构向上，考虑一个选择-项目-连接处理器。接下来,添加总量。通过这种方式，您可以将SQL从单一语言转换为一系列更丰富的语言，每一种语言都作为组件提供，并满足大量应用程序领域。任何特定的应用程序都会选择它需要的组件。基于组件的体系结构的这种思想可以扩展到包括数据库设计的其他几个方面:并发控制、事务、日志记录和高可用性。
并发控制的层次结构类似于语言示例中的结构。有些应用程序是完全单线程的，不需要锁;另一些则具有较低的并发级别，可以通过表级锁或api级锁(只允许一个写入器或多个读取器同时进入数据库系统)来很好地服务;最后，高并发应用程序需要细粒度锁定和多级别隔离(可能允许应用程序看到不完整的事务所写的值)。6在传统的数据库管理系统中，锁是假设的;在这里讨论的美丽新世界中，锁定是可选的，可以使用不同的组件来提供不同级别的并发性。
事务提供了一种错觉，即操作集合应用于原子单元中的数据库，并且一旦应用，操作将持久存在，即使面临应用程序或系统故障。事务管理是大多数数据库管理系统的核心，但许多应用程序不需要事务。在基于组件的世界中，事务也是可选的。当它们出现时，系统可能仍然有许多不同的组件提供基本的事务机制、保存点(确定数据库可能回滚到的时间点的能力)、两阶段提交(以支持跨多个数据库的事务)、嵌套事务(将大型操作分解为许多较小的操作)以及补偿事务(以撤消高级逻辑操作)。
许多事务系统使用某种形式的日志记录来提供回滚和恢复功能。在这种情况下，似乎没有必要将日志记录视为可分离的组件，但它应该是可分离的。事务组件可能被设计为使用多个实现，其中一些不使用日志记录(例如，无覆盖方案，如影子页面)。也许更有趣的是，日志系统可能在事务上下文之外很有用;它可能用于审计或提供某种备份机制。无论哪种情况，都应该由应用程序设计者来决定日志记录是否必要，而不是由数据库供应商强制执行。
最后，数据有时非常关键，停机是不可接受的。许多数据库系统提供复制或高可用性系统来满足这一需求。尽管在今天的系统中，这个功能通常作为一个附加组件可用，但它们还不够。开发人员可能希望使用数据库的HA(高可用性)配置，但也可能将其与其他公司的HA基板一起使用。如果应用程序已经拥有执行心跳协议(或在组件故障时通知应用程序或系统的任何其他机制)、故障转移和冗余通信通道的基板，那么您将希望从数据库管理系统中排除这些组件，并连接到现有的功能。单片系统不允许这样做，而基于组件的模块化体系结构则允许这样做。
除了提供更小、更简单的应用程序之外，具有良好定义的、干净的、公开的接口的组件还提供了一定程度的可扩展性，这在单片系统中是不可能实现的。例如，考虑构建事务系统所需的基本组件集:事务管理器、锁管理器和日志管理器。如果这些模块是开放的和可扩展的，那么开发人员可以构建将数据库系统不管理的项合并到事务中的系统。例如，考虑一个网络交换机:配置数据库的状态取决于设备内部硬件的状态，反之亦然。如果对芯片和板卡的电气控制可以合并到事务中，通过允许程序员扩展锁定和日志系统来与它们通信，那么像“启动备份网络接口卡”这样的操作就可以成为事务性的。
模块化是一个强大的工具，用于管理应用程序和系统的规模和复杂性，同时也使应用程序和数据管理功能实现无缝交互。因此，我们提出了一种体系结构，使开发人员能够排除他们不需要的功能，并包括他们需要但数据库供应商不提供的功能。
旧式的数据库系统解决旧式的问题;我们需要新型的数据库来解决新型的问题。
可配置性
灵活的数据管理系统的第二个属性是可配置性。模块化是一种架构机制，而配置主要是一种运行时机制。对于基于组件的体系结构，在选择适当的组件时涉及到构建时配置。一个组件集合仍然可以运行在一系列具有不同功能的系统上。例如，虽然两个应用程序都需要事务和b -树，但这并不意味着它们都可以支持几个gb的内存缓存。适应完全不同环境的能力至关重要。可配置性指的是系统与环境和应用程序需求的匹配程度。在本文中，我们将讨论与硬件、应用程序运行的环境(例如，操作系统)、应用程序的软件体系结构和应用程序的“自然”数据格式有关的可配置性。
硬件环境引入了CPU速度、内存大小和持久存储能力的可变性。CPU速度和持久存储的可变性引入了交易磁盘带宽计算的可能性。在快速处理器上，压缩数据可能是有益的，消耗CPU周期，以节省I/O;在PDA上，CPU周期很稀疏，持久I/O速度很快，因此压缩可能不是正确的权衡方法。
在资源受限的设备可能需要复杂的数据管理的环境中，开发人员必须控制数据库的内存和磁盘消耗策略。在不同的环境中，应用程序可能需要控制内存中数据结构的最大大小、持久数据的最大大小和事务性日志所消耗的空间。使用这些资源的策略必须由应用程序开发人员设置，而不是最终用户，因为开发人员更有可能拥有做出正确决策所需的技术知识。
持久存储技术中的可变性也对数据库引擎提出了新的要求。它不仅必须在有旋转磁存储的情况下运行良好，而且还应该在有行为约束的其他媒体(如闪存)上运行良好(如写入特定内存位置的次数)，并且可能需要在没有任何持久存储的情况下运行。例如，一些应用程序希望完全在主存中管理数据，没有持久性;有些希望在更新时使用完全同步事务保证来管理数据;有些人需要中间的东西。这些策略都应该由相同的事务组件实现，但数据库应该允许程序员控制数据是否跨电源关闭事件持久存在，以及系统对最终用户的任何事务保证的严格程度。
尽管许多嵌入式系统现在能够使用现成的硬件平台，但许多专有设备仍然存在。无处不在的数据管理解决方案将可移植到这些特殊用途的硬件设备。它还可以移植到各种操作系统上;手机操作系统提供的服务与64路多处理器提供的服务不同，即使两者都运行Linux。如果数据管理系统要在任何地方运行，那么它必须只依赖于大多数操作系统通用的服务，并且必须通过简单的插入库或源代码可用性提供显式的机制来允许可移植性。
即使在单一平台上，开发人员也会做出影响数据库系统的体系结构选择。例如，一个系统可以使用:一个单一的控制线程;协作进程的集合，每个进程都是单线程的;单个进程中的多个线程控制;多个多线程进程;或者是严格的基于事件的架构。这些选择是由应用程序的需求、开发人员的偏好、操作系统和硬件的组合驱动的。数据库系统必须容纳它们。
数据库还必须避免对网络协议做出决策。由于数据库将运行在通过背板进行通信的环境中，以及在通过wan进行通信的环境中，因此开发人员应该选择适当的通信基础设施。一种专用电话交换机机箱可包括用于冗余板之间快速通信的自定义背板和协议;数据库不能阻止开发人员使用它。
到目前为止，可配置性一直围绕着适应应用程序的硬件和软件环境。我们要解决的最后一个配置领域与应用程序的数据有关。数据布局、索引和访问是关键的性能考虑因素。关于数据有三个主要的设计要点:物理聚类、索引机制和数据库项的内部结构。其中一些机制(如索引机制)实际上是运行时配置决策，而其他机制更多地是赋予应用程序做出设计决策的能力，而不是让设计人员因为数据库管理系统而被迫做出决策。
为旋转磁介质设计的数据库管理系统花费大量精力将相关数据聚集在磁盘上，以便通过每次重新定位事件传输大量数据来分摊寻道和旋转时间。一般来说，只要根据正确的标准对数据进行聚类，这种聚类是很好的。在可配置数据库系统的情况下，这意味着开发人员需要保留对主键选择的控制(就像在大多数关系数据库管理系统中所做的那样)，并且必须能够忽略集群问题，如果持久介质不存在，或者对访问“接近”最后一次访问的位置没有显示性能优势。
与此相关的是，开发人员必须能够灵活地为主键选择适合工作负载的索引结构。B+树可以很好地服务于具有局部引用的工作负载;那些拥有巨大数据集和真正随机访问的用户可能更适合使用哈希表。也许数据是高维的，需要完全不同的索引结构;上一节讨论的可扩展性应该允许开发人员提供特定于应用程序的索引机制，并将其与系统的所有其他特性(例如锁定、事务)一起使用。至少，可配置数据库应该提供一系列可选的索引结构，支持迭代、快速相等搜索和范围搜索，包括对部分键的搜索。
与关系引擎不同，可配置引擎应该允许程序员确定其数据项的内部结构。如果应用程序具有动态的或不断发展的模式，或者必须支持特别查询，那么内部结构应该支持高级查询访问，如SQL、Xpath、Xquery、LDAP等。但是，如果模式是静态的，并且查询集是已知的，那么选择一个更直接映射到应用程序内部数据结构的内部结构可以提供显著的性能改进。例如，如果应用程序的数据本质上是非关系型的(例如，包含多值属性或大块的非结构化数据)，那么仅仅为了方便SQL访问而将其强制转换为关系型组织将会降低转换的性能，而且不太可能从关系存储中获益。类似地，如果应用程序的数据是关系数据，强制转换为不同的格式(例如，XML、面向对象等)也会增加开销，而不会带来任何好处。可配置引擎必须支持以对应用程序最自然的格式存储数据。然后，程序员就有责任选择符合“最自然”标准的格式。
针对新型问题的新型数据库
旧式的数据库系统解决旧式的问题;我们需要新型的数据库来解决新型的问题。虽然对传统数据库管理系统的需求并没有消失，但是今天的许多问题都需要一个可配置的数据库系统。即使没有水晶球，很明显，未来的系统也需要很大程度的可配置性。作为程序员和工程师，我们要学会选择正确的工具来完成工作;选择数据库也不例外。我们需要以一种认识到这一点的模式来运作是数据管理的选项，我们应该选择正确的工具，以尽可能高效、健壮和简单地完成工作。
参考文献
1.System R:数据库管理的关系型方法。ACM反式。数据库系统1,2(1976)， 97137。
2.《阿西洛玛数据库研究报告》。ACM SIGMOD记录27日,4 (1998);www.sigmod.org/record/issues/9812/asilomarhtml。
3.Broussard, F.环球IT资产管理软件预测与分析，20022007。(2004)。IDC的医生。# 30277;www.idc.com/getdoc.jsp7containerId = 30277 pid = 35178981。
4.重新思考数据库系统架构:迈向自调优的risc风格的数据库系统。VLDB日报。(2000), 110;www.vldb.org/conf/2000/P001.pdf。
5.面向大型共享数据库的数据关系模型。Commun。ACM13,6(1970年6月):377387。
6.Gray, J.和Reuter, A.。事务处理:概念和技术。摩根·考夫曼，加州圣马特奥，1993,397402
7.安格尔的设计与实现。ACM反式。数据库系统1,3(1976)， 189222。
8.M. Stonebraker和U. Cetintemel, U.有一个标准适用于所有人:一个时间已经来了又去的想法。在2005年数据工程国际会议论文集(2005年4月);http://www.cs.brown.edu/-ugur/fits_all.pdf。
©2008 acm 0001-0782/08/0700 $5.00
允许制作本作品的全部或部分的数字或硬拷贝用于个人或课堂使用，但前提是该拷贝不是为了盈利或商业利益而制作或分发，并且该拷贝在第一页上带有本通知和完整引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2008 ACM有限公司
没有发现记录