PDF身份的多种称谓
错综复杂的交织系统的复杂喧嚣
Pat Helland，Salesforce.com
“名字有什么关系呢？我们所谓的玫瑰
换个名字还是一样芬芳。”
——威廉·莎士比亚（《罗密欧与朱丽叶》）
随着分布式系统在规模和异构性方面不断扩展，它们越来越多地通过标识符连接起来。这些标识符可以称为 ID、名称、键、数字、URL、文件名、引用、UPC（通用产品代码）以及许多其他术语。通常，这些术语指的是不可变的事物。有时，它们指的是随时间变化的东西。标识符甚至用于表示跨越互不信任的系统工作的计算的性质。
关于标识符，最有趣的事情是，虽然它们随着时间的推移标识相同的“事物”，但所引用的事物可能会在其含义上发生变化。产品描述、评论和库存余额都会改变，而产品 ID 则不会。预订、订单和预定都有不变的标识符，而它们标识的东西可能会随着时间的推移而微妙地变化。
身份和标识符提供了不可变的链接。这种链接的两侧都可能发生变化，但它们提供了业务运营所需的语义一致性。无论你如何称呼它，身份都是使事物粘合在一起并促进协作工作的粘合剂。
本文又是关于错综复杂的交织系统的复杂喧嚣的又一次思想实验和思考。
对身份的需求
长期以来，我们都在单个集中式数据库的幕后工作。如果你想与其他计算机通信，那是一个“应用程序问题”，而不是系统范围内的问题。数据作为关系数据库单元格中的值而存在。一切都可以用简单的抽象来解释，生活很美好！
然后，我们开始拆分集中式系统以实现规模和可管理性。我们还试图让独立开发的不同的系统协同工作。这在相互理解4和确保可预测的结果方面带来了许多挑战，特别是对于原子事务而言。
随着时间的推移，许多使用模式涌现出来，以应对跨同构和异构边界工作的挑战。所有这些模式都依赖于用身份的概念来连接事物。所涉及的身份通常在很长一段时间内保持稳定和完整。
外部数据与内部数据
2005 年，我写了一篇论文《外部数据与内部数据》7，探讨了将数据不保存在 SQL 数据库中，而是保存在消息、文件、文档和其他表示形式中的含义。事实证明，未保存在数据库中的信息以不可变的消息、文件、值（à la 键/值）或其他表示形式出现。这些表示形式通常是半结构化的，但它们总是具有某种形式的标识符。
规模、长期运行和异构
系统也通过身份连接在一起。当为规模设计同构解决方案时，分片、副本和缓存都基于某种形式的身份。解决方案随着时间的推移响应刺激，使用一个或多个身份表示来确定要重启或继续的工作。连接独立创建的、具有自身私有和互不信任的实现的系统总是使用共享身份和标识符，而这些身份和标识符是它们合作的关键。
搜索和学习
计算领域的许多其他部分都依赖于身份。搜索分配文档 ID，然后组织与其关联的搜索词索引。机器学习将属性与身份绑定。在许多情况下，一组属性变得有趣，然后被分配一个身份。系统反复工作，将更多属性与它们关联起来。当这些属性在身份之间形成模式时，机器就学到了一些东西。
身份：新的支点
计算模式显示了我们对身份的依赖性。我们过去只关注关系数据库，但现在我们看到通过身份互连的计算和存储片段。通过身份连接的数据和计算可以旋转和移动。
名字有什么关系呢？
本文指的是身份。身份有惊人数量的同义词。真正重要的是身份在其使用范围的空间和时间范围内是唯一的。名称、键、指针、文件名、句柄、支票号码、UPC、UUID（通用唯一标识符）、ASIN（亚马逊标准识别号）、零件号、型号、SKU（库存单位）等，在全球范围内或在其使用范围内都是唯一的。正是每个标识符在其使用范围内的不可变性，使其能够成为将计算结合在一起的间隙粘合剂。
使用身份来扩展规模
身份可用于同构和异构扩展规模。本节考察一个非常复杂的示例。电子商务不仅使用购物车和可扩展的产品目录，而且还可以通过组合来自其众多商家和制造商的一些最佳信息来派生产品描述。此信息可以通过商家 SKU 或制造商零件号来标识。此外，所提供商品的库存、定价和状况都因商家而异，并且以非标准方式标识。许多不同的连接和断开连接的身份贯穿复杂的多公司电子商务。
会话状态和购物车
每个购物者都有自己的购物车。这可以与在线帐户或 Web 会话关联。购物者在单个 Web 会话期间不会获得多个购物车。此外，没有人期望或希望购物车与其他购物车共享状态或一致的更新。
购物车的唯一性由购物车 ID 提供。系统中存在一些逻辑，用于将会话（通过用户登录或在线会话状态）绑定到购物车 ID。基于该唯一 ID，可以找到购物车内容。
可扩展的键值存储
可扩展解决方案中的一种常见模式是可扩展的键值存储。以电子商务零售产品目录为例。零售商有一堆产品，每个产品都有一个产品标识符。产品描述缓存按产品 ID 分片。这支持可扩展的描述数据。复制的分片支持可扩展的读取流量。要添加更多产品描述，请添加更多分片。要支持更多读取流量，请添加更多分片副本。参见图 1 中按产品 ID 索引的产品描述的可扩展目录。产品目录不需要原子地更新不同的产品。事实上，产品目录无法原子地更新单个产品的所有缓存条目！
识别缓存的抖动版本
产品描述的更新会随着时间的推移将新版本分发到副本。因此，读取是抖动的，并且稍后的读取可能会显示较早的值。产品 ID 是使这项工作成为可能的不可变粘合剂。即使缓存的读取返回旧的缓存值，它也与所需的产品 ID 相关联，并满足业务需求。在产品目录和许多其他用途中，旧值是可以接受的。
匹配和派生描述
在大多数大型电子商务网站中，产品描述来自制造商、商家和其他来源提交的数据。为了关联这些描述，有必要规范化输入，匹配来自不同来源的描述，然后将它们组合起来以获得可用的最佳信息。输入带有型号、UPC 和 SKU 等标识符，这些标识符由通过大型电子商务网站销售的第三方商家定义。在匹配之前没有单一的身份。
规范化清理各种输入，以尝试获得一致的表示形式。如果颜色是凯利绿、森林绿、橄榄绿或黄绿色，是否应该将其规范化为绿色？规范化使匹配各种输入彼此更容易。它也失去了一些原始输入的保真度。
匹配尝试找到相同的东西。商家 A 出售的这款产品与商家 B 出售的另一款产品相同吗？每个商家都有自己的 SKU 作为个人唯一标识符。它们如何关联？
滑溜和滑动的标识符
另一个挑战是商家的 SKU 由商家分配和绑定。没有什么可以阻止他们将 SKU 12345 从一双红宝石拖鞋更改为一罐巧克力酱。当您的合作伙伴企业以非不可变的方式使用标识符时，您需要保持警惕。我听过一些小商家的故事，他们在地下室里放了 40 个装满东西的箱子。SKU #23 的内容对应于当时放在箱子 #23 中的任何产品。
UPC：相同但可能不同！
考虑一下通过大型零售商平台整合许多卖家商品的的大型零售商。如果商家在其商品描述中包含 UPC，则会很有帮助。UPC 使匹配来自不同商家的商品变得容易得多。这些 12 位标识符中的每一个都用于特定的制造产品。UPC 与 EAN-13（欧洲商品编号 13）代码一起使用，后者是一种条形码，主要用于零售环境中的扫描仪。
UPC大多是正确的。对于制造商和零售商而言，实现具有相同 UPC 的产品的一致性和等效性都很困难。并非所有商品都有 UPC。例如，手工制作的商品可能没有 UPC。多年来，鞋子因没有 UPC 而臭名昭著。
书籍：ISBN、平装本、二手书和电子书
书籍呢？ISBN（国际标准书号）是一个 13 位（以前为 10 位）数字，唯一标识一本书的特定版本和格式。
评论呢？大多数评论是关于书籍的内容，而不是平装本的装订质量。您是否希望电子书、平装本和精装本版本共享评论？通常，这是通过另一个用于表示所有不同版本和格式的唯一标识符来处理的。同样，当颜色和唯一标识符不同时，许多时候相同的在线产品共享评论。
错综复杂的网络：产品、SKU、报价、库存和可运性
在线零售是唯一 ID 的海洋，所有 ID 都贯穿不同的系统、概念和合作公司。商家将他们的视角描述为待售商品的 SKU。从电子商务网站的角度将这些商品匹配和关联到产品中，是数据科学和机器学习领域的一项重大工作。完成后，相关性将保持，以方便跨商家和电子商务网站工作。当然，商家可以自由地在明天用相同的 SKU 标记完全不同的产品；电子商务网站必须适应。
产品的标识符将引用产品目录。产品目录的内容将不断发展，并被缓存以实现高效的可扩展读取。当访问缓存时，它可能会与缓存的更新竞争，并且稍后的读取可能会返回较早版本的产品描述。这无关紧要，因为任何版本都可以。产品目录不需要事务一致性。
接下来，将展示来自商家的购买报价。您想要全新产品还是二手产品？状况如何？卖家的信誉如何？这些报价与产品、购物车、特定报价的库存、价格、运输承诺以及运输方式的详细信息相关联。当然，这需要与付款联系起来。
内部和外部系统之间的每个关系都使用各种相关的身份连接在一起。图 2 显示了这些交互的一个非常小的子集，以及标识符如何将它们连接在一起。哦，是的，电子商务零售商希望商家在下订单时没有回收 SKU。将产品描述附加到 SKU 通常可以避免混淆。
使用身份进行搜索
让我们考虑一下我们在 Yahoo!、Google 和 Bing 中看到过的网络搜索。毫不奇怪，搜索是通过为 Web 中的每个文档分配唯一 ID 来完成的。
文档 ID、URL 和搜索词
当这些庞大的网络爬虫遍历它们找到的 URL 以定位文档时，它们会记住每个文档的 URL。这些 URL 构成唯一 ID。通常将 URL 绑定到另一个更短的唯一文档 ID。
当抓取文档时，会提取单词序列以进行索引。这些单词序列（称为 N-gram）对应于输入到 Web 搜索应用程序中的搜索词。
N-gram 被分片到大量分区中。当多个搜索词进入搜索时，可能会保存这些词的分片会被查询。这将从许多分片返回文档 ID 集。通过比较结果，查找跨搜索词的公共文档 ID，可以返回生成的文档 ID 集合。
虽然这被大大地过度简化了，但要点是搜索完全是关于身份的。
搜索对象关系应用程序
对象关系系统通常在底层关系系统之上分层应用程序对象。一些对象关系系统提供搜索功能，这些功能可以根据对象的内容及其中的 N-gram 查找对象的身份。这种机制依赖于搜索系统捕获的对象身份，并与对象相关联。虽然这些身份可能未被底层 SQL 数据库显式理解，但它们被对象关系系统和分层在其之上的搜索引擎所理解。
搜索意味着查找身份
今天的搜索通常意味着一个查找文档、对象或其他事物的身份的系统。正是从这些事物中提取的 N-gram 与身份的相关性提供了搜索结果。哪些文档身份与搜索提交的 N-gram 集最匹配？
当然，排序后的 N-gram 与底层事物并非强一致性。可能存在具有身份但尚未编入索引的事物。有时，存在包含不再存在的事物的身份的索引。虽然事物和索引可能会滑动，但身份通常保持不变。
使用身份进行学习
数据科学基于身份、对象和属性。它已被用于学习令人惊讶的新事物。身份是其工作的关键。
数据科学和观察
数据科学围绕身份展开。身份具有属性。正是对这些身份和属性的操作以及与其他共享这些属性的身份的比较，导致了新的和更深入的理解。
身份、对象和属性
当进行观察时，它们被存储为对象并被赋予身份。这些对象具有属性。分析对象可能会导致向其添加额外的属性。对大量对象集合的属性进行持续的模式匹配可以导致新的属性被附加到对象的侧面。
有时，查看对象及其属性的模式会导致新的对象显示现有对象之间的连接。这将为新对象带来新的身份。因此，属性模式本身就变成了一种身份，这可能会导致新的属性。
身份上的属性——冲洗并重复
正是不断循环查看对象及其身份上的大量属性，才导致了更多的属性。这些新属性要么附加到现有对象，要么用于生成具有自身独立身份的新对象。
大数据是大量的身份
诸如 MapReduce2、Apache Hadoop (https://hadoop.apache.ac.cn) 和 Apache Spark (https://spark.apache.ac.cn) 等大数据系统采用不可变输入，并应用函数式转换来生成不可变输出。由于输入和输出的不可变性，因此在工作片段失败并重新启动时，很容易推理容错性。
这些大数据系统中的每一个都利用数据项的身份来连接分布在多台服务器上的工作和存储。
MapReduce 和 Apache Hadoop
这些大数据系统将它们处理的数据集视为一堆键/值对。考虑 MapReduce 和 Hadoop
• MapReduce 的 map 函数接受一系列键/值对，并生成一组输出键/值对。这些输出对可能与 map 函数输入相同或不同。
• 为每个唯一键调用一次 reduce 函数，并且可以迭代与该键关联的值。单个键可能存在多个值。
使用键进行查询、连接等
这些大数据环境中的查询和连接利用键/值对中的键。这些键通过 map 函数在分片中排序。查询和连接由 reduce 函数处理，该函数处理具有相同键（或身份）的所有键/值对。
由于 map 函数可以将输入键/值排列成另一个形状的键/值，因此 MapReduce 和 Hadoop 可以在数据中的任意字段上进行查询、排序和连接。将连接字段放入键并进行排序，可以实现巨大的功能灵活性。
大数据意味着处理大量的键
大数据系统需要处理大量的键。它们可以以可扩展的方式分布在非常大的服务器集群中，以实现大规模扩展。键提供的身份将所有内容联系在一起。
“身份互联网”
IoT，即物联网，是新的趋势，其中来自不同设备的大量事件以高速率处理。
物联网：识别事物
在 IoT 中，极大量的设备（可能勉强算作计算机）生成大量事件以进行处理。这些设备中的每一个都将具有某种形式的标识符。当它生成事件时，这些事件中的每一个都将具有更详细的标识符，该标识符通常指定其来源设备。
这些事件中的每一个都将反过来具有许多特定于设备的属性。源自您的冰箱的事件将具有与源自您的汽车变速器或大型体育场安全摄像头的事件不同的属性。
查询、连接和连接事物
与在大数据中看到的情况类似，这些 IoT 事件中的每一个都具有身份和许多属性。这些事件可以根据其属性进行查询、连接和连接。您可以通过从单个事件或跨多个事件的连接中提取属性来创建新事件。
对身份的追求
当今一些最具挑战性的问题来自对身份的追求。产品匹配、数据科学、欺诈检测、国土安全等等都在努力弄清楚何时一个事物与另一个事物相同，以便可以分配身份。
产品匹配是查找身份
正如已经讨论过的，为完全不同的商家出售的商品提供一个集成的市场是一项巨大的挑战。这项挑战的核心是将来自不同商家、具有不同描述的不同 SKU 进行匹配，以找到相同的产品身份。
UPC 或 ISBN 代码实际上确实匹配，这通常使这项工作更容易。这使得产品匹配系统可以更轻松地比较属性以验证身份。产品匹配并非总是能从共享的唯一标识符中获得提升，并且问题变成了数据科学的任务。
数据科学是查找身份
在数据科学中，有许多对象，每个对象都有许多属性。每个对象都有一个唯一的身份。
• 附加新属性：通过比较许多对象及其属性，数据科学算法将新属性与现有对象关联起来。
• 合并对象身份：通过检查绑定到对象集的属性，数据科学算法可以意识到两个对象是一个对象。反过来，这统一了它们的属性。
欺诈检测是查找身份
发行信用卡的银行在欺诈检测方面投入巨资，接受信用卡的零售商和其他机构也是如此。接受信用卡的大型公司有强烈的动机来检测欺诈行为，因为如果它们的欺诈率明显降低，它们的银行将向它们收取较低的费用。欺诈检测是一项大生意。
欺诈检测通过将交易视为具有关联属性的对象来工作。此外，信用卡持卡人是具有关联属性的对象。将其他信用卡的欺诈活动与此卡进行模式匹配可以发出早期预警。如果没有这种匹配来查找新身份，电子商务将非常具有挑战性，因为会有大量的欺诈行为会通过。
国土安全是查找身份
身份和匹配的另一个例子来自查看旅行模式、地点、付款类型等等。对许多旅行者的分析导致表面上不同的人表现出相似的行为并不罕见。通过意识到他们具有相同的身份，可以将关于不同人员的已知详细信息合并，以更好地了解他们可能构成的风险。
激光般的清晰视觉和模糊的细节
这种基于共同属性合并身份是数据科学中许多新兴用例的基础。一种观点是，属性集定义了由合并产生的身份。属性是否必须在其所有完整的光辉中匹配？是什么使其可以接受存在差异？我们是否希望在属性匹配中具有激光般的精确度，还是可以稍微眯起眼睛并模糊一些细节以允许更多匹配？
越来越多的原始数据（例如，带有产品信息的商家Feed）被保留并链接到规范化、匹配和清理的数据。当您努力与其他输入保持共性时，这些操作本质上是有损的。考虑对齐和清理的通用视图，并将其与各个原始Feed进行比较，可以提供额外的见解。
使用身份进行活动
活动是跨时间和跨计算机运行的长期工作，并且可能跨越信任边界、部门和公司运行。活动通常通过具有活动标识符和每个步骤的单独标识符来处理。
长期运行的工作流和标识符
长期运行的工作流随消息跨时间运行，并且通常等待外部操作完成。当外部事件启动时，当事件完成时，会以某种方式接收到事件的标识符。为了处理外部计算机，标识符通常与传出和传入消息绑定。
跨越信任边界的标识符
有时，活动会跨越信任边界。在 B2B 解决方案中跨公司发送消息会引发信任问题——或许跨部门甚至从 Linux 盒子到 Windows 盒子发送消息也是如此。这些解决方案中的每一个都带来了挑战。在这些情况下，工作总是通过某种形式的身份连接在一起。该身份必须具有涵盖所有互不信任的参与者的空间范围，以及涵盖工作持续时间的时间范围。
一个系统为其标识符提供别名的情况并不少见。传出和传入的消息在两个身份系统之间进行转换。
银行支票号码和幂等性
长期运行工作的标识符的一个示例是您银行打印支票上的支票号码。当您向电力公司或杂货店开具纸质支票时，支票具有唯一标识符。支票底部有三组数字：ABA（美国银行家协会）路由号码、帐号和支票号码。ABA 路由 号码唯一标识您的银行。帐号标识您在银行内的帐户。最后，支票号码在您的帐户内是唯一的。
当您的支票交给您的杂货店时，它会被存入商店的银行，而不是您的银行。然后，该银行记录存款以及您支票上的号码。然后，杂货店的银行将支票转发给您的银行，您的银行记录借记并向杂货店的银行汇款。
由于支票上的唯一标识符，您的银行和杂货店的银行可以实施算法，以确保借记和贷记的精确一次处理。这种情况已经持续了很多年，比我们拥有计算机的时间还要长。
标识符：连接和拆分的粘合剂
标识符是将工作连接起来的粘合剂。正是连接工作的能力使我们能够拆分我们的扩展解决方案，并连接以前断开连接的解决方案。
REST：URL 式绑定
REST（具象状态传输3）是一种有趣且有影响力的模式，它利用了 HTTP 和 URL。在 REST 模式中，资源被实现为客户端-服务器调用，这些调用是无状态的。无状态意味着来自客户端的每个请求都包含足够的信息来在服务器端处理请求，而无需利用服务器端存储的任何上下文。会话状态有效地保存在客户端。
资源和表示形式
在 REST 中，资源是可以命名的任何信息片段。通常，资源的名称是 URL。1 资源通常用于表示相关事物的分组，这些分组可用于执行工作。资源的内容可以是静态的或动态的。至关重要的是它可以被命名。
REST 资源可以投影一个或多个表示形式。每个表示形式都是资源的视图，可以为每个用户定制，也可以不定制。资源本身被赋予其自身的 URL 作为身份。
REST：REpresentational State Transfer（具象状态传输）
希望使用资源的用户将被赋予他们自己的表示形式，这些表示形式用一个或多个 URL 标识。资源可能有很多用户。庞大的 URL 身份空间被细分为每个用户的表示形式。工作请求通过 HTTP PUT 命令完成，从而修改表示形式。
在表示形式上涂鸦
更改在表示形式中投影的状态是完成工作的方式。表示形式（可能针对客户端个性化）与在表示形式上涂鸦更改的能力相结合，允许多个客户端使用资源。
URL：混合身份、操作和会话状态
当表示形式发生更改时，对 HTTP PUT 请求的响应会包装在返回的 URL 中。该 URL 中包含会话状态，描述此客户端正在进行和可能长期运行的工作。
URL 中的身份捕获工作的会话状态！
REST：每个动词都可以名词化
REST 将用户的视角映射到表示形式的一组 URL。REST 还定义了调用计算和工作的机制，即对表示形式的修改。正是 REST 或对表示形式的更改导致了更改。
这些名词被描述为 URL。
操作被转换为在 URL 中表示的身份。
身份正在 REST 的桂冠上休息
URL 中捕获的身份是 REST 如此强大的重要原因。底层资源在 URL 命名空间中具有身份。每个表示形式（分配给单个用户）在 URL 命名空间中具有身份。特定操作被捕获，利用 URL 命名空间中的身份——一种使用 URL 身份的强大机制！
身份的作用域界定
身份必须在空间和时间范围内限定，以避免歧义。一方面，这似乎是显而易见且有些愚蠢的说法。另一方面，这是一个令人解放的概念。
标识符可以具有永久唯一 ID，例如 UUID 提供的那些。这些功能强大且有用。标识符可以具有集中式或分层式授权机构来分配其 ID，而这本身就带来了挑战：该授权机构是否可以扩展？它在角色方面是否足够广泛，能够涵盖解决方案的许多不同部分？
对于大多数系统而言，现实情况是身份跨越了看到该特定标识符使用的参与者。当商家与大型电子商务网站互动时，他们将对其合作工作拥有共享的标识符。尽管如此，商家可能不会共享他们用来与私人供应商打交道的标识符。这些私人供应商可能具有不同的标识符，用于与他们产品的制造商互动。
标识符的范围通常取决于托管该标识符的工作流程部分。存在诸如 UPC 或 SSN（社会安全号码）之类的全局 ID，但也存在诸如 SKU 之类的本地 ID，这些 ID 仅为单个商家定义。
“I” 的重要性
身份是我们系统中极其重要的组成部分。当它与另外三个以 “I” 开头的词结合使用时，它的真正力量才会被释放：幂等性、不变性和互换性。
身份和幂等性
幂等性是指可以多次执行工作的属性。如果它发生至少一次，则其行为与它发生恰好一次相同。5 一般而言，幂等性是一个主观概念，它忽略了服务提供的抽象层面之外的副作用。8
幂等性通常取决于工作是否具有身份。在许多情况下，您需要了解操作的身份才能确定您是否之前执行过该操作。还有其他情况，例如读取记录，工作自然是幂等的，因为它在执行时不会留下任何影响。在进行更改的情况下，跟踪是否已完成需要某种身份。
有时，用于提供幂等性的身份是某些连接或会话的结果。这在新的会话到达以重试失败的会话之前都有效。
银行使用了一种简单的方法来处理身份和幂等性，其中包含两个基本技巧
• 交易的身份是预先分配的支票号码。
• 支票通常必须在开出后一年内清算。
第二个约束限制了银行必须维护的已清算支票列表，同时保留了恰好一次的处理。
身份和不变性
不变性是指某些东西不会改变的属性。无论数据被读取多少次，返回的结果都是相同的。不变性是当今许多解决方案的基础，从低级硬件到大规模可扩展解决方案。6
如果没有某种形式化的身份概念，您就不会拥有不变性。
产品 ID 可能会固定多年，而其描述会不断演变。
身份和互换性
互换性可以被视为与不变性的二元性。我们不再问“这东西与我们之前拥有的东西是否相同？”，而是问“这东西与我们之前拥有的东西是否等效？” 它是否足够好？
当制造的物品都是全新的且相同的时，您可以高兴地从仓库中取出任何一件，假设它们没有损坏。产品具有身份，并且该身份意味着它们中的任何一个都可以。它们是可互换的。
当在酒店预订房间时，您可以接受一间特大号床无烟房与另一间一样好——即使一间靠近电梯并且真的很吵。标记为特大号床无烟房的房间组被认为是等效的，并且这些房间中的任何一间都具有身份。您从房间池中预订一间，而不知道具体是哪一间。
回想一下，产品目录中产品描述的标识符指的是产品描述的模糊版本。没关系，任何一个都可以，因为这些版本是可互换的。
明智地使用歧义和互换性可以润滑分布式、长时间运行、可扩展和异构的系统。
互换性的真正艺术在于找到一种方法来识别等效的个体集合
在这些集合中，哪些必须相同，哪些差异是可以接受的。
结论
过去，我们专注于在一个计算机上运行的一个应用程序访问一个 SQL 数据库。虽然我们可能具有基于应用程序的标识符（例如，社会安全号码），但底层系统是基于单元格中的值。关系代数将值与其他值相关联。
随着系统为了扩展而分离，为了提供管理或信任边界而分离，或者为了集成解决方案而结合在一起，标识符和身份构成了连接解决方案的粘合剂。身份也使分离的且互不信任的解决方案形式化。分离或结合在一起都需要身份。
当我们使用身份将工作结合在一起时，有趣的张力是“什么构成了身份？” 特大号床无烟房究竟标识了什么？我们将保证交付的消息交付到哪里了？
新兴的系统和协议都在收紧和放松我们对身份的概念，这很好！它们使完成工作变得更容易。REST、IoT、大数据和机器学习都围绕着故意保持灵活且有时模糊的身份概念。身份概念是我们分布式系统的基本机制的基础，包括互换性、幂等性和不变性。
最后，不要对称呼这种身份过于挑剔。我们将身份视为名称、键、指针、句柄、ID、数字、标识符、UUID、GUID、文档 ID、UPC、ASIN、员工编号、文件名、社会安全号码等等。
确实，任何其他名称的身份都一样甜蜜
参考文献
1. Berners-Lee, T., Masinter, L., McCahill, M. 1994. 通用资源定位符。技术报告，互联网工程任务组，RFC 草案； https://dl.acm.org/citation.cfm?id=RFC1738。
2. Dean, J., Ghemawat, S. 2004. MapReduce：大型集群上的简化数据处理。《第六届操作系统设计与实现研讨会论文集》6, 10； https://dl.acm.org/citation.cfm?id=1251264。
3. Fielding, R. 2000. 网络化软件的架构风格与设计。博士论文。加州大学尔湾分校。
4. Helland, P. 2016. 闲聊的力量。《 通讯》59(11), 40-43； https://dl.acm.org/citation.cfm?id=2980932。
5. Helland, P. 2012. 幂等性不是一种医学疾病。《acmqueue》10(4), 30； https://dl.acm.org/citation.cfm?id=2187821。
6. Helland, P. 2016. 不变性改变一切。《acmqueue》13(9)； https://queue.org.cn/detail.cfm?id=2884038。 （首次印刷于第七届创新数据库研究双年会议（2015 年 1 月）。
7. Helland, P. 2005. 外部数据与内部数据。在《创新数据库研究会议论文集》中； http://cidrdb.org/cidr2005/papers/P12.pdf。
8. Helland, P. 2017. 副作用，居于中心！《 通讯》60(7), 36-39； https://dl.acm.org/citation.cfm?id=3080010。
相关文章
物理物品的普遍动态身份验证
硅 PUF 电路的应用
Meng-Day Yu 和 Srinivas Devadas
https://queue.org.cn/detail.cfm?id=3047967
如何建模状态？让我数数方法
Web 服务规范的技术和社会学研究
Ian Foster 等人。
https://queue.org.cn/detail.cfm?id=1516638
如何取消识别您的数据
大型社会科学数据集中平衡统计准确性和主体隐私
Olivia Angiuli、Joe Blitzstein 和 Jim Waldo
https://queue.org.cn/detail.cfm?id=2838930
Pat Helland 自 1978 年以来一直从事事务系统、数据库、应用程序平台、分布式系统、容错系统和消息传递系统的实施工作。为了娱乐，他偶尔撰写技术论文。他目前在 Salesforce 工作。
版权所有 © 2018，由所有者/作者持有。出版权已许可给 。
最初发表于 Queue vol. 16, no. 6—
在 数字图书馆 中评论本文
更多相关文章
Qian Li, Peter Kraft - 事务和无服务器天生一对
数据库支持的应用程序是无服务器计算令人兴奋的新领域。通过紧密集成应用程序执行和数据管理，事务性无服务器平台能够实现许多在现有无服务器平台或基于服务器的部署中不可能实现的新功能。
Raymond Blum, Betsy Beyer - 实现数字永恒
当今的信息时代正在为世界所依赖的数据创造新的用途和新的管理方式。世界正在从熟悉的物理文物转向更接近信息本质的新型表示方式。我们需要流程来确保知识的完整性和可访问性，以保证历史将被人们了解和真实。
Graham Cormode - 数据素描
您是否曾经感到被源源不断的信息淹没？似乎如潮的新电子邮件和短信需要持续关注，还有电话要接听、文章要阅读和敲门声要回应。将这些碎片组合在一起以跟踪重要内容可能是一个真正的挑战。为了应对这一挑战，流数据处理模型越来越受欢迎。其目的不再是捕获、存储和索引每一分钟的事件，而是快速处理每个观察结果，以便创建当前状态的摘要。
Heinrich Hartmann - 工程师统计学
现代 IT 系统从网络设备、操作系统、应用程序和其他组件收集越来越多的数据。需要分析这些数据以得出有关用户体验和业务绩效的重要信息。例如，需要检测故障、测量服务质量以及预测未来几天和几个月的资源使用情况。
© 保留所有权利。