【问题标题】:Elasticsearch structure in the correct and effective way for search engine搜索引擎正确有效的 Elasticsearch 结构
【发布时间】:2021-09-21 01:39:21
【问题描述】:

我正在为我的音频商店构建一个搜索引擎。

我只对音频文档使用 1 个索引,结构如下:

{
  id: { type: 'integer' },
  title: { type: 'search_as_you_type' },
  description: { type: 'text' },
  createdAt: { type: 'date' },
  updatedAt: { type: 'date' },
  datePublished: { type: 'date' },
  duration: { type: 'float' },
  categories: {
    type: 'nested',
    properties: {
      id: { type: 'integer' },
      name: { type: 'text' }
    },
  }
}

按照发布日期的顺序通过文本搜索音频文档很简单。 但我想通过基于特定范围内的音频收听时间和购买历史的趋势来进行文本搜索和排序,例如:过去 3 个月或过去 30 天的文本搜索趋势音频,所以我调整结构如下:

{
  ...previousProperties,
  listenTimes: {
    type: 'nested',
    properties: {
      timestamp: { type: 'date' },
      progress: { type: 'float' }, // value 0-1.
    },
  },
  purchaseHistories: {
    type: 'nested',
    properties: {
      timestamp: { type: 'date' }
    },
  },
}

这是我获取过去 3 个月的热门音频的查询,它奏效了:

{
  bool: {
    should: [
      {
        nested: {
          path: 'listenTimes',
          query: {
            function_score: {
              query: {
                range: {
                  'listenTimes.timestamp': {
                    gte: $range,
                  },
                },
              },
              functions: [
                {
                  field_value_factor: {
                    field: 'listenTimes.progress',
                    missing: 0,
                  },
                },
              ],
              boost_mode: 'replace',
            },
          },
          score_mode: 'sum',
        },
      },
      {
        nested: {
          path: 'purchaseHistories',
          query: {
            function_score: {
              query: {
                range: {
                  'purchaseHistories.timestamp': {
                    gte: 'now+1d-3M/d',
                  },
                },
              },
              boost: 1.5,
            },
          },
          score_mode: 'sum',
        },
      },
    ],
  },
}

我的方法有些不确定,例如:

  • 每个音频的收听次数和购买历史记录都很大,我这样组织数据是否有效?我只是用样本数据进行测试,它似乎工作正常。
  • 每次我将收听时间和购买历史的新记录推送到音频文档时,Elasticsearch 是否会重新索引整个文档?

我是 Elasticsearch 的新手,所以有人可以就这个案例给我一些建议,非常感谢!

【问题讨论】:

    标签: elasticsearch audio search-engine elasticsearch-nested nested-fields


    【解决方案1】:

    第一个问题很好,这取决于您将如何实现它,您必须注意原子操作,因为我猜,您计划获取侦听次数,然后保存增量值。如果您在一个线程中从一个应用程序执行此操作并且它设法及时处理它,那么您很好,但您无法扩展。我会说 elasticsearch 并不是真正为这种交易而设计的。我脑海中闪现的第一个想法是将数字保存到 SQL 数据库中并按某个时间表更新 elasticsearch。我想这些结果不必实时更新?

    关于第二个问题,我将发布来自 elasticsearch 文档 The document must still be reindexed, but using update removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation. 的引用,您可以在此 link 上找到更多信息。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-01-24
      • 1970-01-01
      • 2011-02-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多