Question

我们将弹性搜索用于以下用例 Elasticsearch版本：5.1.1
注意：我们正在使用AWS托管的ElasticSearch

我们有一个多租户系统，每个租户都会存储多件物品的数据，租户数量会逐日增加。

exa：每个租户都有以下信息。

1] tickets
2] sw_inventory
3] hw_inventory

目前的索引策略如下：

INDEXNAME：
tenant_id（GUID）exa：tenant_xx1234xx-5b6x-4982-889a-667a758499c8

类型：

1] tickets
2] sw_inventory
3] hw_inventory

我们面临的问题：

1]公共字段的映射冲突exa：（id，name，userId）类型（ticket，sw_inventory，hw_inventory）
2]随着租户数量的增加，指数的数量也可达到1000或2000。

如果我们改变索引策略是不是一个好主意？

EXA：索引名称：

1] tickets
2] sw_inventory
3] hw_inventory

类型：

tenant_tenant_id1
tenant_tenant_id2
tenant_tenant_id3
tenant_tenant_id4

因此，只有3个巨大的指数，N个类型作为租户。

所以在这种情况下的问题是哪种解决方案更好？

1]许多小指数和3种类型 OR
2] 3个巨大的指数和多种类型

此致

Answer 1

这两种方法都不起作用。正如其他人所提到的，这两种方法都会降低成本并阻止您升级。

考虑为每组数据设置一个索引和类型，例如sw_inventory然后在映射中有一个区域，用于区分每个租户。然后，您可以在X-Pack或Search Guard等安全插件中使用文档级安全性，以防止一个租户查看其他记录（如果需要）。

Answer 2

我建议采用不同的方法：https://www.elastic.co/guide/en/elasticsearch/guide/master/faking-it.html

意味着自定义路由，其中每个文档具有tenant_id或类似（对于每个租户而言都是唯一的），并将其用于路由和为每个租户定义别名。然后，仅在查询特定租户的文档时，使用别名。

您将以这种方式使用一个索引和一个类型。根据索引的大小，您可以考虑现有的索引大小和节点数，并尝试以这样的方式提供一些分片，使它们在所有数据保持节点上或多或少地均匀分割，并且跟随您的测试性能是可以接受的。如果将来索引变得太大而且分片变得太大而无法保持相同的性能，请考虑创建一个包含更多主分片的新索引，并重新索引新索引中的所有内容。这不是闻所未闻或未使用或不推荐的方法。

1000-2000别名在处理能力方面没有任何意义。如果你有接近10个节点，或者超过10个节点，我也建议使用4-6GB堆大小和至少4CPU核心的专用主节点。

Answer 3

在Elasticsearch 6.0.0或更高版本中创建的索引可能只包含一个映射类型，这意味着不推荐使用doc_type（_type）。

您可以找到here的完整说明，但总的来说有两种解决方案：

每种文档类型的索引

这种方法有两个好处：

数据更容易密集，因此受益于Lucene中使用的压缩技术。
用于全文搜索评分的术语统计信息更可能是准确的，因为同一索引中的所有文档都代表一个实体。

自定义类型字段

当然，群集中可以存在多少个主分片是有限制的，因此您可能不希望将整个分片浪费在仅有几千个文档的集合中。在这种情况下，您可以实现自己的自定义类型字段，该字段的工作方式与旧的_type类似。

PUT twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": { "type": "keyword" }, 
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" },
        "content": { "type": "text" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

你使用旧版本的Elastic，但同样的逻辑可以应用，当你决定这样做时，你会更容易移动到更新的版本所以我认为你应该使用单独的索引结构，或者换句话说3索引和许多类型，但类型作为映射中的字段而不是_type。

Answer 4

我认为这两种策略都有利有弊：

多个索引：

<强>赞成： - 租户数据与其他人隔离，任何查询都不会返回多个结果。 - 如果文档总数非常大，则不同的较小索引可以提供更好的性能

缺点：难以管理。如果每个索引都有很少的文档，那么您可能会浪费大量资源。

已编辑：根据评论的性能和弃用功能，避免在同一索引中使用多种类型

ElasticSearch：更多索引与更多类型

4 个答案: