PDF超越关系数据库
数据访问不仅仅只有SQL。
MARGO SELTZER，SLEEPYCAT
环境中计算设备的数量和种类正在快速增加。真正的计算机不再受限于桌面或锁定在服务器机房中。掌上电脑、高度移动的平板电脑和笔记本电脑设备、掌上电脑以及移动电话手机现在为新应用程序和服务的交付提供了强大的平台。然而，这些设备仅仅是冰山一角。隐藏在视线之外的是支持普及计算基础设施所需的众多计算和网络元素。
随着如此强大的计算能力在公文包和口袋中随处可见，开发人员正在构建几年前还不可能实现的应用程序。如今可用的有趣服务包括文本和多媒体消息传递、基于位置的搜索和信息服务（例如，附近餐馆的按需评论）以及临时多人游戏。在未来几年，肯定会开发出新的移动和个性化服务类别，这些服务在今天还无法预测。
虽然这些服务在主要方面彼此不同，但它们也共享一些重要的属性。其中之一——本文的重点——是应用程序中内置的数据存储和检索功能的需求。消息传递应用程序需要可靠且无损地在网络中移动消息。基于位置的服务需要将物理位置映射到逻辑位置（例如，GPS或蜂窝塔坐标到邮政编码），然后查找基于位置的信息。游戏应用程序必须记录和共享分布式设备上游戏的当前状态，并管理内容检索和实时交付到每个设备。在所有这些情况下，快速、可靠的数据存储和检索至关重要。
一旦讨论转向数据存储和检索，关系数据库就会浮现在脑海。在过去的三十年中，关系数据库取得了巨大的成功，SQL已成为数据访问的通用语言。虽然数据管理几乎已成为RDBMS的代名词，但是，越来越多的应用程序更适合使用更轻量级的替代方案。
在本文中，我们首先简要回顾关系系统如何主导数据管理领域，讨论关系技术如何演变，介绍当今新兴应用程序以数据为中心的概述，并深入探讨当今和未来应用程序的数据管理需求。
关系数据库的史前史
关系数据库源于20世纪70年代IBM1,2和加州大学伯克利分校3的研究。关系数据库从根本上是对部署和维护复杂系统所需成本不断升级的一种反应。
关键的观察是，程序员非常昂贵，每当数据库的内容或物理组织发生变化时，他们都必须手动重写大量的应用程序软件。由于应用程序通常详细了解其数据的存储方式，包括其磁盘上的布局，因此重组数据库或向现有数据库添加新信息迫使对访问这些数据库的代码进行全面更改。
关系数据库通过两种方式解决了这个问题。首先，它们向应用程序隐藏了数据库的物理组织，并且仅提供了数据的逻辑视图。其次，它们使用声明性语言来描述特定查询中感兴趣的数据，而不是强迫程序员编写函数调用的集合来获取数据。这两个更改使程序员可以描述他们想要的信息，并将优化和访问的细节留给数据库管理系统。这种转变减轻了程序员在数据库布局或组织发生变化时重写应用程序代码的负担。
关系数据库在世界各地的IT部门和数据中心取得了巨大的成功。拥有大量数据要管理和使用这些数据的复杂应用程序的企业迅速采用了这项新技术。对关系产品的需求创造了一个每年许可收入达数十亿美元的市场。几家RDBMS供应商在20世纪80年代崛起，争夺这项利润丰厚的业务。
在随后的20年中，出现了两个相关的趋势。首先，RDBMS供应商增加了功能以提供市场差异化，并解决出现的每个新市场领域。其次，很少有应用程序需要当今RDBMS中提供的所有功能，因此随着功能集规模的增加，每个应用程序使用的功能集比例都在下降。
这种增加DBMS功能的驱动力伴随着复杂性的增加，并且大多数部署现在都需要经过数据库管理培训的专家来保持系统和应用程序的运行。由于这些系统是作为单体实体开发和销售的，因此即使应用程序可能只需要系统功能的一小部分子集，每个安装也要付出总体复杂性的代价。当然，一定有更好的方法。
新的前沿
我们不是第一个注意到这些变化潮流的人。1998年，主要的数据库研究人员得出结论，数据库管理系统变得过于复杂，自动化配置和管理变得至关重要。4 两年后，Surajit Chaudhuri和Gerhard Weikum提出了彻底重新思考数据库管理系统架构的建议。5 他们建议使数据库管理系统更加模块化，并拓宽我们对数据管理的思路，以包括相当简单的、基于组件的构建块。最近，Michael Stonebraker也加入了合唱，他认为“一种尺寸不再适合所有情况”，并举例说明了传统RDBMS架构不适用的特定应用程序示例。6
正如Stonebraker所论证的那样，关系供应商一直在提供RDBMS是满足任何数据管理需求的答案的错觉。例如，随着数据仓库和决策支持作为重要的应用领域出现，供应商已经调整产品以满足这些新领域中出现的特殊需求。他们通过在熟悉的SQL前端后面隐藏相当不同的数据管理实现来实现这一点。然而，当人们开始更深入地检查新兴数据需求时，这种模型就会崩溃。
以下部分介绍数据管理中出现的一些新问题。我们检查这些示例的目标是得出一些新兴的应用程序类别，对于这些类别，传统的数据管理方法可能不是最优的。
数据仓库。零售组织现在有能力记录每一笔客户交易，从而产生庞大的数据源，可以挖掘有关客户购买模式、产品受欢迎程度趋势、地域偏好以及无数其他现象的信息，这些现象可以被利用来增加销售额或降低业务成本。该数据库主要是读取操作：它通过定期向集合中添加新交易来批量更新，但分析师经常读取它，从中提取有用的信息。此应用程序领域的特点是巨大的表（数十或数百TB）、仅访问表中许多列中的少数几列的查询，以及需要扫描以多种不同方式排序的表。
目录服务。随着组织越来越依赖分布式资源和人员，对目录服务的需求激增。7 目录服务器提供对以分层结构排列的实体的快速查找，该分层结构通常与组织的分层结构匹配。LDAP标准在20世纪90年代应运而生，以应对重量级的ISO X.400/X.500目录服务。LDAP现在是许多供应商（例如，IBM Tivoli的Directory Server、Microsoft的Active Directory Server和Sun ONE Directory Server）的身份验证和身份管理系统的核心。与数据仓库一样，LDAP的特点是主要进行读取访问。查询可以是单行检索（查找与此用户对应的记录）或基于属性值的查找（查找工程部门中的所有用户）。多值属性的普遍存在使得关系表示非常低效。
网络搜索。互联网搜索引擎位于数据库管理和信息检索的交叉点。它们操作的对象通常是半结构化的（即HTML而不是原始文本），但是提出的查询最常见的是关键字查找，其中所需的响应是可能答案的排序列表。如今，几乎所有成功的搜索引擎都开发了自己的数据管理解决方案来解决这个问题，构建高效的倒排索引以及索引和查找的高度并行化实现。此应用程序主要是读取操作，具有批量更新和非传统索引。
移动设备缓存。小型移动设备的普及引入了另一类应用程序：在较小的、低功能设备上缓存较大数据集的相关部分。虽然今天的用户认为他们手机的目录是他们自己的数据集合，但另一种观点可能是将其视为全球电话和地址目录的缓存。此模型具有吸引人的特性——特别是能够随着条目的使用或需要来扩充本地数据集。移动电话基础设施需要类似的缓存功能来维护与设备的通信通道。在这些缓存中观察到的访问模式也是主要进行读取操作，并且数据本身是完全临时的；如有必要，可以丢失并重新生成。
XML管理。在线交易越来越多地通过交换XML编码的文档进行。今天的标准解决方案包括将这些文档转换为规范的关系组织，将其存储在RDBMS中，然后在希望使用它们时再次转换。随着创建、传输和操作的XML文档越来越多，这些转换变得不必要、效率低下且乏味。当然，一定有更好的方法。具有XQuery和XPath访问模式的本机XML数据存储代表了下一波存储演变。虽然新项目不断添加到XML存储库并从中删除，但文档本身在很大程度上是只读的。
流处理。流处理在这个数据密集型应用程序列表中有点格格不入。严格来说，流处理不是数据管理任务；它是一个数据过滤任务。也就是说，数据在某个源产生并流式传输到接收者，接收者过滤流以查找“有趣的”事件。例如，金融机构关注股票行情，寻找交易活跃的股票和/或交易不如预期活跃的股票。
这些流处理应用程序之所以包含在此处，是因为一个语言学原因：在这些环境中通常需要的过滤器看起来像SQL；然而，虽然SQL旨在对持久存储的表进行操作，但这些查询作用于实时数据值流。Stonebraker深入解释了数据库在完成此任务方面有多么差。也许更大的惊喜不是数据库系统在解决此任务方面装备不足，而是因为SQL看起来像是“正确”的查询语言，开发人员将关系数据库系统用于没有持久存储的应用程序！
流处理代表了一类应用程序，这些应用程序可以从SQL类查询语言中受益，该查询语言位于数据管理系统之上，该数据管理系统的属性与RDBMS截然不同。由于流式查询经常在时间窗口内观察到的数据上运行，因此一些瞬态本地存储是必要的，但是此存储不需要是持久的、事务性的或支持复杂的查询处理。相反，它需要速度极快。虽然关系数据库非常适合处理相对静态或缓慢变化的数据上的动态查询，但此类应用程序的特点是在高度动态的数据上具有相当静态的查询集。
灵活的解决方案
关系系统旨在满足OLTP（在线事务处理）工作负载，其特点是即席查询、大量的写入流量以及对强大的事务和完整性保证的需求。相比之下，此处描述的应用程序几乎都是读取主导的，而流式应用程序甚至没有利用持久数据，仅仅是SQL类查询语言。这些应用程序很少需要事务保证，并且所访问的数据几乎没有固有的关系。因此，数据管理问题变成了如何最好地满足这些不同类型应用程序的需求。正如Stonebraker所声称的那样，确实没有唯一的正确答案。相反，我们必须专注于可以根据特定应用程序的需求量身定制的灵活解决方案。
在当今不断变化的数据环境中，有几种方法可以提供灵活性。回归基本的方法是要求每个应用程序都构建自己的数据存储服务。虽然这种选择看似简单，但在除最简单的应用程序之外的所有应用程序中都不切实际。然而，今天运行的一些数据密集型应用程序是建立在简单的、自制的解决方案之上的。
解决灵活性需求的第二种方法是提供各种各样的数据管理选项，每个选项都针对特定的应用程序类别。我们看到这种方法正在传统的关系市场中兴起，其中SQL外观用于隐藏OLTP和数据仓库所需的不同功能。
第三种实现灵活性的方法是生产更可配置的存储引擎，以便可以根据各个应用程序的需求对其进行调整。此解决方案允许对单个存储系统进行集中投资，从而提高质量。然而，可配置性对使用数据库的开发人员提出了新的要求，因为他们必须了解配置选项，然后将数据管理组件正确地集成到他们的产品设计中。
实际上，市场上正在出现的解决方案是拥有少数几个合理可配置的存储系统，每个系统都可以在广泛的应用程序类别中使用。
解决方案必须具备两个基本属性才能满足当今涌现的广泛应用程序需求：模块化和可配置性。很少有应用程序需要数据管理系统中可能的所有功能。如果应用程序不需要某个功能，则不应在大小（占用空间、内存消耗、磁盘利用率等）、复杂性或成本方面为该功能“付费”。因此，灵活的引擎必须允许开发人员根据应用程序是否需要来使用或排除主要子系统。一旦系统足够模块化以允许真正的小占用空间，我们就会发现该系统部署在硬件平台上，这些硬件平台的性能差异惊人。在这些情况下，系统必须可配置到其运行环境：特定的硬件、操作系统和使用它的应用程序。在本文的其余部分，我们将更详细地讨论这两个属性。
模块化
有些人认为，数据库架构需要一场类似于计算机硬件中RISC革命的革命。传统的单体DBMS架构不够灵活，无法适应当今的数据需求，因此我们需要从小型、简单、可重用的组件集合中构建数据管理功能。例如，Chaudhuri和Weikum认为，与其将SQL视为简单的二元决策，不如以不同的复杂程度提供查询功能。您可以从具有B+树索引的单表选择处理器开始，该索引支持简单的索引、更新和选择。在此基础上，您可以添加事务。继续向上复杂性层次结构，考虑一个选择-投影-连接处理器。接下来，添加聚合。通过这种方式，您将SQL从一种单体语言转变为一系列连续丰富的语言，每种语言都作为组件提供，并满足大量的应用程序领域。任何特定的应用程序都选择它需要的组件。这种基于组件的架构的思想可以扩展到包括数据库设计的其他几个方面：并发控制、事务、日志记录和高可用性。
并发控制适用于类似于语言示例中呈现的层次结构。一些应用程序是完全单线程的，不需要任何锁定；其他应用程序具有低级别的并发性，并且可以通过表级锁定或API级锁定（即，只允许一个写入器或多个读取器同时进入数据库系统）来很好地服务；最后，高度并发的应用程序需要细粒度锁定和多个隔离级别（可能允许应用程序查看不完整事务已写入的值）。8 在传统的数据库管理系统中，假定锁定是存在的；在本文讨论的勇敢新世界中，锁定是可选的，可以使用不同的组件来提供不同的并发级别。
事务提供了一种错觉，即操作集合以原子单元应用于数据库，并且一旦应用，即使在应用程序或系统发生故障的情况下，操作也将持久存在。事务管理是大多数数据库管理系统的核心，但许多应用程序不需要事务。在基于组件的世界中，事务也应该是可选的。当它们存在时，系统可能仍然有许多不同的组件提供基本的事务机制、保存点（识别数据库可以回滚到的时间点的能力）、支持跨多个数据库的事务的两阶段提交、将大型操作分解为多个较小操作的嵌套事务以及撤消高级逻辑操作的补偿事务。
许多事务系统使用某种形式的日志记录来提供回滚和恢复功能。在这种情况下，几乎没有必要将日志记录视为可分离的组件，但它应该是可分离的。事务组件可能被设计为与多种实现一起工作，其中一些实现不使用日志记录（例如，现在覆盖方案，如影子页）。也许更有趣的是，日志记录系统可能在事务上下文之外有用；它可能用于审计或提供某种备份机制。在任何一种情况下，是否需要日志记录应该是应用程序设计人员的决定，而不是由数据库供应商强加的。
最后，有时数据非常关键，以至于停机时间是不可接受的。许多数据库系统提供复制或高可用性系统来解决此需求。虽然此功能通常在当今的系统中作为附加组件提供，但它们还不够深入。开发人员可能希望使用数据库的HA（高可用性）配置，但可能将其与另一家公司的HA底层结构结合使用。如果应用程序已经有一个执行心跳协议（或任何其他在组件发生故障时通知应用程序或系统的机制）、故障转移和冗余通信通道的底层结构，那么您将希望从数据库管理系统中排除这些组件并连接到现有功能。单体系统不允许这样做，而基于组件的模块化架构允许这样做。
除了提供更小、更简单的应用程序之外，具有良好定义、清晰、暴露接口的组件还提供了在单体系统中根本不可能实现的扩展性。例如，考虑构建事务系统所需的基本组件集：事务管理器、锁管理器和日志管理器。如果这些模块是开放且可扩展的，那么开发人员可以将各种系统构建到事务中，这些系统包含数据库系统未管理的项。例如，考虑一个网络交换机：配置数据库的状态取决于设备内部硬件的状态，反之亦然。如果可以通过允许程序员扩展锁定和日志记录系统以与它们通信，将对芯片和电路板的电气控制纳入事务，那么诸如“启动备份网络接口卡”之类的操作就可以实现事务性。
模块化是管理应用程序和系统的大小和复杂性的强大工具，同时也使应用程序和数据管理功能能够无缝交互。这种类型的架构使开发人员能够排除他们不需要的功能，并包含他们需要但数据库供应商未提供的功能。
可配置性
灵活数据管理系统的第二个属性是可配置性。模块化是一种架构机制，而配置主要是一种运行时机制。借助基于组件的架构，构建时配置涉及选择适当的组件。单个组件集合仍然可以在一系列功能差异很大的系统上运行。例如，仅仅因为两个应用程序都想要事务和B树，这并不意味着两者都可以支持数千兆字节的内存缓存。适应截然不同的环境的能力至关重要。可配置性是指系统与环境和应用程序需求的匹配程度。在本文中，我们讨论了关于硬件、应用程序运行环境（例如，操作系统）、应用程序的软件架构以及应用程序的“自然”数据格式的可配置性。
硬件环境引入了CPU速度、内存大小和持久存储功能的可变性。CPU速度和持久存储的可变性引入了用计算换取磁盘带宽的可能性。在快速处理器上，压缩数据（消耗CPU周期）以节省I/O可能是有益的；在PDA上，CPU周期稀缺且持久I/O速度快，压缩可能不是正确的权衡。
在资源受限的设备可能需要复杂的数据管理的世界中，开发人员必须能够控制数据库的内存和磁盘消耗策略。在不同的环境中，应用程序可能需要控制内存中数据结构的最大大小、持久数据的最大大小以及事务日志消耗的空间。这些资源的消耗策略必须由应用程序开发人员而不是最终用户设置，因为开发人员更有可能具有做出正确决策所需的技术知识。
持久存储技术的变异性也对数据库引擎提出了新的要求。它不仅必须在存在旋转磁存储介质的情况下良好工作，而且还应在其他介质（例如，闪存）上良好运行，这些介质对行为（例如，对特定存储位置的写入次数）有限制，并且它可能需要在没有任何持久存储的情况下运行。一些应用程序希望完全在主内存中管理数据，而无需持久性；一些应用程序希望在更新时具有完全同步的事务保证来管理数据；而一些应用程序则需要在两者之间取得平衡。这些策略中的每一个都应由相同的事务组件实现，但数据库应允许程序员控制数据是否在断电事件中持久存在，以及系统向最终用户做出的任何事务保证的严格程度。
尽管许多嵌入式系统现在能够使用COTS硬件平台，但仍然存在许多专有设备。通用的数据管理解决方案将可移植到这些专用硬件设备。它还将可移植到各种操作系统；移动电话手机上的操作系统提供的服务与具有千兆字节RAM的64路多处理器上的操作系统提供的服务不同，即使两者都运行Linux。如果数据管理系统要在任何地方运行，那么它必须仅依赖于大多数操作系统通用的服务，并且必须提供显式机制以通过简单的中间库或源代码可用性来实现可移植性。
即使在单个平台上，开发人员也会做出影响数据库系统的架构选择。例如，系统可以使用以下方式构建：单线程控制；一组协作进程，每个进程都是单线程的；单个进程中的多个控制线程；多个多线程进程；或严格的基于事件的架构。这些选择是由应用程序的需求、开发人员的偏好、操作系统和硬件组合驱动的。
数据库还必须避免对网络协议做出决策。由于数据库将在通信通过背板以及通过WAN进行的环境中运行，因此开发人员应选择适当的通信基础设施。专用电话交换机机箱可能包含自定义背板和协议，用于在冗余板之间进行快速通信；数据库不得阻止开发人员使用它。
到目前为止，可配置性一直围绕着适应应用程序的硬件和软件环境。我们讨论的最后一个配置领域围绕应用程序的数据展开。数据布局、索引和访问是关键的性能考虑因素。关于数据，有三个主要的设计点：物理聚簇、索引机制和数据库中项的内部结构。其中一些，如索引机制，实际上是运行时配置决策，而另一些则更多地是关于赋予应用程序进行设计决策的能力，而不是让设计人员因为数据库管理系统而被强制做出决策。
为旋转磁介质设计的数据库管理系统花费了大量精力将相关数据聚簇在磁盘上，以便可以通过每次重新定位事件传输大量数据来摊销寻道和旋转时间。一般来说，只要数据根据“正确”的标准聚簇，这种聚簇是好的。在可配置数据库系统的情况下，这意味着开发人员需要保留对主键选择的控制权（就像在大多数关系数据库管理系统中完成的那样），并且如果持久介质不存在或从访问“靠近”上次访问的位置没有显示出性能优势，则必须能够忽略聚簇问题。
与此相关的是，开发人员必须保持灵活性，以便为适合工作负载的主键选择索引结构。具有引用局部性的工作负载可能非常适合使用B+树；那些具有庞大数据集和真正随机访问的工作负载可能更适合使用哈希表。也许数据是高度维度的，需要完全不同的索引结构；上一节中讨论的可扩展性应允许开发人员提供特定于应用程序的索引机制，并将其与系统的所有其他功能（例如，锁定、事务）一起使用。至少，可配置数据库应提供一系列替代索引结构，这些结构支持迭代、快速相等搜索和范围搜索，包括对部分键的搜索。
与关系引擎不同，可配置引擎应允许程序员确定其数据项的内部结构。如果应用程序具有动态或不断发展的模式，或者必须支持即席查询，则内部结构应是一种支持高级查询访问（如SQL、XPath、XQuery、LDAP等）的结构。但是，如果模式是静态的并且查询集是已知的，则选择更直接映射到应用程序内部数据结构的内部结构可以显着提高性能。例如，如果应用程序的数据本质上是非关系的（例如，包含多值属性或大量非结构化数据），那么为了方便SQL访问而将其强制转换为关系组织将花费转换性能，并且不太可能获得关系存储的好处。同样，如果应用程序的数据是关系的，则将其强制转换为不同的格式（例如，XML、面向对象）将增加开销而没有任何好处。可配置引擎必须支持以对应用程序最自然的格式存储数据。然后，程序员有责任选择满足“最自然”标准的格式。
面向新问题的全新数据库
旧式数据库系统解决旧式问题；我们需要新式数据库来解决新式问题。虽然对传统数据库管理系统的需求不会消失，但当今的许多问题都需要可配置的数据库系统。即使没有水晶球，似乎也很清楚，未来的系统也需要很大程度的可配置性。作为程序员和工程师，我们学会选择合适的工具来完成工作；选择数据库也不例外。我们需要在一种模式下运行，在这种模式下，我们认识到数据管理中存在多种选择，我们应该选择合适的工具，以便尽可能高效、稳健和简单地完成工作。问
参考文献
1. Codd, E. F. 1970. 大型共享数据库的数据关系模型。通信 13(6): 377-387。
2. Astrahan, M. M., et al. 1976. System R：数据库管理的关系方法。数据库系统事务 1(2): 97-137。
3. Stonebraker, M. 1976. Ingres的设计与实现。数据库系统事务 1(3): 189-222。
4. Bernstein, P., et al. 1998. 关于数据库研究的Asilomar报告。 SIGMOD记录 27(4)。 http://www.sigmod.org/record/issues/9812/asilomar.html。
5. Chaudhuri, S., 和 Weikum, G. 2000. 重新思考数据库系统架构：迈向自调优RISC风格的数据库系统。《VLDB杂志》：1-10。 http://www.vldb.org/conf/2000/P001.pdf。
6. Stonebraker, M. 和 Cetintemel, U. 2005. 一刀切：一个过时的想法。《2005年国际数据工程会议论文集》（四月）。 http://www.cs.brown.edu/~ugur/fits_all.pdf。
7. Broussard, F. 2004. 2002-2007年全球IT资产管理软件预测与分析。IDC 文档 #30277。 http://www.idc.com/getdoc.jsp?containerId=30277&pid=35178981。
8. Gray, J. 和 Reuter, A. 1993. 事务处理：概念与技术，397-402页。San Mateo, CA: Morgan Kaufman Publishers。
喜欢它，讨厌它？请告诉我们
[email protected] 或 www.acmqueue.com/forums
MARGO I. SELTZER，哲学博士，是哈佛大学工程与应用科学学部计算机科学的Herchel Smith教授和副院长。她的研究兴趣包括文件系统、数据库和事务处理系统。Seltzer 也是 Sleepycat Software（Berkeley DB 的制造商）的创始人和首席技术官。她是斯隆基金会计算机科学研究员、邦廷研究员，并于 1996 年获得拉德克利夫青年教师奖学金和加州大学微电子学奖学金。她于 1996 年获得 Phi Beta Kappa 教学奖，并于 1999 年获得 Abrahmson 教学奖。她于 1983 年获得哈佛/拉德克利夫学院应用数学学士学位，并于 1992 年获得加州大学伯克利分校计算机科学博士学位。
© 2005 1542-7730/05/0400 $5.00
最初发表于 Queue 杂志第 3 卷，第 3 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Ethan Miller, Achilles Benetopoulos, George Neville-Neil, Pankaj Mehra, Daniel Bittman - 远内存中的指针
有效利用新兴的远内存技术需要考虑在父进程上下文之外操作富连接数据。正在开发的操作系统技术通过公开诸如内存对象和全局不变指针之类的抽象来提供帮助，这些抽象可以由设备和新实例化的计算遍历。这些想法将允许在未来的具有分离内存节点的异构分布式系统上运行的应用程序利用近内存处理来获得更高的性能，并独立扩展其内存和计算资源以降低成本。
Simson Garfinkel, Jon Stewart - 磨砺你的工具
本文介绍了我们在首次发布十年后更新高性能数字取证工具 BE (bulk_extractor) 的经验。在 2018 年至 2022 年间，我们将程序从 C++98 更新到 C++17。我们还进行了完整的代码重构并采用了单元测试框架。DF 工具必须经常更新，以跟上其使用方式的变化。对 bulk_extractor 工具更新的描述可以作为可以和应该做什么的示例。
Pat Helland - 自主计算
自主计算是一种业务工作模式，它使用协作来连接领地及其特使。这种基于纸质表格的模式已经使用了几个世纪。在这里，我们解释了领地、协作和特使。我们研究了特使如何在自主边界之外工作，并在保持局外人身份的同时提供便利。我们还研究了如何启动、长时间运行并最终完成跨不同领地的工作。
Archie L. Cobbs - 持久性编程
几年前，我的团队正在为增强型 911 (E911) 紧急呼叫中心进行商业 Java 开发项目。我们试图使用传统的 Java over SQL 数据库模型来满足该项目的数据存储需求，但感到沮丧。在对项目的特定需求（和非需求）进行一些反思之后，我们深吸一口气，决定从头开始创建我们自己的自定义持久层。
© 保留所有权利。