企业的可发现性

当企业中有新的信息到达时，不论是来了一个新员工、员工的某条记录更新、剽窃者信息或者是会员俱乐部登记，人们需要记住其他什么组织数据和这个信息相关。

企业发现的一个常见办法是采用“联合搜索”技术，把查询传递给每个相关的业务系统。正如我们所证明的，这种方式对于数据发现数据系统并不适用。可发现性，尤其是在大规模、实时的环境中，目录是必需的。

联合搜索不是万能的

企业组织有众多的业务系统，每个系统都有自己专用的业务功能、定制的信息结构、分析和报告。二级数据聚合是很常见的，而且包含如数据仓库、业务数据存储和数据集市。数据聚合存在无数的信息孤岛，每个孤岛都和特定的任务或功能相关。

传统的联合搜索系统涉及用户查询每个孤岛的数据库，获取相关内容。更复杂的联合搜索系统使用智能中间件，为数据库的每个查询做代理；智能中间件是一个模型，在该模型中，中间件通过自动结合各种信息来处理查询，并对查询的结果进行编制，返回集成的结果集给查询者。

在需要信息的时候，联合搜索“即时”收集跨孤岛的数据。虽然这种类型的联合搜索在一些场景下是可用的，但是无法很好地适合于高性能的企业可发现性，后者需要根据数据发现数据来生成。

有两种主要的原因使得联合搜索无法扩展：

现有的系统通常不包含高效定位一条记录所需的必要的索引。如支付系统通常会包·含预先构建的索引（对数据定义指针），从而有助于在员工号码、纳税ID号码和名字进行查询。支付系统很少会包含高效的方式来定位地址或者电话号码上的记录。假设新发现的赌博诈骗者暴露了他的地址和电话号码。我们的支付系统保留所有员工的电话号码和地址记录（毕竟它需要发送支票）。但是该支付系统无法简单地生成（如果它可以）员工的列表，这些员工和之前提到的赌博诈骗有相同的地址或电话号码。即使在支付系统中为员工的电话号码中创建了一条索引，但是它仍然无法使人们在相同的系统中定位紧急联系电话号码。如果我们无法对赌博诈骗者的验证信息和所有相关的员工数据进行比较，我们还是错过了发现员工和诈骗者之间的联系。

如果某个字段不在索引中，在数据库中定位一条记录的方法称为“表扫描”。在表扫描过程中，对搜索的值和表中每条记录的值进行比较——从数据库中的第一条记录开始比较，到第二条，等等。因此，数据库越大，每次搜索花费的时间越长，因而主服务器系统上的计算压力就越大。

更糟糕的是，联合搜索需要递归处理（某些情况下需要重复一些步骤），这对于分·布式查询环境简直是一场噩梦。假设你执行一条联合查询，是为了发现和某个特定的人相关的企业记录——也就是说，根据某个特定的人的名字和出生日期开始查询。如果联合查询返回这个人的一些新的属性，如一些地址和电话号码，那么你就了解了一些新的东西。为了更全面地了解，需要最大化利用所了解到的关于这个人的新数据，也就是说，初始化另一个企业范围的联合查询，防止基于这些新的数据点，定位额外的数据。因此，如果第二次的联合查询发现了另一个地址，拼写名字的多种方式，以及一两个别名，那么又会发生什么情况呢？更具体全面地说，每次了解一些能够发现先前丢失的记录的知识，发现过程必须执行另一个企业范围的联合查询。

下面这个真实的案例强调了这一点。某个企业组织（一个商业实体，不是政府）有2000多个数据库。用户查询被定向到这些数据库中来收集相关的记录。为优化搜索过程而设计的优秀的中间件产品需要花很多年的时间，以及几百万美元的成本。这种智能的系统会识别哪个数据库应该处理哪个查询，确定合理的数据库访问方式，把查询同时传播给所有相关的集合，并汇集了解到的知识。但是，这种联合搜索方式永远都无法克服一个严重的设计缺陷：每次发现了解一些知识（如一个别名或者一个新的电话号码），优秀的中间件必须重新把这些查询发给很多数据库。这种递归过程运行在大规模的计算机集群中，最终需要定制为每8分钟停止处理。注意下一次的递归查询可能最终会发现一条重要记录。

但是，需要8分钟！这意味着用户或者系统只能等着，无法执行任何操作，因为在这段期间内无法获取到任何答案。然而，在数据发现数据的情况下，数据是个问题。这意味着每当有新的数据到达，在处理这些数据之前会有最多高达8分钟的延迟。想象一下，在整个企业网络，每秒提交成百上千的联合查询的规模下，通过无数的业务系统递归执行，使用联合查询这种方式是多么得不切实际！

如果以上提到的因素还不具有足够的吸引力，联合搜索的致命一击是所有必须搜索的系统在物理上必须是可访问的，而不是处于维护或者备份状态，或者处在周期性的半夜或者月末的批处理过程中。当然，连接性也必须是完全可运作的。考虑这些需求以及由成百上千的涉及建筑、时区和大陆的系统组成的组织。联合搜索无法支持“数据发现数据”的任务，因为它无法大规模地基于企业的发现力来发布数据。