推荐的最大代币数？(可伸缩性)

Question

我正在使用下面的ngram标记程序来处理15000个文档(并期望它增长到100万个文档)，每个文档都有多达6000个字符的文本(平均100-200个字符)。2-8 ngram是我使用的一种无障碍的方法，因为它需要支持所有的语言。1 QPS应该是足够的(不是很多并发用户)，因此，只要每次搜索需要200 ms的avg，性能就不是优先级。

 "tokenizer": {
    "ngram_tokenizer": {
      "type": "ngram",
      "min_gram": 2,
      "max_gram": 8,
      "token_chars": [
        "letter",
        "digit"
      ]
    }
  }

令牌程序需要与包括CJK在内的所有语言一起工作，因此需要ngram。另一种方法是为CJK语言(或者其他语言)使用分析器插件，这将产生更少的标记。但如果可能的话，我更喜欢一刀切的方法。

最大的示例文档使用大于纳克的10000个令牌，其大小略高于一兆字节。但是，如果这是一个问题，我可能可以为每个标记的文本设置一个最大值。虽然我只有大约15000份文档，而且搜索速度足够快，但我不知道这是如何与#的文档进行缩放的。这个数额合理吗？Elasticsearch是否对最大令牌数量有任何有记录的建议/限制？

更多信息:内存优化部署(ES Cloud)、2个区域、4GB存储和每个区域2GB RAM、162个碎片。记忆压力在30%左右。

Answer 1

在问题的开头，您提到了100万个文档，但后来您提到了15k，所以请澄清这一点，您的问题非常类似于我在我的这个stackOverflow的答案中回答的内容，但是我想补充几个更多的细节。

这将有助于您为什么使用n-gram，并解释您的用例，以便我们可以解释选择，如果可能的话。除此之外，使用ngram肯定很昂贵，在索引和查询时占用更多的CPU、内存、磁盘和infra，并且已知会导致性能问题，但也有各种因素，比如集群大小、索引配置(主碎片和副本碎片的配置)，以及如何在Elasticsearch集群中分配它们。

除非提供更多的信息，否则很难提供具体的建议，还需要对数据集和集群进行基准测试，因为每个部署都是独一无二的。

额外提示:您可以使用 profile API 来了解执行细节，并在查询.中查找瓶颈。

希望这有帮助，如果你需要更多的信息，请告诉我。