为了账号安全,请及时绑定邮箱和手机立即绑定

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

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

C#
千万里不及你 2023-09-24 15:48:16
我有一个 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?
查看完整描述

1 回答

?
慕侠2389804

TA贡献1719条经验 获得超6个赞

是的。单个索引可以处理大量数据:您不需要将它们拆分得那么小。事实上,从性能角度来看,带有小分片的小索引实际上更糟糕,因为它会导致每个节点有大量分片,从而消耗堆空间和开销。

如果您定期收到大量数据,那么创建单个基于日期的索引是有意义的,因此也许只有该index_name-yyyyMMdd模式才有效。

最后,您始终可以使用通配符搜索所有索引。所以你可以通过查询来搜索上面的内容index_name-*。在您现有的模式中,您可以执行相同的操作:index_patterns-*index_patterns-yyyy-*等。

查看完整回答
反对 回复 2023-09-24
  • 1 回答
  • 0 关注
  • 57 浏览

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信