ToB企服应用市场:ToB评测及商务社交产业平台

标题: Elasticsearch Mapping类型修改 [打印本页]
作者: 慢吞云雾缓吐愁    时间: 2023-2-17 21:35
标题: Elasticsearch Mapping类型修改
背景

通常数据库进行分库分表后，目前比较常规的作法，是通过将数据异构到Elasticsearch来提供分页列表查询服务；在创建Elasticsearch索引时，基本都是会参考目前的业务需求、关系数据库中的类型以及对数据的相关规划来定义相关字段mapping的类型.
在Elasticsearch的mapping中的列(或则叫属性)，有几个比较重要的参数(更多参数参考官方文档)
但是在实际的开发过程中，又会有需求对现有的mapping的type进行修改（类似对MySQL数据表的字段进行DDL操作）的诉求。比如商品上的价格price字段，按原来的业务分析，只需要提供数据返回即可，在创建索引时类型定义了keyword了，并且index设置成了false，这时我们需要根据价格的范围查询或则进行排序操作，就希望对mapping进行调整，将类型修改成数字类型，索引也需要加上；今天针对Elasticsearch的Mapping类型进行修改，讨论几个可行的方案
方案1：运用reindex

遇到问题第一时间，我们应该是查询官方文档是否有相关的操作说明，在官方文档中，确定能找到对已有mapping更新的相关api put-mapping,通过这个文档，很快可以找到文档中对修改已有mapping的列的方式（参考官方文档），同时也提到的通过 reindex的方式来修改已有类型的方式；
除了支持的mapping parameters外，您不能更改现有字段的映射或字段类型。更改现有字段可能会使已编制索引的数据无效。如果您需要更改字段的映射，请使用正确的映射创建一个新索引并将您的数据重新索引reindex到该索引中。
如原来索引的mapping如下
  1. PUT /users
  2. {
  3.   "mappings" : {
  4.     "properties": {
  5.       "user_id": {
  6.         "type": "long"
  7.       }
  8.     }
  9.   }
  10. }
  12. //加一了两条数据
  13. POST /users/_doc?refresh=wait_for
  14. {
  15.     "user_id" : 12345
  16. }
  18. POST /users/_doc?refresh=wait_for
  19. {
  20.     "user_id" : 12346
  21. }
复制代码
这时想在修改user_id的类型为keyword,我们直接是修改不了的。
  1. //尝试直接修改type，行不通，会报错
  2. PUT /users/_mapping
  3. {
  4.     "properties": {
  5.         "user_id": {
  6.             "type": "keyword"
  7.         }
  8.     }
  9. }
  11. //报错信息
  12. {
  13.   "error": {
  14.     "root_cause": [
  15.       {
  16.         "type": "illegal_argument_exception",
  17.         "reason": "mapper [user_id] of different type, current_type [long], merged_type [keyword]"
  18.       }
  19.     ],
  20.     "type": "illegal_argument_exception",
  21.     "reason": "mapper [user_id] of different type, current_type [long], merged_type [keyword]"
  22.   },
  23.   "status": 400
  24. }
复制代码
按官方文档说的reindex重新索引可按以下步骤操作
操作步骤

第一步：创建新的mapping new_users 将user_id的类型定义成 keyword
  1. PUT /new_users
  2. {
  3.   "mappings" : {
  4.     "properties": {
  5.       "user_id": {
  6.         "type": "keyword"
  7.       }
  8.     }
  9.   }
  10. }
复制代码
第二步：将原user索引标记为只读

控制我们的应用系统，不再向老索引中写数据，最好对老索引进行只读操作设置，保证在reindex的过程中，不要生产新数据，导致新老索数据不一致；
  1. //设置索引为读写的
  2. PUT /users/_settings
  3. {
  4.   "settings": {
  5.     "index.blocks.write": true
  6.   }
  7. }
复制代码
第三步：将原user索引中的数据迁移到new_users中
  1. POST /_reindex
  2. {
  3.   "source": {
  4.     "index": "users"
  5.   },
  6.   "dest": {
  7.     "index": "new_users"
  8.   }
  9. }
复制代码
reindex还有很多的参数可以配置，包括从别一个集群迁移数据都是可以的，详细可参考：Reindex API
如果新的索引的mapping的定义与原索引的定义有差异的，会按新索引定义的 dynamic 规则进行数据的迁移，具体的，可以参考: dynamic
该dynamic设置控制是否可以动态添加新字段。它接受三种设置：
值说明true新检测到的字段被添加到映射中。（默认）; 新增的数据类型的规则，可以参考：dynamic-mappingfalse忽略新检测到的字段。这些字段不会被编入索引，因此将无法搜索，但仍会出现在_source返回的命中字段中。这些字段不会添加到映射中，必须明确添加新字段。strict如果检测到新字段，则会抛出异常并拒绝文档。必须将新字段显式添加到映射中。同时将原user索引标记为可读写
  1. //设置索引为可读写
  2. PUT /users/_settings
  3. {
  4.   "settings": {
  5.     "index.blocks.write": false
  6.   }
  7. }
复制代码
第四步：切换到使用新的mapping

  1. //为索引增加别名 基本格式
  2. PUT /<index>/_alias/<alias>
  3. POST /<index>/_alias/<alias>
  5. //为new_users索引增加别名users
  6. PUT /new_users/_alias/users
  8. //没有删除老索引前，是增加不了别名的,需要先删除老别名
  9. {
  10.   "error": {
  11.     "root_cause": [
  12.       {
  13.         "type": "invalid_alias_name_exception",
  14.         "reason": "Invalid alias name [users], an index exists with the same name as the alias",
  15.         "index_uuid": "8Rbq_32BTHC4CoO_CqWdXA",
  16.         "index": "users"
  17.       }
  18.     ],
  19.     "type": "invalid_alias_name_exception",
  20.     "reason": "Invalid alias name [users], an index exists with the same name as the alias",
  21.     "index_uuid": "8Rbq_32BTHC4CoO_CqWdXA",
  22.     "index": "users"
  23.   },
  24.   "status": 400
  25. }
复制代码
方案优劣分析

【优点】操作简单，官方方案

该方案，不需要对原索引做操作，在线即可进行，并且操作步骤也简单；也是官方文档提供的方案。
【缺点】数据量大迁移耗时长

当数据最大时，这个数据迁移会比较耗时
结论

当数据量小时，并且希望mapping比较规整好看，该方案是比较推荐的。当数据量大时，可能该方案在数据迁移过程中，可能就是一个问题，需要评估是否可行了；
方案2：运用multi-fields

为不同的目的以不同的方式索引同一个字段通常很有用。这就是multi-fields的目的。例如，一个string 字段可以映射为text用于全文搜索的字段，也可以映射keyword为用于排序或聚合的字段;
在这个方案中，应用的是mapping参数fields来对同一个列，定义多种数据类型；详细[【官方文档】multi-fields] (https://www.elastic.co/guide/en/elasticsearch/reference/7.5/multi-fields.html)
操作步骤

第一步：为列增加fields属性

还是用上面的users这个索引为例，我们还是想在为将user_id的类型定义成 keyword；
  1. PUT /users/_mapping
  2. {
  3.     "properties":{
  4.         "user_id":{
  5.             "type":"long",
  6.             "fields":{
  7.                 "raw":{
  8.                     "type":"keyword"
  9.                 }
  10.             }
  11.         }
  12.     }
  13. }
复制代码
操作完成后，在users的 user_id列下，就多个了个raw的子属性；在我们正常写数据user_id时，索引中就会后成两直索引，一个是long类型的user_id，以及keyword类型的user_id.raw;
该put mapping时，type参数必需有，同时需要跟原来的类型一致，fields中新定义的属性，可以多个；
方案优劣分析

【优点】不影响原索引，同一列可以定义多种类型

通过这方式不会影响原来的索引数据，可以不修改现在的应用程序，查询方式与数据写入方式，都是可以按原来的执行，对应用方无感知，只需要在使用新类型时使用即可，可以说影响是最小的；
同时只是做了一个定义，执行速度是非常快的，对Elasticsearch服务基本不会有太大影响；并且对于同一个列可以定义多个类型，比如商品名称，在多国环境下可以根据不同语言定义不同的分词器；
【缺点】老数据不会自动创建子索引，多出额外的存储

老数据不会自动创建索引，因为需要多出新的索引来，会增加额外的存储；
结论

1、需要对多一列创建多个索引类型时，是一个非常推荐的方案；
2、对于新索引，只有新业务使用，对老数据没有诉求的，也非常推荐该方案；
方案3：运用copy_to

copy_to是将多个字段的值，合并到一个字段中，便于搜索。但是也可以实现一个字段存在多个类型的需求。详细参考【官方文档】copy_to
操作步骤

还是用上面的users这个索引为例，为user_id创建一个copy列： user_id_raw 类型定义成 keyword
  1. PUT /users/_mapping
  2. {
  3.     "properties":{
  4.         "user_id_raw":{
  5.           "type":"keyword",
  6.           "copy_to":"user_id"
  7.         }
  8.     }
  9. }
复制代码
这个方案与方案2：multi-fields 基本是一样的，只是创建列的方式不同，优缺点都一样；
参考资料


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4