经典数据库系统为相对少量的数据提供清晰的答案。这些系统将其数据保存在一台或相对少量的计算机中。凭借严格定义的模式和事务一致性,从查询返回的结果清晰而准确。
新系统拥有海量的数据内容、变化率和查询率,需要大量的计算机来存储和处理。数据质量和含义是模糊的。模式(如果存在)很可能因数据而异。数据的来源可能值得怀疑,其时效性也可能各不相同。
今天的数据系统从许多来源汇集数据。互联网、B2B 和企业应用程序集成 (EAI) 将来自不同地点的数据组合在一起。没有计算机是孤岛。这种大量的互联互通和相互依赖性导致许多数据库原则的放宽。让我们考虑一下今天的答案与我们过去期望的答案有何不同。
经典 SQL 数据库的许多不同原则正因数据量过大而受到侵蚀
• 未锁定的数据。 经典 SQL 语义依赖于数据库中数据的锁定。解锁数据会改变经典数据库的语义。
• 不一致的模式。 不同的文档来自不同的来源。您需要处理可扩展性、不同的语义和未知的语义。
• 提取、转换和加载。 数据可能来自许多来源,您正尝试将其硬塞到类似于共性的东西中。
• 通过推断得出模式。 您没有想到的连接在哪里?通过不断检查数据,您可以推断出什么?
• 太多而无法做到准确。 当您完成计算时,答案可能已经更改。太多,太快——您需要近似。
虽然我们希望做到完美,但即使答案不完美,业务也需要答案。
• 有时,数据会带来挑战。 可能有大量数据;它可能来自许多不同的来源或不明确的来源;它可能会在一段时间内到达。
• 有时,处理会带来挑战。 您可能需要以丢失信息的方式转换、转换或解释数据(参见图 1)。您可能需要对数据进行推断和假设。
我们不能再假装生活在一个干净的世界里。SQL 及其数据定义语言 (DDL) 假定对数据有清晰明确的定义,但这只是我们在周围世界中看到的业务示例的一个子集。如果我们有有损答案是可以接受的——这通常是业务需要的。
巨大的规模对数据的一致性语义产生影响。事实证明,NoSQL(不仅是 SQL)类型中的大多数大型系统都无法支持跨其所有数据的事务。这关系到如何一起使用数据。在这里,我将研究来自远程系统的数据的一些问题。
事务让您感到孤独。数据库事务的目的是让您感觉在您工作时没有其他任何东西在更改数据。
作为一名事务极客,我花了数十年时间研究提供有保证的一致性形式的系统。这种一致性的一种特殊形式称为可串行化,或串行顺序的外观。各个事务不必按串行顺序执行,但必须至少存在一个与观察到的行为相对应的串行顺序。
图 2 中显示的每个事务似乎都在清晰明确的“现在”中执行。有些事情发生在过去;有些事情发生在未来;事务看到“现在”。“现在”的定义是可以在其中应用事务的边界。
SQL 数据库依赖于生活在“现在”中来提供其语义。尽管许多 SQL 系统提供宽松的一致性语义以提高并发性,但事务可串行化仍然是考虑通用 SQL 机制的最清晰方式。
消息和文档包含已发送到狂野、残酷世界中的未锁定数据。发送消息时,它们通常会跨越可以支持分布式事务的边界;因此,数据不受事务保护。相反,数据通常被赋予身份和版本。来自始发系统的数据可能会在消息发送后不久发生更改。解锁它允许更改。消息和文档始终来自过去。
同时性在远处不存在。知识以光速传播。当您在夜空中看到远处物体时,它可能已经发生了变化。同样,当您收到来自远程计算机的消息时,该系统中包含的数据可能已经更改。
事务和应用程序/业务边界定义了同时性。在单个系统(一台计算机或少量计算机)内部,您可以拥有一个事务数据库,其中包含受事务保护的应用程序操作。许多单个应用程序正在变得如此庞大,以至于将这些应用程序实现为单个事务域是不切实际的。因此,我们现在看到应用程序使用 NoSQL 风格的数据,其中应用程序数据的不同部分存在于不同的事务边界内。一些最近的可扩展系统提供了一个小的数据集合,您可以在其中获得事务一致性。在这些边界之外,提供了较宽松的一致性,并且应用程序负责特定于应用程序的一致性。这些包括 Google 的 Megastore1 和 Microsoft 的 SQL Azure。4
互联网上的所有数据都来自“过去”。当您看到它时,任何变化值的真实状态都可能不同。每个独立的数据库、系统或应用程序都将培育自己的数据,这些数据会随着时间的推移而变化。在松散耦合的系统中,每个系统内部都有一个“现在”,并且有一个“过去”通过消息到达。当您看到一些未锁定的消息或文档时,真相可能已经改变。
如果您依赖于一组数据的凝聚力,则必须由其源将其作为单个标识在单个原子事务中写入。这个有凝聚力的数据单元必须具有唯一的标识和版本。在当今大型、松散耦合的系统中,将会有许多这样的数据集。在每个数据集内部,时间性质可以是凝聚的。在它们之间,应用程序必须推理它们不同的历史记录。
在这个庞大且松散连接的世界中运行的每个应用程序都必须有自己主观的“现在”感,并且必须了解来自其他系统的信息不在同一个“现在”中。当您看到它时,事情可能已经发生了变化。至关重要的是,业务概念要接受这些真理。这与电话发明之前人们使用手写消息和信使来协调业务的情况没有什么不同。
根据需要,这种临时歧义(关于真相的不确定性)的解决方案必须以特定于应用程序的方式处理。不同的业务问题有不同的业务机制来应对不确定性。
我最喜欢的通知之一是:“通常在 24 小时内发货。” 这绝对没有告诉您任何关于保证的信息,但它非常有用——我总是根据这种定义不清的非保证在我的购物车中添加或删除商品。
在大型、松散耦合的分布式系统中,我们还必须认识到,不止一台计算机。这些计算机中的每一台都将有自己的时间域和自己的事务历史序列。我们必须构建我们的应用程序来应对这些多重历史的歧义。
当数据在文档中发布或在消息中发送时,通常会尝试对其进行描述,以便读者可以理解它。在非常庞大且松散连接的分布式世界中,这种数据模式的性质本质上是不同的。在这里,我将讨论在传达应该传达的内容方面的一些挑战。
当在分布式和异构系统中编写消息时,编写系统(理想情况下)会理解其语义。在编写时,存在上下文和意图。希望描述消息意图的模式显式或通过引用伴随内容。此模式的目标是促进理解消息的意图。
消息是不可变的。它们被编写、发送,并且可能会重试。如果消息重试在语义上与第一次尝试不同,则被认为是错误的。因此,在描述消息时,模式信息也应该是不可变的。
当编写消息或文档时,编写系统知道其含义。通常,文档会附加一些描述或模式,以方便读者弄清楚发送者的意思。此描述可以采用多种表示形式中的任何一种,包括 XML(及其许多模式变体)。XML 的一个好处是,基本上所有系统都可以很好地解析它,以至于会混淆消息的语义而不是语法。这是一个巨大的进步。
除非消息或文档的读者是专门为此编程的,否则很可能会出现混淆。消息的含义、对其字段的解释等等都将受到近似值和清晰度损失的影响。不同的公司、不同的国家,甚至一个国家内的不同地区对数据都有不同的理解。有时,与同一公司内部的不同部门沟通比与一些外部合作伙伴沟通更困难。(当然,总是有一些上下文问题是出了名的难以捕捉的。模式作者可能会尽最大努力表达数据的含义。但是,当现代读者试图破译中世纪作品时,会存在一些文化假设,这些文化假设可能与青少年父母面临的文化假设一样难以理解。消息和文档模式中也普遍存在类似的挑战。)
当两个组织尝试沟通时,总会有一只经济上的狗和一条经济上的尾巴。狗摇尾巴,尾巴动。在消息传递和/或文档定义中,是经济上的狗定义了语义。如果存在任何歧义,则责任仍然落在经济上的尾巴上来解决它。
例如,沃尔玛是零售业的主导力量,并对希望通过其销售的制造商规定了很多事情。除了包装和标签标准外,沃尔玛还对与制造商的沟通施加消息传递标准。沃尔玛规定了含义,制造商则适应。
模式定义越来越多地捕获在名称/值对的“名称”中。这可以从 SQL DDL(旨在对数据含义进行严格且规范的声明)到 XML(更倾向于作为作者对消息或文档中写入内容的描述)的转变中看出。名称/值对(及其在 XML、JSON 等中的分层表亲)正在成为数据交换的标准。
我们正在从模式退化到名称/值对。从严格和正式类型化的转变正在导致正确性的丧失。本来会被更严格的描述捕获的错误现在可以挤过去了。
另一方面,我们正在从严格定义的规范模式演变为更具适应性、灵活性和可扩展性的名称/值对。在非常大型、松散耦合的系统中,适应性和灵活性似乎比清晰性和明确性提供更多价值。
可扩展性是添加模式中未指定的内容。根据定义,它是读者没有预期但发送者无论如何都想添加的数据。这很像在未设计用于此类添加的纸质表格的页边空白处涂写附加说明。有时阅读表格的人会注意到这些附加说明,但有时不会。
一个人穿着的风格通常旨在向陌生人提供信息。当人们开始从居住在小村庄(每个人都认识您并知道对您的期望)过渡到居住在大城市(您遇到的大多数人都是陌生人)时,通过以特定的方式穿着来向他人发出一些信息变得很重要。
人们动态地适应和发展他们的着装,以识别他们的刻板印象和社区。一些群体迅速改变以保持精英主义(例如,垃圾摇滚);另一些群体则缓慢改变以鼓励顺从(例如,银行家)。
动态和松散类型允许适应性。无模式互操作性不像严格定义的模式那样清晰和正确。它为混淆提供了更多机会。
在解释消息或文档时,您必须寻找模式并推断数据的角色。当人类检查陌生人的刻板印象和风格时,这很有效。它允许数据共享的灵活性(包括犯错误的成本)。
确定和肯定地了解一个人(或模式)具有优势,但扩展到无限数量的朋友(或模式)是不可能的。新兴的自适应数据模式就像人们的刻板印象。虽然您可以快速学习很多东西(但并非完美),但它可以扩展到非常大量的交互。
在非常大型且松散耦合的系统中,我们看到的是描述性模式,而非规范性模式
• 描述性模式。 在编写数据时,作者描述了预期内容。
• 规范性模式。 数据被强制转换为所有作者一致共享的固定格式。
系统越大且越断开连接,维护规范性模式就越不切实际。随着时间的推移,对一致性的尝试变成了一种脆弱性,会崩溃。自然选择将超大型系统从一致性和规范性中驱离。
在 20 世纪初,住在铁路上的流浪汉经常吃“杂烩汤”。5 社区成员会贡献任何可用的食材,并将所有东西都扔进一个公共锅中。根据具体情况,可能会有许多不同的肉类、鱼类、蔬菜和其他可食用物品都混合在同一个炖菜中。剩菜将构成明天炖菜的基础。虽然这道菜可能很美味,但很难精确定义其内容。
许多大型系统从大量来源提取数据。这些不同的数据被处理、压缩、硬塞和捣成糊状——有点像杂烩汤。通过组合数据并推理其与其他数据的关系,涌现出了令人惊讶的业务,例如谷歌和亚马逊。本节将研究实现这一目标的一些机制以及过程中需要的折衷方案。
许多数据系统执行提取、转换和加载 ETL:从一个或多个来源收集数据,通过转换将其转换为新形式,然后将其加载到数据存储中以进行进一步操作。这是一个有价值的过程,其用途和规模都在增长。数据的转换通常是有损操作,这意味着转换后的信息比转换前少。您无法获取转换后的数据并返回到原始信息。这很像用一些牛肉块制作汉堡包——您无法回到原始形式(参见图 3)。
为了避免您认为这是批评,我想指出我非常喜欢汉堡包。而且,我非常喜欢这些 ETL 操作产生的大型数据集,包括谷歌和必应的搜索索引,以及亚马逊的产品目录。虽然结果不能支持返回源数据的向后处理,但由此产生的炖菜确实很美味。
亚马逊、谷歌购物和必应购物等购物网站通过合作伙伴的数据馈送和抓取网络相结合的方式,从数百万个来源收集数据。这些数据很少采用标准格式,即使采用标准格式,语义也总是存在挑战。(同样的讨论也适用于为互联网搜索创建搜索信息。)
通常,第一步涉及清理。如何统一数据,以便可以对其进行比较和对比?例如
• 谁是制造商? HP、惠普、Hewlett/Packard、康柏、Digital、DEC、H-P?
• 颜色是什么? 绿色、翠绿色、芦笋色、黄绿色、橄榄色、梨色、三叶草色?
映射到单个值增加了将数据视为等效的能力,但您可能会丢失知识。
有许多竞争和统一的机制可以为一种产品类型分配唯一的编号——例如,GTIN(全球贸易项目代码)、UPC(通用产品代码)和 EAN(欧洲商品编号)。亚马逊内部使用其 ASIN(亚马逊标准识别号),其中包括以图书为中心的标准 ISBN(国际标准书号)。
作为标准化身份挑战的一个例子,每本书的每个版本和变体(再版除外)都会分配不同的 ISBN。这意味着每本书的平装本和精装本都有单独的身份。关于文学价值的评论和评论需要跨身份单独连接。同样,有些产品即使颜色不同,也具有相同的 UPC。由于某种原因,鞋子没有标准识别号,而是通过制造商和品牌名称来识别(并且一些制造商回收品牌名称)。
基于这些脆弱的身份,产品目录现在必须尝试辨别哪些商家的产品与其他产品相匹配。我们能否确定行业标准标识?我们能否准确地将商家 A 的这款产品与商家 B 的同一产品相关联,以便我们可以为客户提供比较?
一旦来自一组商家的多个产品被识别为相同并映射到唯一身份,就该创建统一的产品描述了。来自多个商家(有时是制造商)的最佳信息经过处理以创建目录条目。根据身份,您希望获得尽可能好的产品描述。
另一种知识形式是通过模式和推断收集的。通过研究数据的内容,有时可以推断出两个看似不同的身份实际上是相同的。例如,当查看来自不同商家的鞋子目录时,就会发生这种情况。缺乏像鞋子的 UPC 这样的行业范围内的标识符意味着它们特别容易错误地将两个鞋子描述解释为独立的商品。
推理引擎查看身份之间的关系(以及身份的属性),以识别出两个表面上不同的商品是相同的。一旦您意识到两个身份是相同的,就会通过将两个身份合并为一个来识别新的关系。推理引擎不断地将新信息附加到从 Web 和合作伙伴公司收集的数据中。
推理引擎收集的识别非常宝贵。一些重要的应用领域包括
• 欺诈分析。 识别信用卡使用的欺诈模式对于在线信用卡使用至关重要。正是由于这些欺诈检测机制,在线支付才在经济上可行。
• 国土安全。 在追踪可疑人员的惊人模式方面,有巨大的吸引力。最近,在匿名化身份方面也出现了增长,这种模式在不泄露身份和侵犯隐私的情况下共享关系。
• 市场目录中的商品匹配。 这两个 SKU 是待售的同一产品吗?
不可避免地,对源数据的这种“增强”会导致新的见解,并增加与源数据的距离。
识别数据的来源变得越来越困难。这个结果来自哪里?谁对数据的正确性负责?当来自多个来源的数据与其他派生来源的数据混合在一起时,来源是什么?当法律变更意味着您的某些输入数据不应再使用时,该怎么办?许可权的丧失和/或剥离您公司的一部分可能意味着输入数据不再供您使用。如果该输入数据已贡献于您知识产权的杂烩汤,那么您就遇到了问题。(在抱怨来源的文章中使用维基百科作为其某些参考文献,这有点讽刺意味。嗯...)
在考虑正在向 NoSQL 模型靠拢的大型可扩展应用程序时,我们必须考虑到不可避免地伴随它们的派生数据的语义。应用程序可能需要聚合数据的简化和提炼视图。这种视图不可避免地是一个有损棱镜,它着眼于知识的子集,但只有接受损失的必然性,我们才能寻找从由此产生的美味炖菜中获得业务价值的方法。
沃纳·海森堡6 表明,当事物变小时,您无法精确地了解一切。好吧,事实证明,当事物变大时,我们也可能会感到困惑。
Web 搜索结果非常具有挑战性。Web 爬虫,嗯,是爬虫。由于请求的歧义和 Web 的庞大规模,确保搜索结果与发出请求的人相关非常困难。受众的人口统计数据会影响所需的结果。例如,青少年经常想要与他们的父母不同的结果。请求者的位置、兴趣和最近的搜索会极大地影响预期的答案。
对大量人群进行的任何人口普查都非常难以实现。当您不能在同一时刻到达每家每户时,您无法准确地统计人数。人们会搬家;人们会撒谎;人们与女友同居,但不会告诉父母。您应该按地址、社会安全号码、姓名还是其他方式计数?如果在您统计完某人后他或她去世了怎么办?如果在家庭房屋被统计后但在人口普查完成之前有人出生了怎么办?
在 2000 年美国总统大选中,结果最终取决于佛罗里达州。佛罗里达州的选票几乎持平,每次重新计票都会产生不同的答案。大部分歧义来自自动投票机和选票残片(如图 4 所示)的存在,这有时使得难以(和/或主观地)解释选民的意图。
无论从哪个角度衡量,佛罗里达州的选票都非常接近,第一个结果显示差异约为 0.01%。在任何大型系统中,在需要精度之前,不准确性并不重要。如果获胜者领先 10%,则无需重新计票。
规模很大很难!时间、意义、相互理解、依赖性、过时性和推导都成为挑战。海森堡指出,在小规模下,不确定性是生活的事实。在大规模计算中,不确定性也是生活的事实。
NoSQL 系统正在兴起,因为数据的世界正在发生变化。数据的大小和异构性意味着旧的保证根本无法满足。幸运的是,我们正在学习如何在旧的和经典的数据库之外的方式来满足业务需求。
在 2005 年 CIDR(创新数据系统研究会议)上发表的一篇论文中,我观察到锁定(并且在数据库内部)的数据与未锁定的数据在本质上是不同的。2 未锁定的数据以具有身份和版本控制的集群形式出现。当数据包含在数据库内部时,它可以被规范化并接受 DDL 模式转换。当数据未锁定时,它必须是不可变的(或具有不可变的版本)。
数据库规范化旨在帮助避免更新异常。在大型系统中,您不更新数据,而是添加新数据或创建新版本。3 大型系统中数据的处理方式在本质上是不同的。
数据库行业从 1970 年代开始的数据理论的开创性工作中获益匪浅。这项工作改变了世界,并且仍然非常相关,但现在很明显,它只捕获了问题的一部分。
我们需要一种新的数据理论和分类法,其中必须包括
• 身份和版本。 未锁定的数据带有身份和可选版本。
• 推导。 哪些版本的哪些对象为此知识做出了贡献?它们的模式是如何解释的?对源的更改将像在 Excel 中一样驱动重新计算。如果法律原因意味着源数据可能无法使用,您应该忘记使用从中派生的知识。
• 推导的有损性。 我们能否发明一种边界来描述派生数据引入的不准确性?这是一个多维度的不准确性吗?我们能否区分损失与纯粹的大小引起的不准确性?
• 按模式归因。 就像杂烩汤一样,模式可以从从模式派生的属性中派生出来(依此类推)。我们如何限制来自我们不应合法或合乎道德地拥有的知识的污点?
• 经典锁定的数据库数据。 让我们不要忘记,任何新的数据理论和分类法都应将经典数据库作为更大难题的一部分。
现在是从事数据工作的好时机。许多新的和令人兴奋的事情正在发生!
问
1. Baker, J. Bond, C., Corbett, J. C., Furman, JJ, Khorlin, A., Larson, J., Léon, J. M., Li, Y., Lloyd, A., Yushprakh, V. Megastore:为交互式服务提供可扩展、高度可用的存储。《创新数据系统研究会议论文集》(加利福尼亚州阿西洛马,2011 年); www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf。
2. Helland, P. 外部数据与内部数据。CIDR 2005; www.cidrdb.org/cidr2005/papers/P12.pdf。
3. Helland, P. 规范化是给胆小鬼用的。《创新数据系统研究会议》(2009 年); http://blogs.msdn.com/b/pathelland/archive/2007/07/23/normalization-is-for-sissies.aspx。
4. Microsoft 开发人员网络。SQL Azure (2011); http://msdn.microsoft.com/en-us/windowsazure/sqlazure/default.aspx。
5. 维基百科。杂烩汤; http://en.wikipedia.org/wiki/Mulligan_stew_(food)。
6. 维基百科。沃纳·海森堡; http://en.wikipedia.org/wiki/Werner_Heisenberg。
喜欢它,讨厌它?请告诉我们
Pat Helland 自 1978 年以来一直从事分布式系统、事务处理、数据库和类似领域的工作。在 1980 年代的大部分时间里,他曾担任 Tandem Computers 的 TMF(事务监控设施)的首席架构师,该设施为 NonStop 系统提供分布式事务。除了在亚马逊工作两年外,Helland 自 1994 年以来一直在微软公司工作,在那里他曾担任 Microsoft Transaction Server 和 SQL Service Broker 的架构师。他目前正在从事 Cosmos 的工作,Cosmos 是一种分布式计算和存储系统,为 Bing 提供后端支持。
© 2011 1542-7730/11/0500 $10.00
最初发表于 Queue 第 9 卷,第 5 期——
在 数字图书馆 中评论本文
Qian Li, Peter Kraft - 事务和无服务器是天作之合
数据库支持的应用程序是无服务器计算令人兴奋的新领域。通过紧密集成应用程序执行和数据管理,事务性无服务器平台实现了许多新功能,这些功能在现有无服务器平台或基于服务器的部署中是不可能实现的。
Pat Helland - 任何其他名称的身份
新兴的系统和协议既收紧又放松了我们对身份的概念,这很好!它们使完成工作变得更容易。REST、IoT、大数据和机器学习都围绕着故意保持灵活且有时模糊的身份概念。身份概念是我们分布式系统基本机制的基础,包括互换性、幂等性和不变性。
Raymond Blum, Betsy Beyer - 实现数字永恒
当今的信息时代正在为世界所依赖的数据创造新的用途和新的管理方式。世界正在从熟悉的物理人工制品转向更接近信息本质的新的表示方式。我们需要流程来确保知识的完整性和可访问性,以保证历史将被人们所知晓且真实。
Graham Cormode - 数据概要
你是否曾感到被源源不断的信息流淹没?似乎大量的新邮件和短信要求持续的关注,还有需要接听的电话、需要阅读的文章以及需要应门的敲门声。将这些信息碎片整合起来以跟踪重要内容可能是一个真正的挑战。为了应对这一挑战,流数据处理模型的使用日益普及。其目的不再是捕获、存储和索引每一个细微的事件,而是快速处理每一次观察,以便创建当前状态的概要。