ElasticSearch 多渗透性能

Question

我有一个专门的过滤器索引。
那里有3000 查询。这是一个典型的查询：

 {
    "index": "articles_percolators",
    "type": ".percolator",
    "body": {
        "query": {
            "filtered": {
                "query": {
                    "bool": {
                        "should": [
                            {
                                "query_string": {
                                    "fields": [
                                        "title"
                                    ],
                                    "query": "Cities|urban|urbanization",
                                    "allow_leading_wildcard": false
                                }
                            },
                            {
                                "query_string": {
                                    "fields": [
                                        "content"
                                    ],
                                    "query": "Cities|urban|urbanization",
                                    "allow_leading_wildcard": false
                                }
                            },
                            {
                                "query_string": {
                                    "fields": [
                                        "url"
                                    ],
                                    "query": "Cities|urban|urbanization",
                                    "allow_leading_wildcard": false
                                }
                            }
                        ]
                    }
                },
                "filter": {
                    "bool": {
                        "must": [
                            {
                                "terms": {
                                    "feed_id": [
                                        3215,
                                        3216,
                                        10674,
                                        26041
                                    ]
                                }
                            }
                        ]
                    }
                }
            }
        },
        "sort": {
            "date": {
                "order": "desc"
            }
        },
        "fields": [
            "_id"
        ]
    },
    "id": "562"
}

映射（PHP 数组）。为简洁起见，过滤器、分析器和标记器被排除在外：

    'index' => 'articles_percolators',
    'body' => [
        'settings' => [
            'number_of_shards' => 8,
            'number_of_replicas' => 0,
            'refresh_interval' => -1,
            'analysis' => [
                'filter' => [
                ],
                'analyzer' => [
                ],
                'tokenizer'=> [
                ]
            ]
        ],
        'mappings' => [
            'article' => [
                '_source' => ['enabled' => false],
                '_all' => ['enabled' => false],
                '_analyzer' => ['path' => 'lang_analyzer'],
                'properties' => [
                    'lang_analyzer' => [
                        'type' => 'string',
                        'doc_values' => true,
                        'store' => false,
                        'index' => 'no'
                    ],
                    'date' => [
                        'type' => 'date',
                        'doc_values' => true
                    ],
                    'feed_id' => [
                        'type' => 'integer'
                    ],
                    'feed_subscribers' => [
                        'type' => 'integer'
                    ],
                    'feed_canonical' => [
                        'type' => 'boolean'
                    ],
                    'title' => [
                        'type' => 'string',
                        'store' => false,
                    ],
                    'content' => [
                        'type' => 'string',
                        'store' => false,
                    ],
                    'url' => [
                        'type' => 'string',
                        'analyzer' => 'simple',
                        'store' => false
                    ]
                ]
            ]
        ]
    ]

然后我一次将文档发送到mpercolate API，100。这是mpercolate 请求的一部分（1 个文档）：

{
    "percolate": {
        "index": "articles_percolators",
        "type": "article"
    }
},
{
    "doc": {
        "title": "Win a Bench Full of Test Equipment",
        "url": "\/document.asp",
        "content": "Keysight Technologies is giving away a bench full of general-purpose test equipment.",
        "date": 1421194639401,
        "feed_id": 12240778,
        "feed_subscribers": 52631,
        "feed_canonical": 1,
        "lang_analyzer": "en_analyzer"
    }
}

100 文章在我的 MacBook Pro 2.4 GHz Intel Core i7（4 核，8 带 HT）上以 ~1 second 处理，所有内核最多：

这对我来说似乎相当慢，但我没有可比较的基础。
我有一个具有相同映射（但有 6 个分片）的常规索引，有超过 30 亿个文档（仍然）存在于具有24 core Xeon 和128GB RAM 的单个服务器上。此类查询在不到100ms（在热服务器上）中搜索整个索引。

我的设置是否存在明显错误，是否有其他人对渗滤器的性能进行了基准测试？我没有在网上找到任何关于此的其他内容......

我的 ES 版本是 1.4.2，具有默认配置，工作负载完全受 CPU 限制。

编辑

因为John Petrone's 评论关于在生产环境中进行测试是正确的，所以我在生产环境中使用的相同 24 核 Xeon 上进行了测试。即使不是更糟，渗透指数为 8 的碎片索引的结果也是相同的。时间在 1 秒到 1.2 秒之间，而网络延迟低于我的笔记本电脑。
这可能是因为 Xeon 的每个内核的时钟速度较慢 - 2.0GHz 与 i7 的 2.4Ghz 相比。

这导致 CPU 利用率几乎恒定在 800% 左右：

然后我用 24 个分片重新创建了索引，时间已降至每 100 个文档 0.8 秒，但 CPU 时间增加了一倍多：

我每秒有大约 100 个文档的恒定流，并且将来查询的数量会增加，所以这对我来说有点担心。

Answer 1

所以要明确一点，您无法将 24 核 Xeon 和 128GB 内存的正常 Elasticsearch 性能与笔记本电脑上的 ES percolate 性能进行比较 - 硬件和软件截然不同。

对于许多大型索引设置（例如您的具有 30 亿个文档的设置），您在运行查询时往往会受到磁盘或内存的限制。只要你有足够的两者，查询性能可以相当高。

渗透是不同的——你实际上是在索引每个文档，然后针对每个文档运行存储在渗透器中的每个查询，所有这些都在内存中的 Lucene 索引中：

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-percolate.html

渗透水平扩展并且往往受 cpu 限制 - 您可以通过添加具有足够 cpu 的额外节点来扩展它。

通过 multi percolate api 提交的 100 个文档针对 3000 个已注册的 percolate 查询，您基本上是在运行 300,000 个单独的查询。我希望它会在 Macbook 上绑定 cpu - 我认为你最好在一个更受控制的环境（单独的服务器）中对它进行基准测试，并且你可以通过添加额外的节点来扩展它。

更新

因此，为了更好地了解瓶颈是什么以及如何提高性能，您需要从减少注册查询数量和一次减少文档数量开始，然后逐步增加。这将使您更清楚地了解幕后发生的事情。

我会从一个文档（不是 100 个）开始，注册的查询要少得多，然后运行一系列测试，其中一些增加了文档的数量，一些增加了注册的查询的数量，在多个步骤中，然后到上面100 个文档，一次和 3000 个以上的查询。

通过查看结果，您将更好地了解性能下降与负载的关系 - 与文档数量成线性关系，与注册查询数量成线性关系。

我会尝试其他配置变体 - 而不是通过批量 percolate api 的 100 个文档，而是在多个线程中尝试单个 doc api（看看它是否是一个多 doc api 问题）。我还会尝试在同一系统上运行多个节点，或者使用许多较小的服务器，看看您是否在多个较小的节点上获得更好的性能。我还会改变分配给 JVM 的内存量（更多不一定更好）。

最终，您需要一系列数据点来尝试确定您的查询如何扩展以及拐点在哪里。