Question

我有7个节点弹性搜索集群，有2个索引，并且都有嵌套对象映射。插入到 Index2 （通过火花串流）的时间显着延迟。我使用批量插入，每批需要约8-12秒（约100k记录）。

Node Configuration:
RAM: 64 GB
Core: 48
HDD : 1 TB
JVM allocated Memory: 32 GB

Marvel Node Status:
CPU Usages: ~10-20%
JVM Memory: ~60-75%
Load Average    : ~3-35
Indexing Rate: ~10k/s
Search Rate: ~2k/s

Index1 (Replication 1): 
Status: green
Documents: 84.4b
Data: 9.3TB
Total Shards: 400 (Could it be the reason of low performance)

Index2 (Replication 1): 
Status: green
Documents: 1.4b
Data: 35.8GB
Total Shards: 10
Unassigned Shards: 0

Spark streaming configuration:
executors: 2
Executor core per executor: 8
Number of partition: 16
batch size: 10s
Event per batch: ~1k-200k
Elastic Bulk insert count: 100k

Index2映射：

{
  "settings": {
    "index": {
      "number_of_shards": 5,
      "number_of_replicas": 1
    }
  },
  "mappings": {
    "parent_list": {
      "_all": {
        "enabled": false
      },
      "properties": {
        "parents": {
          "type": "nested",
          "properties": {
            "parent_id": {
              "type": "integer",
              "doc_values": false
            },
            "childs": {
              "type": "nested",
              "properties": {
                "child_id": {
                  "type": "integer",
                  "doc_values": false
                },
                "timestamp": {
                  "type": "long",
                  "doc_values": false
                },
                "is_deleted": {
                  "type": "boolean",
                  "doc_values": false
                }
              }
            }
          }
        },
        "other_ID": {
          "type": "string",
          "index": "not_analyzed",
          "doc_values": false
        }
      }
    }
  }
}

我的查询：

使用至少一个is_deleted为false的子项按父ID进行计数。
使用is_deleted false的子ID进行计数。
通过_id

我期待Elastic的更多性能，但它成为我系统的瓶颈。 有人可以建议性能调整吗？我们可以通过此群集配置从Elastic获得更高的插入率吗？

Answer 1

您的问题不在于配置可能是在硬件级别。

尝试禁用throtling

PUT /_cluster/settings
{
    "transient" : {
        "indices.store.throttle.type" : "none" 
    }
}

关闭副本 - ＆gt; 0 将每个节点的分片数量减少到最多2-3个（400是非常危险的）

在索引编制期间将刷新率更改为-1

PUT /{INDICE}/_settings
{
    "index" : {
        "refresh_interval" : "-1"
    }
}

在服务器（节点）之间对批量请求进行负载平衡

通过套接字使用持久性连接

确保您没有遇到网络瓶颈

关于100k文件批量请求，它取决于每个文件的大小，甜蜜的spoot总是在4-5k左右。为什么？因为批量API不会立即插入数据，所以它首先将其缓存，然后将其转储到磁盘中，如果你完成缓存发送过大批量的数据，你将会遇到重大问题。

如果您正在使用持久性连接，您不必担心批量API的大小，您只需打开一个套接字并开始发送批量的1个文档，它就像在bluk中一样快。。（因为它不需要每次处理helo，每次往返节省50ms）

任何其他问题我知道这有点晚了但希望有人发现它对某个点有用

弹性搜索：大型数据集的性能降低

1 个答案: