使用我自己的_id，Elasticsearch索引性能越来越差

Question

我正在构建一个相当大的索引--大约30亿个文档，平均大小为2KB，一点也不像父/子关系那样花哨。起初，批量索引运行良好，但现在正在急剧下降。

不确定硬件信息对这个问题是否重要，但如下所示：

该集群目前位于一台服务器上，具有24核、128 BBU和一个带有7200 K磁盘的RAID 10阵列和带有BBU的HW控制器。不幸的是，大多数RAM被其他守护进程占用(大约80 of )。

，以下是重要的(至少我认为如此)：

我在提供我自己的身份证。我已经读过为Lucene选择快速唯一标识符(UUID)了，这一切对我来说都是合乎逻辑的。我的ID是64位整数，最终将是顺序的，但由于各种原因，初始索引是在完全随机ID的情况下成堆完成的。

起初，我的索引是每秒大约3000个文档(瓶颈不是ES，而是从其中提取文档的数据库)。目前，由于不断的查找，服务器几乎无法从IO (99% read)中恢复。我已经索引了大约60%的文档，大约花了两个星期。

当这个初始索引完成后，我将只提供大约100个docs/s的顺序in。这里的主要问题是--的性能会像整个索引是使用顺序in？构建的一样好吗?如果答案是否定的，那么我将放弃当前的索引，使用ES的默认_id字段创建一个新的索引，我的in将在另一个字段中。当然，这需要在应用程序中进行一些更改，但是我的文档很少更新，所以应该不难。

===编辑===

我正在添加更多关于我的设置的信息：

碎片数:6

ES_HEAP_SIZE: 32g

映射(为了简洁起见，不包括PHP数组、过滤器、分析器和标记器)：

    'index' => 'articles',
    'body' => [
        'settings' => [
            'number_of_shards' => 6,
            '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
                    ]
                ]
            ]
        ]
    ]

配置(elasticsearch.yml)：

node.master: true
node.data: true
plugin.mandatory: analysis-kuromoji,analysis-icu,langdetect-1.4.0.2-1368fbe,analysis-smartcn
bootstrap.mlockall: true
action.disable_delete_all_indices: true;
index.merge.scheduler.max_thread_count: 1
indices.memory.index_buffer_size: 3gb
index.translog.flush_threshold_size: 1gb
index.store.throttle.type: none

我已经从主机上删除了其他服务，现在所有128 ES内存都是针对ES的。现在它在索引时不做任何读取IO，因为索引是由操作系统缓存的。

我基本上是用从MySQL到给定ID的自动增量ID来索引文档，我已经写下了这个ID。这些文档不是按顺序进行索引的，而是在整个ID范围内非常随机。在这个索引阶段没有重复的请求(更新)。

主要问题仍然存在：

当我完成批量索引所有if直到我的阈值，然后开始索引新文档只顺序，索引的性能是否与整个索引是用顺序if构建的一样？

Answer 1

我的猜测是，经济放缓与提供您自己的_id字段无关。我建议观看这段关于为生产配置ES的视频，它讨论了许多需要更新的设置。主要是将机器50%的内存固定在JVM上。这对我们的生产至关重要。

http://www.elasticsearch.org/webinars/elasticsearch-pre-flight-checklist/

当然，您还应该在多台机器上有多个生产节点。ES建议生产中至少有3个节点。

另一个考虑因素是，单个索引中的3B记录相当大。您可能会从滚动索引中获得更好的性能(例如，每30天建立一个索引)，然后在需要时使用混叠将所有滚动索引组合成单个可查询的索引。

祝好运!

Answer 2

据我所见，你的案例可能与时间序列数据有关，我们讨论的是6Tb的数据。

碎片数

不要过分分割你的数据。。使其具有较少CPU核心的两个服务器，并使用一个副本创建两个碎片。这样，如果一台服务器发生故障，您就会有一些冗余。

时间序列用例

我猜想，最频繁访问的数据将是最近一两个月。比方说，您有一个名为"events“的别名。并指出所有指标如events_2014_12、events_2014_11、events_2014_10、events_2013、events_2012等。索引越大，添加新文档或搜索新文档所花费的时间就越长。使用月份数据，我认为您不会在底部增加超过100-300Gb的索引。你可以读到它，这里。

_id生成

ElasticSearch总是确保标识符是均匀的。只有在另一个存储中有数据源的情况下，预生成标识符才有意义。

其他

如果您想深入研究这种技术，我可以推荐公司的博客，它提供ElasticSearch作为一种服务。