java - 如何为共享文档设计Appengine Search API索引？

Question

我正在尝试设计一个适合与AppEngine Search API（java）一起使用的架构，并且鉴于以下用例，我希望能提出一些意见：

在我们的应用程序中，我们希望用户能够搜索Foo类型的对象。 Foo对象如下所示：

{
    groupId: "x1",
    name: "somename"
    someFieldA: "somevalue",
    someFieldB: "somevalue",
    someFieldC: "somevalue"
}

但是，另一个Foo对象可能类似于：

{
    groupId: "x2",
    name: "somename"
    someFieldD: "somevalue",
    someFieldE: "somevalue",
    someFieldF: "somevalue"
}

群组ID很重要：


groupId字段确定每个Foo对象具有哪些属性
（即someFieldA，someFieldB，someFieldC仅适用于具有
X1的groupId）
每个用户只能访问具有特定组ID的Foo


因此，我要解决的用例是，用户应该只能够访问某些Foo（可以通过其任何字段）来搜索Foo。这是两个都有缺点的解决方案：

解决方案1：


为所有Foo创建1个索引。
该索引的字段是每个Foo中每个字段的SUPERSET。
这很有效，因为用户搜索可以转换为： userquery AND (groupId:X OR groupId:Y OR groupId:Z)
这也是很好的，因为所有Foo的不分性别或它们的groupId都是相对于彼此进行排名和排序的。
我认为这种方法行不通，因为每个架构上都有1000个字段限制，并且可能有足够的groupid，以至于所有Foo的所有字段的超集都超过1000个字段


解决方案2：


为每个groupId创建1个索引
用户搜索在那里转换为异步搜索（用户有权访问的每个groupid 1个），然后必须将结果合并
这样的好处是我们不会遇到1000个字段限制
缺点之一是，这可能会导致成本增加，因为您对搜索api进行了1次以上的查询
更重要的缺点是，似乎没有一种简单的方法可以合并每个查询的结果。如果每个查询都返回结果，则将每个返回文档的分数标准化为该查询中的所有结果，那么您将如何合并来自不同查询的结果？


似乎解决方案2是最理想的-但我不知道如何解决结果问题的合并/排序。

有任何想法吗？

-更新1--

以下是一些有关文档外观的具体示例：

{
    groupId:"Hiring Process",
    name: "Bob Smith",
    position: "Software Engineer",
    yearsOfExperience: 6
}

{
    groupId:"Sales Process",
    name: "Frank J",
    company: "Engineering Engineer Inc.",
    contactInfo: "555-555-5555"
}

{
    groupId:"Hiring Process",
    name: "Jane Doe",
    position: "Marketing",
    yearsOfExperience: 3
}

{
    groupId:"Sales Process",
    name: "Jane Moe",
    company: "Google",
    contactInfo: "666-666-6666"
}

如您在上面看到的，这些文档代表人员。每个对象的组标识为“销售流程”或“雇用流程”。请注意，文档的字段根据它们具有的groupId而有所不同。我们系统中的单个用户可以访问有关两个过程中所有人员的所有信息。

因此，可以说我们的用户搜索了 engineer，该搜索应返回2个结果，其中1个表示 Bob Smith，1个表示 Frank J。但是， Frank J结果的排名/得分较高，因为“工程师”一词在文档中出现了两次。

因为所有文档的字段数的超集的大小都可能大于1000，所以我认为我不能将所有文档都放在1个索引中。如果我将索引分片（每个组ID 1个），如何在几组搜索结果中进行排名/评分？

*-更新2--

之所以会超过1000个字段限制，是因为Foo对象的模式是用户可配置的。因此，例如，用户可以创建一个名为“销售流程”的groupId，并添加一些用户定义的字段，例如“潜在客户来源”，“感兴趣的产品”，“截止日期”等。

因为每个用户都可以在数百万个用户中自定义其组，所以所有字段的超集肯定是> 1000。上面列出的示例Foo对象有些简化。 groupId实际上是一个ID，指向用户创建的他们想要的所有自定义字段的架构。 foo对象实际上包含这些字段的值。

Answer 1

这是一个半生不熟的“答案”。我希望它可以激发您的思维，使您想出一个足够有效的真实答案。

对我而言，根据用户输入动态定义架构（即字段名集）的想法是一个危险信号。我可能不太愿意做一个笼统的声明，即永远不要做这样的事情。但这当然似乎值得深思。

如果这些字段是用户定义的，则似乎可以理解，系统没有任何特定的处理知识可用于这些字段。换句话说，对于系统而言，字段必须仅是通用信息容器。你同意吗？

因此，我的想法将朝着消除这一方面的方向发展。

我想知道是否有一种方法可以使实际的字段名称通用（例如UserField1，UserField2等），并将用户提供的字段名称的每个groupId映射到实际的字段名称存储在其他位置。似乎这对于全局搜索（在搜索查询中未提及字段名称）会很好。

我确实知道用户将无法简单地编写类似[engineer yearsOfExperience> 3]的查询。但是，想一想，他们还能这样做吗？是否允许他们定义用户定义字段的类型？

无论如何，我的感觉是不恰当地考虑了这些“领域”。用户定义的字段名以某种方式希望存储为数据，而不用作动态模式。