愤世嫉俗者
PDF数据的成本
Chris Suver，微软
在过去的几年里，人们让自己相信他们发现了一种被忽视的数据形式。这种新的数据形式是半结构化的。呸！没有什么新的数据形式。人们所发现的实际上是经济学对数据类型化的影响——但如果你将问题描述为经济学问题，那就没那么令人兴奋了。然而，这更准确和更有价值。清楚地看到半结构化数据的现实，实际上可以改进数据处理（字面意义上的）。然而，只要我们通过“新型数据”的模糊视角来看待这个问题，我们将继续误解问题，并开发出误导性的解决方案来解决它。是时候改变这一切了。
为了使数据能够可靠地在应用程序或工具（如数据库）中操作，数据必须是类型化的，或者为了高可靠性，数据必须是强类型化的。这是必要的，因为在某个时候，底层硬件必须选择正确的电路来处理这些位。早已证明任何数据都可以被类型化——事实上，是强类型化的。然而，今天大多数数据都不是类型化的（即结构化的）。这仅仅是因为不值得花费资源对数据进行类型化（即，数据的价值根本不足以证明这项投资是合理的）。
对数据进行类型化会产生一些成本
- 设计时间成本，或实际确定并将类型（模式设计）应用于数据的成本更高。
- 运行时资源的成本增加。这包括但不限于 CPU 成本（即，复杂的连接可能会很慢）。
- 当我们使用需要处理强类型数据所需的精度的工具时，应用程序开发成本更高。这通常包括理解（或几乎解码）类型描述的成本。
- 最后但同样重要的是，用户实际查询数据的成本更高，因为查询本身要复杂得多（以至于大多数用户实际上无法使用 XQuery 或 SQL 等语言构建结构化查询）。
成本/效益分析是区分数据的真正方法；它有多有价值？如果价值足够，就会有人对其进行类型化。如果没有，就不会有人对其进行类型化。自从书面记录存在以来，就已经做出了这个决定。随着 XML 的出现，它并没有改变。简单的经济学控制着数据是类型化的还是非类型化的——而简单的经济学我们可以理解。
从这个前提出发，我认为“半结构化数据”这个术语可能会产生误导。我经常看到“半结构化”被理解为数据本质上是不同的。我看到很多人将此视为专有名词，视为“新事物”。也许如果我们选择“不完全结构化”或“半类型化”的描述，就不会有那么多困惑了（可悲的是，这些词语不太容易朗朗上口）。 essential 的关键点是数据的结构化（或类型化）只是部分完成。并不是说数据本质上是不同的，也不是说数据没有类型（或无法类型化）。仅仅是因为完全定义数据类型的努力是不值得的。因此，作者仅添加满足当前需求所需的类型信息。请记住，半结构化数据是一项未完成的任务，而不是根本上的新事物。仅仅是信息只有部分类型信息到位。
通过从这个替代的角度来看待数据——类型化是您为实现价值而必要做的事情——我们现在可以查看我们的工具、功能和产品，看看成本/效益如何与用户的需求相匹配。
我们可以看看一些我们都熟悉和喜爱的当今数据技术如何发挥作用的例子。我们还可以看看已经成功的技术，并了解其原因。
一个极端是今天存储在 SQL 数据库中的数据，例如会计数据（显然是高价值数据）。显然，编写 SQL 模式、查询，甚至输入信息的成本非常高。但是数据的价值和查询结果的价值更高。高编写成本，但结果的价值巨大，使这些数据库取得了巨大的成功。
另一个极端是 Web 上的数据。总的来说，这是非常低的价值（又一个提高性能的药物网站到底有多有价值？）。但是对于读者来说，几乎没有编写成本。Yahoo、Google 和 MSN 等搜索引擎使查询这些数据的成本几乎为零，无论是在编写查询还是执行时间方面。 “准备”和正确查询数据的成本恰当地反映了其价值。搜索被大量使用，即使其大部分原始数据没有价值，并且结果通常是嘈杂的。低价值数据，但与低成本相匹配，使其成为成本/效益的胜利。因此，这是 Web 上使用最广泛的工具之一，又一次明显的成功。
在这两个极端之间是 XML，用于文本标记——类似于 HTML 和 SGML（标准通用标记语言）——以及数据传输。这两种用途都需要低编写成本和软类型系统。我将 XML 类型化称为软系统，因为类型化是在处理 XML 时应用于数据的。通常，发送者和接收者使用的类型是不同的。有时这些差异很大，有时很小，但任何差异都意味着传输本身必须是软类型化的，以便它可以轻松地适应不同的用途。
因此，XML 的编写成本很低。作者可以选择添加尽可能多的元数据（即结构），或尽可能少的元数据。这里，我们再次看到了技术与用户之间完美匹配的情况。从这个角度来看，XML 受到欢迎是有道理的。
从这个角度来看待查询 XML 也很有启发。 XPath（1.0 版）是查询 XML 的成功工具。 DTD（文档类型定义）的使用是描述 XML 文档的常用方法。那么 XQuery 和 XSD（XML 模式定义）呢？它们没有受到同样的欢迎。它们没有像 DTD 和 XPath 首次推出时那样流行起来。部分原因是时机，但我认为最终原因是 XQuery 和 XSD 都过于复杂。直接结果是，它们在价值适中的数据上使用过于昂贵。它们现在和将来都会在 XML 中找到用武之地，作为昂贵数据的传输方式——例如，商业 Web 服务。然后成本/效益分析就奏效了。
成本不能证明努力合理的另一个例子是文档数据。大多数文档的低数据价值可以解释为什么文档很少被加载到高度结构化的存储中。虽然这显然是可能的，但在大多数情况下，所涉及的成本根本无法通过回报来证明是合理的。（对此也有例外：律师事务所和其他以文档为主要业务的用户经常将文档存储在非常复杂的存储库中。这仅仅是因为文档确实具有证明这项巨大投资是合理的必要价值。对于普通用户来说，情况并非如此。）
我们不应该谈论这种“新的”半结构化数据的本质。相反，当我们看待数据技术时，我们需要使用成本/效益分析——包括在没有完整类型描述的情况下满足数据需求。成本是多少，我们目标数据的价值有多大，以及，当一切都完成后，用户是否会受益？如果他们受益（并且应该非常清楚），那么我们就有一个赢家。如果他们没有受益，或者不清楚，那么我们就没有赢家。这是我们为了取得成功而必须提出的困难且有些平凡的问题。好消息是现在，我认为，我们有一个坚实的框架来评估这些选择。
CHRIS SUVER 是微软的软件架构师，在 SQL Server 组中从事数据访问和 XML 工作。他从 1970 年代开始参与数据库工作，涵盖数据库应用程序、库、工具、语言和引擎。这包括在 Microrim、dbVista 和 Cascade/DB 以及他创立的两家初创公司 Precedent Systems 和 MicroQuill 的工作。
最初发表于 Queue 第 3 卷，第 8 期——
在 数字图书馆 中评论本文
更多相关文章
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 - 持久性编程
几年前，我的团队正在为一个商业 Java 开发项目工作，该项目是为增强型 911 (E911) 紧急呼叫中心开发的。我们试图使用传统的 Java over SQL 数据库模型来满足该项目的数据存储需求，但感到很沮丧。在对项目的特定需求（和非需求）进行一些反思之后，我们深吸一口气，决定从头开始创建我们自己的自定义持久层。
© 保留所有权利。