PDF从网络中学习
网络教会了我们许多关于分布式计算的经验，但其中一些最重要的经验尚未完全被接受。
ADAM BOSWORTH，谷歌
在过去的十年中，我们目睹了一场计算领域的革命，其范围和影响超越了以往任何时期，同时也改变了我们对“好”与“坏”计算的看法。网络教会了我们一些违反直觉的经验
1. 简单、宽松、略微草率的可扩展文本格式和协议通常比复杂而高效的二进制格式和协议更有效。 因为没有准入门槛，所以这些是理想的选择。一个自下而上的倡议可以迅速围绕它们形成，并在采用方面达到临界点。换句话说，任何人都可以编写HTML，无论他们的语法多么糟糕，因为浏览器非常宽容；甚至编写一个HTTP服务器也比编写一个CORBA或DCOM服务器更容易得多。更重要的是，如果文本格式不起作用，人们可以轻松地将HTTP请求或HTML邮件发送给朋友，他们会在他们选择的文本工具中检查它，并解释哪里不正确。简而言之，拥有一个“普通”人可以检查、理解、增强和编写的格式，对于在自下而上的世界中被采用至关重要。
2. 值得将事情做得足够简单，以便可以并行利用摩尔定律。 这意味着一个系统可以在处理传入请求的量以及理想情况下处理复杂性方面或多或少地线性扩展。例如，谷歌能够处理大量请求，这些请求要求相当复杂的工作（从数十亿文档中找到与以下词语“最相关”的所有文档），这主要是因为它可以在底层语料库的大小和查询量方面线性扩展。当然，DNS是这方面最好的例子，但缓存也是如此，这引出了我的第3点。
3. 大部分时间处于陈旧状态是可以接受的。 大多数数据不会频繁更新，如果会更新的话。它作为新版本插入（因为审计跟踪问题等）。因此，您看到的内容有点过时也没关系。例如，如果使用FedEx的跟踪器查找包裹，并且它显示的数据过时了30分钟，这几乎不会是灾难性的。除非在会议或赶飞机方面卡得太紧，否则即使航空公司的着陆信息过时两到三分钟，也不会有任何严重的后果。这个事实通过允许将数据惰性复制到额外的磁盘上，从本质上实现了可扩展性。
4. 群体的智慧效果惊人。 网络上成功的系统是自下而上的。它们不会以自上而下的方式强制规定太多。相反，它们通过临界点自我控制。例如，Flickr不会告诉用户照片使用什么标签。远非如此。任何用户都可以用任何东西标记任何照片（嗯，我认为你不能使用空格）。但是，这是一个关键的但是，Flickr确实提供了关于最受欢迎标签的反馈，并且那些寻求照片关注或喜欢照片的人会很快学会使用该词汇，如果它有意义的话。事实证明，它非常稳定。Del.icio.us对链接也做了同样的事情（实际上是第一个做的）。谷歌在实现更相关的搜索方面的成功是基于利用群体的智慧（PageRank）。RSS 2.0正在兴起，因为有大量的用户在阅读它，而且它易于读/写，因此人们决定在发布内容时利用它。这并不是说它对于联合内容以外的其他事物来说是一个好或坏的格式（对于联合内容，我认为它非常好）。相反，它足够好用。
5. 人们理解由树状文档（HTML）组成的图，这些文档通过链接（URL）相关联。 在某些方面，我发现这是最令人惊讶的。多年来，我们一直认为人们在树方面有困难，更不用说图了。突然超链接出现了，只要有一个后退按钮，它们就能工作。
不令人惊讶的经验
也有一些不令人惊讶的经验需要重新学习
6. 关注物理规律。 作为一个简单的经验法则，单个服务器通常每秒可以处理大约100个请求（我会说，如果请求简单，则在一个数量级内向上浮动，如果非常复杂，则向下浮动）。因此，如果目标是让每个服务器支持1,000个并发用户，那么尽量避免事件模型，其中每个用户每10秒钟，更不用说每秒钟，ping服务器的次数超过一次。简而言之，避免在服务器上对鼠标移动或按键或每次滚动条拖动三毫米的级别上响应事件的细粒度代码模型，因为如果这样做，您将每秒生成大约10个事件，或者说数量级过高。顺便说一句，即使每个服务器只支持10个并发用户是可以接受的，通信通常也是脆弱的，并且采用极其细粒度的模型不是一个好主意，因为通信中的一个小小的罕见故障更容易破坏系统。
7. 尽可能松散耦合。 理想情况下，服务器相对于客户端异步运行。它们在时间上是松散耦合的。然后，很容易最大化整体服务器吞吐量，并处理请求的优先级和故障转移。不幸的是，这并没有被广泛实践，因为当今大多数应用程序框架的性质，这些框架并没有使异步对于普通程序员来说足够容易，并且因为异步不可靠的一件事是保证延迟，这对于良好的用户体验至关重要。这些框架是为了支持杀手级应用而派生出来的，这些应用都与用户界面有关。如果异步失败，那么至少要有一个模型，其中客户端和服务器之间没有硬链接（意味着IP链接），因为服务器上的负载和代码总是在变化，机器也会发生故障。因此，始终通过间接方式访问服务器。URL和重定向显然都服务于此目的，并且它们之间做得非常好。有些人会在DNS级别进行交换，另一些人会在重定向级别进行交换，但这两种方法都可以让人处理移动负载和代码，甚至在运行时也是如此。在任何一种情况下，都不需要共享密钥，更不用说共享代码，来使事情工作。例如，即使站点的代码被完全替换，语言被切换，操作系统被切换，浏览器仍然可以与站点一起工作。这有一个限制。HTTP和HTML是浏览器和服务器之间的共享密钥，因此也许规则应该是拥有极少数量的共享密钥，并使它们极其简单、灵活、宽容和通用。
8. KISS。保持（设计）简单和愚蠢。 复杂的系统往往会失败。它们很难调整。它们往往不能很好地扩展。它们需要更聪明的人来维持系统的正常运行。简而言之，它们是令人讨厌的东西。相反，简单的系统往往易于调整和调试，并且往往更少出错，更好地扩展，并且通常更易于操作。这不是新闻。正如我之前所论证的那样，电子表格、SQL和PHP之所以成功，正是因为它们简单而愚蠢——而且宽容。有趣的是，标准机构往往在应该冻结标准很久之后还在继续制定标准。他们忘记了这些教训，并添加了数百万个花哨的功能，如果被采用，无疑会导致系统失败。幸运的是，这种情况不会发生，因为到那时，已经有大量的已安装代码（甚至硬件）假设了更简单的规范，并且无法处理新的花哨功能。因此，没有人使用它们，我们都受到了保护。
将这些经验应用于XML
我们中的一些人在七八年前就学到了这些经验，并将它们应用于分布式计算。我们明确的目标是使用XML over HTTP通过消息在应用程序之间交换信息，以构建一个松散耦合、健壮、Web友好的分布式计算模型。然而，以我拙见，我们忽略或忘记了经验3、4和5。
经验3告诉我们，XML中值在已知的时间段内不太可能更改的元素（或者在该时间段内可以接受它们是陈旧的元素，例如书名）应该被标记来说明这一点。XML没有这样的模型。您可以使用HTTP协议以非常粗略的方式说明这一点，但是，例如，一本书可能大部分是不变的，尽管偶尔会有价格变化或新的评论，当然，拍卖品的价格可能会发生变化。
经验4表明，我们不应过度投资于使模式得到普遍理解。某些模式会在达到临界质量时胜出（如RSS 2.0所做的那样），而另一些模式则不会。有些模式将支持几种变体但成功的变体（如RSS也做过的那样，大多数阅读器都可以读取RSS .92、RSS 1.0、RSS 2.0和Atom）。它还表明，试图强制规定用于语义的通用URL不太可能奏效，因为一般来说，它们不会达到临界质量，因此人们不会知道它们——更不用说费心去使用它们了。简而言之，如果大量的人不使用某物，或者没有反馈机制来知道使用什么，那么它就不会被使用。
经验1和5告诉我们，XML应该易于理解，无需模式，并且应该让客户端智能地决定如何以及何时获取相关信息，特别是大型文件（如照片、视频和音乐），甚至只是相关的XML集（如帖子的评论、候选人的评论或餐厅的评分）。
嗯。这一切都蕴含着一些有趣的含义。
其中之一是语义网将面临许多挫折。它已经尝试了五年来说服世界使用它。它实际上有一个观点。XML应该具有自描述性，以便松散耦合可以工作。如果您需要在双方共享密钥，那么我会说系统不是松散耦合的，即使唯一的共享密钥是模式。更重要的是，XML本身在这方面有三个严重的弱点
1. 它不能很好地处理二进制数据。 没有理智的人会将大量的二进制数据编码到XML中。但是，没有理智的人首先会推送二进制数据。他们会让接收者使用现有的协议来流式传输二进制数据（或者可能是现在的BitTorrent）。
2. 它不处理链接。 世界不是一个可以冷冻干燥并放入文本中的巨大树。您必须将其分解为块。一个人的块是另一个人的块集。解决这个问题的方法是自描述链接，它可以选择性地向您显示链接的MIME类型和/或用途，例如 <Link purpose=”comments” type=”Text/Atom”/> 和/或服务器“认为”是块的自描述语法（见下文第3点）。
如果您检查XML，它通常由数据集甚至数据集的集合组成。问题在于，人们无法查看XML（记住，据说是自描述的）并知道哪些元素是集合的实例，哪些不是。例如，如果看到
<Person><Name>…</Name><email>…</email>
<email>…</email></Person>
人们不能安全地假设存在一组 <email> 元素。现在模式将描述这一点，但这既困难（XML模式语言非常复杂），更重要的是，需要共享密钥。理想情况下，这将是不需要的，并且一个工具，无需不断下载和分析每个XML文档的模式，就可以很容易地从实例中弄清楚这一点。
3. XML文档往往是单片的。 例如，给定一个采购订单，并且希望插入一个行项目或替换地址，很难知道如何操作，因为项目不包含ID或上次创建/更新的日期。相比之下，数据库世界将事物分解为行，每一行通常都有一个唯一的ID和一个创建日期，尽管最后一个日期因数据库而异。这让人们可以“分块”信息，同时仍然有能力组装它。默认情况下，在XML中，子元素的顺序很重要。然而，这会鼓励错误。它违反了让草率的人编写的规则。许多XML错误只是子元素顺序的简单差异。在大多数情况下（打印文档除外），这不应该也不应该重要。
充满希望的转机
最近，出现了一个超越这些限制的机会。RSS 2.0已成为Web上极其流行的格式。RSS 2.0和Atom（本质上是同构的）都支持一个基本模式，该模式为集合提供了一个模型。Atom的通用模型是一个 <feed> 容器，其中包含 <entry> 元素，每个 <entry> 可以包含它选择的任何命名空间范围的元素（因此是任何XML），必须包含少量必需元素（<id>、<updated> 和 <title>），并且可以包含Atom命名空间中的一些其他众所周知的元素，例如 <link>s。
更好的是，Atom明确表示顺序无关紧要。这立即为XML中缺少的集合提供了一个简单的模型。人们所要做的就是为集合创建一个 <feed>，并将集合中的每个项目放入一个 <entry> 中。由于所有 <entry> 元素都包含一个 <id>（这是一个GUID）和一个 <updated> 元素（这是上次更改的日期），因此很容易定义替换特定条目的语义，甚至确认您正在替换您认为的条目（例如，它们具有相同的 <id> 和相同的 <updated>）。由于它们有一个标题，因此很容易构建一个用户界面来显示它们的菜单。几乎所有Atom条目都有一个 <content> 或 <summary> 元素（或两者都有），它们以用户友好的方式总结条目的值，并增强自动用户界面。如果条目有相关的二进制信息（如图片或声音），它会包含 <link> 元素，这些元素具有描述目标MIME类型和大小的属性，从而使Atom feed的消费者可以智能地选择何时以及如何获取哪些媒体，并解决XML在这方面的不足。
Atom还支持其他类型的链接，例如评论，因此显然Atom条目可以包含指向相关feed的链接（例如，餐厅的评论或客户的投诉）或指向特定帖子的链接。这为我们提供了XML中缺少的网络和图模型。Atom包含一种基于HTTP的简单方法，用于在 <feed> 中INSERT、DELETE和REPLACE <entry>s。所有这些文档都有一个杀手级应用，因为浏览器已经可以查看RSS 2.0和Atom，并且有望很快本地支持Atom协议，这意味着读写功能。
atomEntry =
element atom:entry {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContent?
& atomContributor*
& atomId
& atomLink*
& atomPublished?
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& extensionElement*)
}
RSS 2.0已达到普遍理解的临界点。RSS中缺少缓存所需的时间-生命周期（TTL）指示器，但如前所述，HTTP为此提供了一个粗略的模型。简而言之，很有可能大量有用的信息将以RSS 2.0或Atom（或两者兼有，取决于请求者要求的类型）的形式在Web上传输。它解决了当今XML中的许多严重限制或不足。
这对数据库意味着什么？
所有这些对数据库都有深远的影响。今天的数据库基本上违反了我们从网络中学到的每一条经验。
1. 是否支持简单宽松的文本格式和协议？ 不支持。我们仍然处于CORBA世界。仍然需要自定义代码才能读取数据库。就好像浏览器需要驱动程序才能与每个站点（或至少是站点类型）对话一样。在这个时代，这毫无意义，而且正如我们刚刚看到的，现在Atom中有一个值得称道的候选协议，每个数据库都应该支持，并且Atom和RSS 2.0中都有一个值得称道的线格式。
2. 数据库是否使人们能够并行利用摩尔定律？ 这意味着数据库可以或多或少地线性扩展，以处理传入请求的量，甚至处理复杂性。答案是否定的。诸如ORDER BY、joins、子查询和许多其他操作使得几乎不可能将查询逻辑下推到任意数量的叶节点，并简单地对结果进行排序/合并/聚合。限制查询以避免这种情况的更简单方法是将所有谓词限制为可以针对单行一次计算的谓词，至少在效率和规模至上的情况下是这样。
3. 当可以接受陈旧时，数据库是否优化缓存？ 不优化。一般来说，数据库没有办法标记字段的TTL是什么，然后通常也没有办法在查询语言中描述可接受的陈旧程度。因此，跨越机器海洋的缓存，即另一种最佳的速度机制，几乎变得不可能。
4. 数据库是否允许使用自下而上的共识/临界点来演变一组项目的模式？ 显然不允许。它们通常对模式非常僵化。这被认为是一个特性。数据库是否允许用户“标记”数据？完全不容易，因为标记行的重点是每行中的外键可能指向任何表中的任何其他行，而关系数据库通常不允许这样做。
5. 数据库是否能很好地处理灵活的图（或树）？ 不，它们不能。长期以来，人们都知道遍历任意树对于数据库来说是一场噩梦。即使在今天，对于许多站点来说，这仍然是一个大问题。虽然您可以在数据库中建模任何规范链接，但几乎不可能建模指向特定集的特定链接。换句话说，我可以让WhoToGoTo字段成为指向People的外键，但不能指向People或Companies或Friends或Helpdesks，或者有时是单个值，有时是集合，有时是指向HTML页面的指针。今天的数据库对于图来说，就像IMPROV对于电子表格一样——也就是说，更加正式、严谨和不灵活。事实证明，电子表格是更健壮和有用的工具。
6. 数据库是否从Web中学习并使其查询简单而灵活？ 没有，只需询问数据库是否有人，如果他们有年龄，则年龄超过40岁；如果他们有城市，则住在纽约；如果他们有收入，则收入超过10万美元。这是一个噩梦，因为所有对NULL的测试。对于最基本的查询（即“关于”以下词语）没有简单有效的标准（例如，告诉我关于一切：朋友、人、员工、项目...）。然而，这正是最宽容、最灵活和最容易理解的查询类型。
这种情况正在改变。Oracle在以客户可能想要的各种方式向其数据库添加XML方面做得非常出色。在这样做时，它添加了许多这些功能。它的ROWID类型允许某些形式的灵活链接。但没有真正表明他们已经从网络中学到了什么。
数据库供应商是时候挺身而出了
分布式计算一直在学习和发展，以响应网络的经验教训。格式和协议正在兴起，以克服XML的局限性——即使XML反过来也是为了克服CORBA和DCOM的局限性而产生的。数据库供应商是时候挺身而出，开始支持原生的RSS 2.0/Atom协议和线格式了；一种询问非常通用查询的简单方法；一种以人类思考的方式对包含树和任意图的数据进行建模的方法；更流畅的模式，不需要复杂的连接来建模从产品到人到地点的任何主题的变体；以及内置的线性扩展，以便数据库销售人员可以问心无愧地告诉他们的客户，对于此类查询，您可以在吞吐量方面任意扩展，甚至在延迟方面也非常好，只要您将自己限制在以下类型的查询中即可。然后我们就会知道数据库供应商已经加入了21世纪。
ADAM BOSWORTH于2004年加入谷歌，担任工程副总裁。他从BEA Systems来到谷歌，在那里他担任首席架构师和高级副总裁，负责BEA框架部门的工程工作。在加入BEA之前，他与人共同创立了Crossgain，一家被BEA收购的软件开发公司。Bosworth被称为XML的先驱之一，曾在微软担任过多个高级管理职位，包括WebData组的总经理，该团队专注于定义和推动XML战略。在微软期间，他负责设计Microsoft Access PC数据库产品，并组建和领导了开发Internet Explorer 4.0 HTML引擎的团队。
最初发表于Queue第3卷，第8期—
在数字图书馆中评论本文
更多相关文章
Andrew McCallum - 信息提取
2001年，美国劳工部受命建立一个网站，帮助人们在美国各地的社区学院、大学和组织中寻找继续教育机会。该部门希望其网站支持对地点、日期、时间、先决条件、讲师、主题领域和课程描述进行布尔搜索。最终，它还对挖掘其新数据库以获取模式和教育趋势感兴趣。这是一个主要的数据集成项目，旨在每三个月自动从数万个独立机构收集详细的结构化信息。
Alon Halevy - 为何你的数据无法混合
当独立方为同一领域开发数据库模式时，它们几乎总是彼此完全不同。这些差异被称为语义异构性，这也出现在多个XML文档、Web服务和本体中——或者更广泛地说，只要存在多种结构化数据主体的方式。半结构化数据的存在加剧了语义异构性，因为半结构化模式从一开始就更加灵活。为了使多个数据系统相互协作，它们必须理解彼此的模式。
Natalya Noy - 从混乱中理出秩序
过去十年在线信息数量的“大爆炸”为人类和机器处理带来了便利，这可能没有什么争议。它促成的两个趋势（在许多其他趋势中）是：首先，已经转向比传统集中式关系数据库更灵活和流动的（半结构化）模型，这些数据库存储了以前的大部分电子数据；其次，今天可供人类处理的信息太多了，我们真的需要机器的帮助。
C. M. Sperberg-McQueen - XML <和半结构化数据>
词汇设计者可以要求XML数据完全规则，或者他们可以允许少量变化，或者大量变化。在极端情况下，XML词汇实际上可以说，除了所有格式良好的XML所要求的规则之外，没有任何规则。由于XML语法仅记录存在的内容，而不是可能存在的所有内容，因此稀疏数据不会使XML表示显得笨拙；XML存储系统通常旨在优雅地处理稀疏数据。
© 保留所有权利。