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。这是 mercolate 请求的一部分(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 秒，所有核数均达到最大值:

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

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

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

编辑

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

它导致 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 的额外节点来扩展它。

针对 3000 个已注册的渗透查询，通过多重渗透 API 提交了 100 个文档，您基本上运行了 300,000 个单独的查询。我希望它在 Macbook 上受 cpu 限制——我认为你最好在一个更受控制的环境(独立服务器)和一个你可以通过添加额外节点来扩展的环境中对其进行基准测试。

更新

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

我从一个文档(不是 100 个)开始，注册的查询少得多，然后运行一系列测试，一些增加文档的数量，一些增加注册的查询的数量，分多个步骤然后继续100 个文档和一次超过 3000 个查询。

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

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

最终，您需要一系列数据点来尝试确定查询的扩展方式以及拐点的位置。