在 Elastic Search 中通过三个调用更新索引策略的文档效率不高

Question

我有一个 AWS Elastic Search 服务器。使用映射模板和索引策略。

{

  "index_patterns": "users*",

  "order": 6,

  "version": 6,

  "aliases": {

    "users": {}

  },

  "settings": {

    "number_of_shards": 5

  },

  "mappings": {

    "_doc": {

      "dynamic": "strict",

      "properties": {

        "id": { "type": "keyword" },

        "emailAdress": { "type": "keyword" }

      }

    }

  }

}

指数策略是{index_patterns}-{yyyy}-{MM}-{order}-{version}

public async Task<Result> HandleEventAsync(UserChanged @event, CancellationToken cancellationToken)

{

    // 1. Get User, I could get away with this call if Index was known and strategy not used

    var userMaybe =

        await _usersRepository.GetByIdAsync(@event.AggregateId.ToString(), cancellationToken);

    if (userMaybe.HasValue)

    {

        var user = userMaybe.Value.User;

        var partialUpdate = new

        {

            name = @event.Profile.Name,

            birthDate = @event.Profile.BirthDate?.ToString("yyyy-MM-dd"),

            gender = @event.Profile.Gender.ToString(),

            updatedDate = DateTime.UtcNow,

            updatedTimestampEpochInMilliseconds = EpochGenerator.EpochTimestampInMilliseconds(),

        };

        // 2. Remove fields with NULL values (if found any)

        // 3. Partial or Full update of the document, in this case partial

        var result = await _usersRepository.UpdateAsync(user.Id, partialUpdate, userMaybe.Value.Index, cancellationToken: cancellationToken);

        return result.IsSuccess ? Result.Ok() : Result.Fail($"Failed to update User {user.Id}");

    }

    return Result.Fail("User doesn't exist");

}

因此，在这个方法中，我使用 SQS 消息，由于查找索引的原因，我从 Elastic Search 检索文档，因为我不明确知道它，使用以下方法删除任何 NULL 字段，因为更新中的序列化程序将包含 NULL 值，然后部分更新文档。

这是 1 次更新的 3 个 Elastic Search 操作，我知道可以通过决定仅容忍文档中的空值来删除 NULL 值 UpdateByQuery 调用，但我们可能会面临无法在需要时使用 Exists/NotExists 查询这些字段的问题。

我的问题是，如果我改变策略，对所有用户文档使用常量索引，这些文档的数量并不多，目前也不会真正增长到数十亿，我的弹性搜索、分片/索引的性能是否会受到影响ETC？

Answer 1

是的。单个索引可以处理大量数据：您不需要将它们拆分得那么小。事实上，从性能角度来看，带有小分片的小索引实际上更糟糕，因为它会导致每个节点有大量分片，从而消耗堆空间和开销。如果您定期收到大量数据，那么创建单个基于日期的索引是有意义的，因此也许只有该index_name-yyyyMMdd模式才有效。最后，您始终可以使用通配符搜索所有索引。所以你可以通过查询来搜索上面的内容index_name-*。在您现有的模式中，您可以执行相同的操作：index_patterns-*或index_patterns-yyyy-*等。