PDF号召
期待已久，彻底重构的数据库架构的到来终于指日可待。
吉姆·格雷，微软
马克·康普顿，顾问
我们生活在一个剧烈变革的时代，其中大部分变革是由信息海啸引发的，这场海啸威胁要将我们完全吞噬。 在日益增长的冲击下，我们传统的 关系数据库 结构——充其量总是很笨拙——现在显然面临着完全崩溃的风险。
事实上，如今你几乎找不到任何不为在线分析处理提供支持的数据库管理系统。 决策树、贝叶斯网络、聚类和时间序列分析也已成为标准软件包的一部分，并允许在未来添加更多算法。 此外，还添加了文本、时间和空间数据访问方法——以及相关的概率逻辑，因为越来越多的应用程序需要近似结果。 列式存储（以列方式而非记录方式存储数据）已经复兴，主要是为了适应稀疏表以及优化带宽。
经典关系数据库架构慢慢走向崩溃，这有什么奇怪的呢？
但是等等……还有更多！ 越来越多的应用程序开发人员认为 XML 和 XQuery 应该分别被视为我们的主要数据结构和访问模式。 至少，数据库系统需要适应这种观点。 此外，随着外部数据越来越多地以流的形式到达，需要与历史数据进行比较，流处理操作符必然会被添加进来。 发布/订阅系统进一步加剧了这一挑战，它颠倒了传统的数据/查询比率，要求将传入的数据与数百万个查询进行比较，而不是使用查询来搜索数百万条记录。 与此同时，磁盘和内存容量的增长速度明显快于降低延迟和确保充足带宽的相应能力。 因此，现代数据库系统越来越依赖于海量主内存和顺序磁盘访问。
随着我们向前发展，这一切都需要一种新的、更加动态的查询优化策略。 它必须是一种能够轻松适应不断变化的条件和偏好的策略。 坚持某种静态计划的选择已经变得站不住脚了。 还要注意的是，我们需要考虑到智能越来越多地迁移到网络边缘。 每个磁盘和传感器实际上都能够充当一个合格的数据库机器。 与所有其他数据库系统一样，这些设备中的每一个也需要是自我管理的、自我修复的和始终可用的。
毫无疑问，你已经开始明白其中的意思了。 正如现在必须显而易见的，我们确实有大量工作要做，才能使这一切成为现实。 话虽如此，我们没有太多选择——外部力量正在推动这些变化。
欢迎来到革命
对象关系数据库的兴起、衰落和再次兴起。 我们享受了一段相对停滞的时期，在此期间，我们的议程只不过是“更好地实现 SQL”——加州大学伯克利分校教授兼 Ingres 的开发者迈克尔·斯通布雷克将此称为数据库研究和实现的“打磨圆球”时代。 朋友们，那些日子已经结束了，因为数据库已成为交付集成应用程序开发环境的首选工具。
也就是说，数据和过程终于走到了一起——尽管也许是通过一场仓促的婚姻。 Java 或通用语言运行时已与关系数据库引擎结合在一起，因此传统的 EJB-SQL 外部-内部分割已被消除。 现在，Beans 或业务逻辑可以在数据库内部运行。 活动数据库是结果，它们提供了巨大的潜力——无论是好的还是坏的。 （关于这一点，将在稍后的讨论中进行更多介绍。） 然而，我们最直接的挑战源于传统的关系数据库从未被设计为允许数据和算法的混合。
当然，问题始于 Cobol，及其数据部和过程部——以及为定义每个部门而成立的独立委员会。 康威定律在这里发挥作用：“系统反映了构建它们的组织。” 因此，数据库社区从 Cobol DBTG（数据库任务组）继承了人为的数据-程序分离。 实际上，数据库在出生时就与其过程孪生兄弟分离，并且从那时起一直在努力重新结合——已经近 40 年了。
重新统一进程始于 20 世纪 80 年代中期，当时存储过程被添加到 SQL 中（在此向 Britton-Lee 和 Sybase 的那些勇敢、坚强的人们表示由衷的感谢）。 紧随其后的是对象关系数据库的激增。 到 20 世纪 90 年代中期，即使是许多最著名的 SQL 供应商也在自己的系统中添加了对象。 尽管所有这些努力本身都很好——并且尽管各行各业的夸夸其谈者发出了“面向对象数据库优于一切”的过度兴奋的主张——但事实证明，它们中的每一个都注定会因同一个根本缺陷而失败：与所有从头开始的语言设计相关的固有高风险。
早期对象关系数据库中内置的大多数语言都非常糟糕，这也没有帮助。 令人高兴的是，现在有几种优秀的面向对象语言，它们得到了很好的实现，并提供了出色的开发环境。 Java 和 C# 是两个很好的例子。 重要的是，最新一代 OO 环境的标志性特征之一是它们提供了一个通用语言运行时，该运行时能够为几乎所有语言提供良好的性能。
真正的大新闻是，这些语言也已完全集成到当前的对象关系数据库中。 运行时实际上已添加到数据库引擎本身中，这样现在可以编写数据库存储过程（模块），同时在这些语言中将数据库对象定义为类。 随着数据封装在类中，你突然能够实际编程和调试 SQL，使用一个看起来令人欣慰地熟悉的持久编程环境，因为它要么是 Java 的扩展，要么是 C# 的扩展。 是的，请稍作停顿思考一下：SQL 编程配备了版本控制、调试、异常处理以及你通常与完全高效的开发环境相关联的所有其他功能。 SQLJ，SQL 和 Java 的良好集成，已经可用——甚至更好的想法正在酝酿之中。
当然，这样做的好处是，我们在过去 40 年中一直在与之抗争的数据库内部/数据库外部二分法正在成为过去。 现在，字段是对象（值或引用）； 记录是对象（字段）的向量； 表是记录对象的序列。 反过来，数据库正在转变为表的集合。 这种对象化的数据库系统视图提供了巨大的杠杆作用——足以实现我们即将讨论的许多其他革命。 这是因为，有了这种新的视角，我们就获得了一种强大的方式来构建和模块化系统，尤其是数据库系统本身。
一个干净的、面向对象的编程模型也提高了数据库触发器的功能和潜力，同时使构建和调试触发器变得更加容易。 然而，这可能是一把双刃剑。 作为规则编程的数据库等价物，触发器是有争议的——既有批评者也有支持者。 那些讨厌触发器及其启用的活动数据库的人可能不会被现在有更好的语言基础可用的论点所动摇。 然而，对于那些相信活动数据库的人来说，构建系统应该容易得多。
如果数据库系统架构多年来没有不断地模块化和合理化，这一切甚至都不可能实现。 这种固有的模块化现在使得数据库与语言运行时以及后续页面中列出的各种其他正在进行的革命能够集成——它们中的每一个都作为核心数据管理器的扩展来实现。
TPlite 再次出击。 数据库由业务逻辑封装，在存储过程出现之前，业务逻辑始终在 TP（事务处理）监视器中运行。 它位于经典的三层演示/应用程序/数据架构的中间。
随着存储过程的引入，TP 监视器本身被双层客户端/服务器架构所取代。 然后，随着 Web 服务器和 HTTP 的出现，三层架构重返中心舞台，摆钟又摆了回来——部分原因是处理 HTTP 和数据库客户端/服务器协议之间的协议转换，并在 Web 服务器上提供演示服务 (HTML)，但也为 EJB 或 COM 业务对象提供执行环境。
随着电子商务的持续发展，大多数 Web 客户端都发生了转变，以至于今天，取代浏览器盲目地显示服务器交付的任何内容，你往往会发现客户端应用程序——通常用 JavaScript 编写——它们具有大部分演示逻辑，并使用 XML 与服务器通信。 尽管大多数电子商务客户端继续进行屏幕抓取，以便从网页中提取数据，但 XML Web 服务作为向胖客户端应用程序传递数据的一种方式，其使用正在增长。 同样，即使今天大多数 Web 服务仍然由经典的 Web 服务器（例如 Apache 和 Microsoft IIS）提供，数据库系统也开始监听端口 80 并直接提供 SOAP 调用接口。 在这个美好的新世界中，你可以采用一个类——或一个已在数据库系统中实现的存储过程——并将其作为 Web 服务发布在 Internet 上（WSDL 接口定义、DISCO 发现、UDDI 注册和 SOAP 调用存根都将自动生成）。 因此，如果你愿意， “TPlite”客户端/服务器模型正在卷土重来。
应用程序开发人员仍然可以选择三层和 n 层设计选项，但现在两层再次成为一种选择。 对于许多应用程序来说，客户端/服务器方法的简单性无疑具有吸引力。 尽管如此，考虑到数据库提供了巨大的攻击面，安全问题可能会导致许多设计人员选择三层服务器架构，该架构仅允许非军事区中的 Web 服务器和安全地隐藏在私有网络上的这些 Web 服务器后面的数据库系统。
尽管如此，我们突然拓宽的视野似乎提供的所有可能性都令人眼花缭乱。 首先，Web 服务现在是否有可能——甚至很可能——最终成为我们联合异构数据库系统的方式？ 这绝非确定，但它足够有趣，足以引发大量的研究活动。 其中，正在讨论的基本问题包括：数据库的正确对象模型是什么？ 在线路上表示信息的正确方法是什么？ 模式如何在 Internet 上工作？ 因此，模式可能会如何演变？ 如何最好地在 Internet 上查找数据和/或数据库？
你很可能开始意识到，未来的旅程注定会有点颠簸。 系好安全带。 你甚至还不了解其中的一半。
理解工作流的意义。 因为 Internet 是服务器和客户端的松散耦合联合体，所以客户端偶尔会断开连接，这只是生活中的一个事实。 同样，它们必须能够在整个中断期间继续运行，这也是一个事实。 这表明，Internet 软件必须构建为异步任务，而不是紧密耦合的、基于 RPC 的应用程序； 它们必须构建为由多个自治代理启用的工作流。 为了更好地了解这些设计问题，请考虑电子邮件，用户希望即使在未连接到网络时也能够阅读和发送邮件。
所有主要的数据库系统现在都集成了排队机制，这些机制使得定义队列、对消息进行排队和出队、将触发器附加到队列以及调度队列负责驱动的任务变得容易。 此外，随着数据库系统添加了良好的编程环境，现在可以更轻松、更自然地自由使用队列。 将队列发布为 Web 服务只是另一个相当明显的优势。 但是我们发现自己面临着一些更具争议性的问题，因为——凭借所有这些新功能——队列不可避免地被用于简单的 ACID（原子性、一致性、隔离性、持久性）事务之外的更多用途。 最特别的是，趋势是在基本排队系统之上实现发布/订阅和工作流系统。 关于如何最好地处理工作流和通知的想法仍然存在争议——并且是正在进行的实验的重点。
研究人员面临的关键问题是如何构建工作流。 坦率地说，几十年来，我们一直没有找到解决这个问题的通用解决方案。 然而，由于当前问题的紧迫性，我们可以预期在不久的将来会看到大量的解决方案。 从所有这些解决方案中，肯定会出现一些清晰的设计模式，然后这些模式应该会引导我们走向研究挑战：表征这些设计模式。
基于数据立方体抽象构建。 早期关系数据库系统使用索引作为表副本，以实现垂直分区、关联搜索和方便的数据排序。 数据库优化器和执行器在这些结构上使用半连接操作来运行覆盖索引上的常用查询，从而实现巨大的性能提升。
多年来，这些早期思想演变为物化视图（通常由触发器维护），物化视图扩展远远超出了简单的覆盖索引，从而能够加速访问星型和雪花型数据组织。 在 20 世纪 90 年代，我们向前迈进了一步，识别了“数据立方体”OLAP（在线分析处理）模式，通过该模式，数据可以同时沿多个不同维度进行聚合。 研究人员开发了用于自动化立方体设计和实现的算法，这些算法已被证明既优雅又高效——以至于多 TB 事实表的立方体现在可以用几 GB 来表示。 实际上，所有主要的数据库引擎都已依赖于这些算法。 但这绝不表示创新的终结。 事实上，现在有相当多的研究致力于这一领域，因此我们可以期待更好的立方体查询和可视化工具。
更接近知识一步。 为了了解我们在进化之旅中的总体立场，可以说，在从数据到知识再到智慧的缓慢攀登过程中，我们现在才刚刚进入知识领域。 数据挖掘的出现代表了我们进入该领域的第一个步骤。
现在是时候在最早的挖掘工作的基础上再接再厉了。 我们已经发现了如何通过聚类、贝叶斯网络、神经网络、时间序列分析等来拥抱和扩展机器学习。 我们的下一步是创建一个学习表（为便于讨论，标记为 T）。 可以指示系统从属性 a、b 和 c 中学习列 x、y 和 z——或者，或者，对属性 a、b 和 c 进行聚类，甚至可能将 a 视为 b 的时间戳。 然后，通过将训练数据添加到学习表 T 中，一些数据挖掘算法为我们的数据集构建决策树或贝叶斯网络或时间序列模型。 我们需要的训练数据可以使用数据库系统已经广为人知的创建/插入隐喻及其提取-转换-加载工具来获得。 在输出端，我们可以在任何时候要求系统将我们的数据模型显示为 XML 文档，以便可以对其进行图形化呈现，从而更容易被人理解——但真正的力量在于该模型可以用作数据生成器（“向我展示可能的客户”）和测试器（“玛丽是可能的客户吗？”）。 也就是说，给定一个键 a、b、c，该模型可以返回 x、y、z 值——以及每个值的相关概率。 相反，T 可以评估某个给定值正确的概率。 所有这一切的意义在于，这仅仅是一个开始。 现在应该由机器学习社区将更好的机器学习算法添加到这个框架中。 我们可以期待未来十年在这个领域取得长足的进步。
当前最紧迫的研究挑战与需要更好的挖掘算法以及确定概率和近似答案的更好技术有关（我们稍后将进一步考虑这一点）。
重生的列式存储。 人们越来越频繁地遇到包含数千列的表，通常是因为表中的某个特定对象具有数千个测量的属性。 很多时候，这些表中的许多值都被证明为空。 例如，LDAP 对象只需要七个属性，同时定义了另外 1,000 个可选属性。
尽管将每个对象视为表中的一行可能非常方便，但实际上以这种方式表示它们将非常低效——无论是在空间还是带宽方面。 经典关系系统通常将每一行表示为值的向量，即使在行为空的情况下也是如此。 使用这种行式存储方法创建的稀疏表往往非常大，并且仅稀疏地填充了信息。
存储稀疏数据的一种方法是根据三个特征绘制数据：键、属性和值。 这允许非凡的压缩，通常以位图的形式，这可能会使查询时间减少几个数量级——从而实现大量新的优化可能性。 尽管这些想法最早出现在 20 世纪 70 年代早期的 Adabase 和 Model204 中，但它们目前正在复兴。
现在研究人员面临的挑战是开发用于列式存储物理设计的自动算法，以及有效地更新和搜索它们。
处理混乱的数据类型。 从历史上看，数据库社区一直将自己与信息检索社区隔离开来，宁愿对所有与混乱的数据类型（如时间和空间）有关的事情视而不见。 （请注意，并非数据库社区中的每个人都鸵鸟心态——只是我们大多数人。） 事实证明，当然，我们确实有大量工作要做，仅仅是为了处理“简单的事情”——数字、字符串和关系运算符。 尽管如此，不可否认的事实是，今天的实际应用程序往往包含大量的文本数据，并且经常包含时间和空间属性。
令人高兴的是，将持久编程语言和环境集成到数据库架构中，现在为我们提供了一种相对简单的方法来添加提供文本、时间和空间索引和访问所需的数据类型和库。 事实上，SQL 标准已经在这些领域中的每一个领域都得到了扩展。 尽管如此，所有这些数据类型——尤其是文本检索——都需要数据库能够处理近似答案并采用概率推理。 对于大多数传统的关系数据库系统来说，这代表着相当大的延伸。 也可以公平地说，在我们能够将文本、时间和空间数据类型无缝地集成到我们的数据库框架中之前，我们仍然需要在研究方面完成很多工作。 目前，我们没有明确的代数来支持近似推理，我们不仅需要它来支持这些复杂的数据类型，还需要它来支持更复杂的数据挖掘技术。 这个问题在前面我们讨论数据挖掘时也出现过——数据挖掘算法返回排名和概率加权的结果。 因此，有几种力量推动数据管理系统适应近似推理。
处理半结构化数据挑战。 尽管可能不方便，但并非所有数据都完全适合关系模型。 斯坦福大学教授詹妮弗·威多姆观察到，我们都从模式 <stuff/> 开始，然后弄清楚要添加什么结构和约束。 同样真实的是，即使是设计最好的数据库也无法包含所有可能的约束，并且注定会留下至少一些未指定的关系。
如何最好地应对这一现实是一个在数据库社区内引发巨大争议的问题。 辩论的一方是激进分子，他们认为应该将网络空间视为一个可以使用 XQuery++ 操作的大型 XML 文档。 另一方面，保守派认为结构是你的朋友——并且，通过扩展，半结构化数据只不过是一团最好避免的完美混乱。 这两个阵营都有很好的代表——并且经常按年龄分层。 很容易观察到，真相几乎肯定介于这两种极端观点之间，但也很难确切地看到这部电影将如何结束。
然而，一个值得注意的有趣发展与数据库系统和文件系统的集成有关。 在自己的个人系统上保存数千封电子邮件、文档、照片和音乐文件的个人很难再找到任何东西。 扩展到企业级别，文件数量达到数十亿，你就遇到了同样的问题，只是规模更大。 传统的文件夹层次结构方案和文件管理实践根本无法应对我们今天面临的信息海啸。 因此，需要一个完全索引的、半结构化的对象数据库，以实现为我们提供体面精度和召回率的搜索功能。 这一切都意味着什么？ 矛盾的是，文件系统似乎正在演变为数据库系统——如果说这还不能说明半结构化数据问题有多么根本，那就说明不了什么了。 数据管理架构师仍然有大量工作要做，才能声称已经将这个问题制服。
具有历史意识的流处理。 我们的世界越来越充斥着由仪器生成的数据流，这些仪器监控环境以及在这些环境中发生的活动。 例子不胜枚举，但以下仅举几个例子：扫描天空的天文望远镜； 解码分子的 DNA 测序仪； 识别和记录过往货车的条形码阅读器； 跟踪术后恢复室患者生命体征的手术室监护仪； 观察潜在欺诈迹象的手机和信用卡扫描系统； 跟踪供应链网络中产品流动的 RFID 扫描仪； 以及已编程为感知其环境的智能灰尘。
这里的挑战与其说与处理所有这些流数据有关——尽管这当然确实代表着一个重大挑战——不如说与将传入数据与为每个感兴趣的对象存储的历史信息进行比较有关。 此类流处理系统的数据结构、查询运算符和执行环境与人们在经典数据库管理系统环境中习以为常的结构截然不同。 本质上，每个到达的数据项都代表着针对现有数据库的相当复杂的查询。 这里令人鼓舞的消息是，研究人员已经构建流处理系统相当长一段时间了，这项工作中的许多想法已经开始出现在主流产品中。
触发数据库订阅者的更新。 企业数据仓库的出现催生了一种批发/零售数据模型，通过该模型，庞大企业数据存档的子集发布到企业内的各个数据集市，每个数据集市的建立都是为了满足某些特定利益群体的需求。 这种批量发布/分发/订阅模型已经非常普遍，它采用了你能够想象到的几乎所有复制方案。
现在应用程序设计的趋势是在仓库中安装自定义订阅——有时一次安装数百万个。 更重要的是，实时通知被要求作为每个订阅的一部分。 每当任何与订阅相关的数据到达时，系统都会被要求立即将此信息传播给订阅者。 医院想知道患者的生命体征是否发生变化，旅行者想知道他们的航班是否延误，金融应用程序要求被告知任何价格波动，库存应用程序想被告知库存水平的任何变化，就像信息检索应用程序想在发布任何新内容时收到通知一样。
事实证明，发布/订阅系统和流处理系统在结构上实际上非常相似。 首先，数百万个常驻查询被编译成一个数据流图，然后对该图进行增量评估，以确定哪些订阅受到更改的影响，因此必须通知哪些订阅。 实际上，更新后的数据最终会触发对每个已表示对该特定信息感兴趣的订阅者的更新。 所有这一切背后的技术在很大程度上借鉴了 20 世纪 90 年代的活动数据库工作，但你可以确信这项工作仍在不断发展。 特别是，研究人员仍在寻找更好的方法来支持最复杂的常驻查询，同时优化处理不断扩展的查询和数据量的技术。
保持查询成本在可控范围内。 到目前为止讨论的所有更改肯定会对数据库查询优化器的运行产生巨大影响。 例如，将用户定义的函数深入到查询中肯定会使成本估算变得复杂。 事实上，具有高偏差的真实数据一直存在问题。 但是我们将无法再对此不理不睬，因为在我们一直在探索的美好新世界中，关系运算符只不过是非过程程序的外部循环，因此确实必须并行执行并以尽可能低的成本执行。
基于成本的静态计划优化器仍然是那些可以在几秒钟内运行的简单查询的主要支柱。 然而，对于更复杂的查询，查询优化器必须能够适应不断变化的工作负载以及数据偏差和统计信息的波动，同时还要以更动态的方式进行计划——根据系统负载和数据统计信息的变化来更改计划。 对于 PB 级数据库，唯一的解决方案可能是运行连续数据扫描，并将查询搭载在扫描之上。
主内存数据库的到来。 我们面临的部分挑战源于磁盘和内存容量的疯狂增长速度，大大超过了带宽容量和当前最小化延迟的能力。 过去，读取所有 RAM 不到一秒钟，读取磁盘上存储的所有内容不到 20 分钟。 现在，多 GB RAM 扫描需要几分钟，而 TB 磁盘扫描可能需要几个小时。 随机访问比顺序访问慢 100 倍也变得痛苦地显而易见——并且差距正在扩大。 诸如此类的比率与我们从小就习惯的比率不同。 它们需要新的算法，让多处理器系统智能地共享一些海量主内存，同时优化珍贵的磁盘带宽的使用。 与此同时，数据库算法需要进行大修，以适应真正海量的主内存（例如，能够容纳数十亿页和数万亿字节）。 简而言之，主内存数据库的时代终于到来了。
智能设备：数据库无处不在。 我们应该注意到，在与共享内存相反的另一个极端，智能正在向外移动到电话、相机、扬声器和每个外围设备。 每个磁盘控制器、每个相机和每个手机现在都结合了数十兆字节的 RAM 存储和功能非常强大的处理器。 因此，现在完全可以拥有智能磁盘和其他智能外围设备，它们提供数据库访问（通过 SQL 或其他非过程语言）或 Web 服务访问。 从面向块的接口到文件接口，然后再到一组服务接口的演变，一直是数据库机器倡导者三十年来的明确目标。 过去，这需要专用硬件。 但情况不再如此，因为由于摩尔定律，磁盘现在配备了快速的通用处理器。 因此，数据库机器很可能会因此而重生。
在相关进展中，构建传感器网络的人们发现，如果将每个传感器视为表中的一行（其中传感器值构成该行的字段），编写程序来查询传感器就会变得非常容易。更重要的是，当通过一些新算法增强后，当前分布式查询技术被证明能够很好地支持高效的程序，这些程序可以最大限度地减少带宽使用，并且非常容易编写代码和调试。微型数据库系统开始在智能尘埃中出现就证明了这一点——这一发展肯定会让任何曾经摆弄过数据库的人感到震惊和敬畏。
自我管理且始终在线。 实际上，如果每个文件系统、每张磁盘、每部电话、每台电视、每台相机以及每一片智能尘埃内部都装有数据库，那么这些数据库系统将需要是自我管理的、自我组织的和自我修复的。数据库界对其在自动化系统设计和操作方面已经实现的进步感到自豪。结果是数据库系统现在无处不在——您的电子邮件系统是一个简单的数据库，您的文件系统也是如此，您经常使用的许多其他熟悉的应用程序也是如此。正如您可能从本文列举的新兴功能列表中看出的那样，数据库正变得越来越复杂。所有这些都意味着我们仍然有大量工作要做，以创建足够强大的分布式数据存储，以确保信息永远不会丢失，并且查询始终以一定的效率处理。
应对信息洪流
个人和组织正被无情的信息洪流淹没。因此，您曾经认为关于数据库架构的一切都在被重新思考。
最重要的是，算法和数据正在通过将熟悉的、可移植的编程语言集成到数据库系统中而统一起来，这样一来，您被教导的关于将代码与数据分离的所有设计规则将不再适用。相反，您将使用可扩展的对象关系数据库系统，在其中可以使用非过程关系运算符来操作对象集。与此同时，数据库系统正在顺利地成为 Web 服务——这将对我们如何构建应用程序产生巨大的影响。在这种新的思维模式下，DBMS 成为对象容器，队列是需要添加的第一个对象。未来的事务处理和工作流应用程序将基于这些队列构建。
显然，我们所有人面前都有大量的工作要做。研究挑战无处不在——而且没有一个是微不足道的。然而，其中最大的挑战将与近似推理和精确推理的统一有关。我们大多数人来自精确推理的世界——但我们的大多数客户现在都在提出需要近似或概率性答案的问题。
为了应对这种情况，数据库正在从 SQL 引擎演变为数据集成器和中介器，它们以多种不同的形式提供对数据的事务性和非过程性访问。这意味着数据库系统实际上正在成为数据库操作系统，各种子系统和应用程序可以很容易地插入其中。
从这里到那里将涉及比此处提及的更多的挑战。但我确实相信，大多数唾手可得的成果都集中在本文概述的主题周围，在这些领域取得的进展将很快触及几乎所有应用程序设计领域。
喜欢它，讨厌它？请告诉我们
[email protected] 或 www.acmqueue.com/forums
致谢
David DeWitt、Michael Stonebraker 和 Jennifer Widom 在 CIDR（创新数据系统研究会议）上发表的演讲激发了本文中提出的许多想法。
JIM GRAY 是微软可扩展服务器研究组的杰出工程师，也负责管理微软的湾区研究组。他因在事务处理方面的工作而被授予 图灵奖。时至今日，Gray 的主要研究兴趣仍然是数据库架构和事务处理系统。目前，他正在与天文学界合作，帮助构建在线数据库，例如 http://terraservice.net 和 http://skyserver.sdss.org。 Gray 预计，一旦世界上所有的天文数据都放在互联网上，并可以作为一个单一的分布式数据库访问，互联网将成为世界上最好的望远镜。
MARK COMPTON 目前经营一家名为 Hired Gun Communications 的营销传播咨询集团，他在技术市场工作了近 20 年。在自己创业之前，他曾在 Silicon Graphics 领导营销计划，在那里他是该公司 Indigo 系列桌面工作站品牌计划的驱动力。在 20 世纪 80 年代中期的一个四年期间，他曾担任《Unix Review》的主编，该杂志当时被认为是 Unix 软件工程师的领先出版物。
© 2005 1542-7730/05/0400 $5.00
最初发表于 Queue 第 3 卷，第 3 期——
在 数字图书馆 中评论这篇文章
更多相关文章
Qian Li, Peter Kraft - 事务和无服务器天生一对
数据库支持的应用程序是无服务器计算令人兴奋的新领域。通过紧密集成应用程序执行和数据管理，事务性无服务器平台实现了许多在现有无服务器平台或基于服务器的部署中不可能实现的新功能。
Pat Helland - 身份的任何其他名称
新兴的系统和协议既收紧又放松了我们对身份的概念，这很好！它们使完成工作变得更容易。 REST、IoT、大数据和机器学习都围绕着故意保持灵活，有时甚至是模棱两可的身份概念。身份概念是我们分布式系统的基本机制的基础，包括互换性、幂等性和不变性。
Raymond Blum, Betsy Beyer - 实现数字永恒
今天的信息时代正在为世界所依赖的数据创造新的用途和新的管理方式。世界正在从熟悉的物理人工制品转向更接近信息本质的新型表示方式。我们需要流程来确保知识的完整性和可访问性，以保证历史将被了解和真实。
Graham Cormode - 数据草图
您是否曾经感到被无尽的信息流淹没？ 似乎大量的新电子邮件和短信需要持续关注，还有电话要接听，文章要阅读，还有敲门声要回应。 将这些碎片拼凑在一起以跟踪重要内容可能是一个真正的挑战。 为了应对这一挑战，流数据处理模型越来越受欢迎。 其目的不再是捕获、存储和索引每一分钟的事件，而是快速处理每次观察，以便创建当前状态的摘要。
© 保留所有权利。