zoukankan      html  css  js  c++  java
  • ES之数据迁移

    应用背景

    • 数据量过大,索引分片数量不足,导致数据入库较慢的情况,需要扩大分片的数量。
    • 数据的mapping需要修改,但是大量的数据已经导入到索引中了,重新导入数据到新的索引太耗时;但是在ES中,一个字段的mapping在定义并且导入数据之后是不能再修改的。
    上述情况下需要重建索引进行数据迁移,ES提供了_reindex这个API来实现这个功能,它相对于重新导入数据速度更快,大概是bulk导入数据的5-10倍。

    数据迁移步骤

    1、创建新的索引

    在创建索引的时候需要把表结构创建好。

    2、复制数据

    1)直接复制索引到新的索引名称
    POST localhost:9200/_reindex
    {
      "source": {
        "index": "indexName"
      },
      "dest": {
        "index": "newIndexName"
      }
    } 
    2)查询复制索引到新的索引名称
    POST localhost:9200/_reindex
    {
      "source": {
        "index": "indexName",
        "type": "typeName",
        "query": {
          "term": {
            "name": "shao"
          }
        }
      },
      "dest": {
        "index": "newIndexName"
      }
    } 

    3)利用命令

    curl _XPOST 'ES数据库请求地址:9200/_reindex' -d{"source":{"index":"old_index"},"dest":{"index":"new_index"}} 
    但如果新的index中有数据,并且可能发生冲突,那么可以设置version_type"version_type": "internal"或者不设置,则Elasticsearch强制性的将文档转储到目标中,覆盖具有相同类型和ID的任何内容:
    POST _reindex
    {
      "source": {
        "index": "old_index"
      },
      "dest": {
        "index": "new_index",
        "version_type": "internal"
      }
    }

    数据迁移效率

    常规情况下,如果只是进行少量数据迁移,利用普通的reindex就可以达到要求。但是当需要迁移的数据量过大时,会发现reindex的速度会变得很慢。比如数据量几十个G的场景下,elasticsearch reindex速度太慢,从旧索引导数据到新索引最佳方案是什么?

    原因分析:

    reindex的核心做跨索引、跨集群的数据迁移。慢的原因及优化思路包括:
        1)批量大小值可能太小。需要结合堆内存、线程池调整大小;
        2)reindex的底层是scroll实现,借助scroll并行优化方式,提升效率;
        3)跨索引、跨集群的核心是写入数据,考虑写入优化角度提升效率。

    可行方案:

    1)提升批量写入大小值

    默认情况下,_reindex使用1000进行批量操作,可以在source中调整batch_size。 
    POST _reindex
    {
      "source": {
        "index": "source",
        "size": 5000
      },
      "dest": {
        "index": "dest",
        "routing": "=cat"
      }
    }
    批量大小设置的依据:
    1、使用批量索引请求以获得最佳性能
    批量大小取决于数据、分析和集群配置,一般每批处理5-15 MB物理大小数据。
    2、逐步递增文档容量大小的方式调优
    从大约5-15 MB的大容量开始,慢慢增加,直到看不到性能的提升。然后开始增加批量写入的并发性。使用kibana、cerebro或iostat、top和ps等工具监视节点,查看资源何时开始出现瓶颈。如果开始接收EsRejectedExecutionException,说明地区==当前集群已经达到性能极限。
    借助scroll的sliced提升写入效率
    Reindex支持Sliced Scroll并行化重建索引过程。 这种并行化可以提高效率,并提供一种方便的方法将请求分解为更小的部分。
    sliced原理(from medcl)
    Scroll接口现在可以并发进行数据遍历,每个Scroll请求,可以分成多个Slice请求,可以理解为切片,各Slice独立并行,利用Scroll重建或者遍历要快很多倍。slicing的设定分为两种方式:手动设置分片、自动设置分片。手动设置分片参见官网。自动设置分片如下:
    POST _reindex?slices=5&refresh
    {
      "source": {
        "index": "twitter"
      },
      "dest": {
        "index": "new_twitter"
      }
    }
    slices大小设置注意事项:
    1)slices大小设置可以手动指定,或者设置slices设置为auto,auto的含义是:针对单索引,slices大小=分片数;针对多索引,slices=分片的最小值。
    2)当slices的数量等于索引中的分片数量时,查询性能最高效。slices大小大于分片数,非但不会提升效率,反而会增加开销。
    3)如果这个slices数字很大(例如500),建议选择一个较低的数字,因为过大的slices 会影响性能。
    实践证明,比默认设置reindex速度能提升10倍+。
  • 相关阅读:
    常见寻找OEP脱壳的方法
    Windows内核原理系列01
    HDU 1025 Constructing Roads In JGShining's Kingdom
    HDU 1024 Max Sum Plus Plus
    HDU 1003 Max Sum
    HDU 1019 Least Common Multiple
    HDU 1018 Big Number
    HDU 1014 Uniform Generator
    HDU 1012 u Calculate e
    HDU 1005 Number Sequence
  • 原文地址:https://www.cnblogs.com/johnvwan/p/15645008.html
Copyright © 2011-2022 走看看