9.mysql的数据迁移到es中

合集 - elasticsearch(13)
1.1.elasticsearch运行2.2.elasticsearch中的mapping3.3.CRUD及批量操作4.5.elasticsearch中查询条件5.4.elasticsearch中聚合查询6.6.elasticsearch中search template和alias7.7.elasticsearch重建索引
8.9.mysql的数据迁移到es中
9.8.解决elasticsearch深度分页问题10.10.elasticsearch集群red恢复损坏的索引11.elastic常用api12.elastic优化13.elasticsearch oom问题分析
收起

背景

  • 从开发的角度说，就是老板叫我用es了，没那么多为什么，爸爸说了算 😂
  • 从业务角度，mysql已经不能满足我对全文检索的需求了。我需要检索某一个字段包含"圣诞节刚刚过去"这一字符串的记录。这对mysql是个很头疼的问题，但在es中，是个很简单的事。
  • 此外es结合kibana还能实现很多数据可视化和数据分析的功能。

问题

  1. mysql的结构化数据如何平铺成es中的文档结构的数据
  2. 使用什么方式把数据本身从mysql迁移到es中

解决方案

如果你被上述问题困扰过，可以参考以下方案

  1. mysql的结构化数据如何平铺成es中的文档结构的数据

设定index的mapping

这里需要介绍三种字段的type，分别是 object、nested、join

object

现在有个问题，下面的数据如何存入到es中呢，它对应的mapping应该是什么样的呢

{
    "name": "BeJson",
    "url": "http://www.bejson.com",
    "page": 88,
    "isNonProfit": true,
    "address": {
        "street": "科技园路.",
        "city": "江苏苏州",
        "country": "中国"
    },
    "links": [
        {
            "name": "Google",
            "url": "http://www.google.com"
        },
        {
            "name": "Baidu",
            "url": "http://www.baidu.com"
        },
        {
            "name": "SoSo",
            "url": "http://www.SoSo.com"
        }
    ]
}

name、url这些字段好处理，直接设定字段"type" : "text"或者"type" : "keword"或者

"type" : "text",//text类型全文搜索
"fields" : {
  "keyword" : {
     "type" : "keyword",//keyword支持聚合查询
     "ignore_above" : 256
     }
 }

就行了，但是对于address和links，这种里面包含json对象，或者数组的，怎么处理呢。这里可以采用"type" : "object"来处理。如下

{
    "address": {
        "type": "object",
        "properties": {
            "street": {
                "type": "text"
            },
            "city": {
                "type": "text"
            },
            "country": {
                "type": "text"
            }
        }
    },
    "links": {
        "type": "object",
        "properties": {
            "name": {
                "type": "text"
            },
            "url": {
                "type": "text"
            }
        }
    }
}

可能会对links有疑问，它明明是数组，却怎么和address的设置类似。其实es中是没有单独的数组这一类型，因为他所有的字段都支持数组，比如你是text，你可以放多个值进去，以name为例，你可以放"name":["张三", "李四"]这样的数据进去。
而且，es默认对这种嵌套结构建立的索引就是object类型， "type": "object"可以省略 😂
于是可以变为下面这样

{
    "address": {
        "properties": {
            "street": {
                "type": "text"
            },
            "city": {
                "type": "text"
            },
            "country": {
                "type": "text"
            }
        }
    },
    "links": {
        "properties": {
            "name": {
                "type": "text"
            },
            "url": {
                "type": "text"
            }
        }
    }
}

甚至，通过添加properties，可以无限嵌套下去。

下面说object类型的缺点了，缺点也是由它本身结构导致的

对于数组结构，是这么存储数据的,以上面的address为例,他会把json结构平铺开，然后把所有这个字段的值放在平铺后的字段上：

"links.name" : ["Google","Baidu","SoSo"]
"links.url" : ["http://www.google.com","http://www.baidu.com","http://www.soso.com"]

这在查询时就出现问题了，本来Google和http://www.google.com是绑定的，但是这种结构无法满足这种绑定的关系，也就是如果你想查name是Baidu，并且url是http://www.google.com的，竟然也能查出来😂，而这和前面所插入的文档内容不符。

所以需要nested结构和join结构出场了

nested

嵌套结构解决了我们查询嵌套文档字段的问题，同样的，也可以解决，在es中实现类似mysql的join查询的问题。
外键就需要设置为nested（虽然现在设计表几乎不用外键约束了，但外键的逻辑还是在的 😂 )
另外，nested字段本身会形成一个文档，只不过是嵌套在大的文档下，所以在统计索引的文档数时，实际上是最外层的文档数加上nested字段形成的文档数

{
    "mappings": {
        "properties": {
            "orderNo": {
                "type": "text"
            },
            "finance": {
                "type": "nested",
                "properties": {
                    "no": {
                        "type": "text"
                    },
                    "name": {
                        "type": "text"
                    }
                }
            },
            "dengdeng": {
                "type": "nested",
                "properties": {
                    "no": {
                        "type": "text"
                    },
                    "name": {
                        "type": "text"
                    }
                }
            }
        }
    }
}

这里需要注意，以nested里面的字段为查询条件，需要修改下查询DSL，在外层加一层nested，每有一层nested嵌套关系，就需要加一层

{
    "query": {
        "nested": {
            "path": "finance",
            "query": {
                "bool": {
                    "must": [{
                            "match": {
                                "finance.no": "1234"
                            }
                        },
                        {
                            "match": {
                                "finance.name": "bob"
                            }
                        }
                    ]
                }
            }
        }
    }
}

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-nested-query.html
这里有官方描述

由于es本身对文档通过nested字段进行了绑定，索引更新数据时，整个文档都会被替换，代价会大一些，但是由于关系绑定好了，查询会快一些。这里的代价大一些，查询快一些自然就是和join类型对比啦。

join

join 其实有父子文档的概念，父文档通过一个字段关联一个子文档，
这个结构比较复杂的是在你推数据时，需要指定对应的父文档是哪个
mapping结构如下

{
    "mappings": {
        "properties": {
            "order_relation": {
                "type": "join",
                "relations": {
                    "order": ["comment", "finance", "dengdeng"]
                }
            },
            "orderNo": {
                "type": "text"
            },
                        "comment": {
                "type": "text"
            },
            "finance": {
                "type": "keyword"
            },
            "dengdeng": {
                "type": "text"
            }
        }
    }
}

解释一下

  • 6.x版本之后没有指定的type了，都是_doc

  • 所以将所有表的字段都建在一个索引中，不可以分type区分父子文档了。比如orderNo是order表，comment是评论表，finance是金融单表，这里一个字段代表一个表，为了简化嘛😂

  • 新增一个字段order_relation，里面规范了父子关系，以后新增一个文档时，都加上这个字段，里面的值表面这个文档的身份，"order": ["comment", "finance", "dengdeng"]表示的是order是父文档，comment、finance、dengdeng是子文档。

  • 新增父文档时不用指定id，只需指定身份

    PUT index/_doc/1?refresh
{
"order_no": "1234",
"order_relation": "order"
}
//表明我这个文档是父文档

  • 新增子文档时需要指明身份，也需要指定你这个子文档绑定的是哪个父文档

PUT index/_doc/3?routing=1&refresh 
{
  "comment": "This is an answer",
  "order_relation": {
    "name": "comment", 
    "parent": "1" 
  }
}

优点就是更新数据时，不用连带着父子文档一起改，缺点是查询效率不如nested结构

  1. 使用什么方式把数据本身从mysql迁移到es中

以后再说吧😂


__EOF__

本文作者：赛博朋克V
本文链接：https://www.cnblogs.com/pengliblogs/p/17946825.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！
posted @   赛博朋克V  阅读(93)  评论(0)  编辑  收藏  举报
相关博文：
·  2.elasticsearch中的mapping
·  8.解决elasticsearch深度分页问题
·  数据库：MySQL、HBase、ElasticSearch三者对比
·  Elasticsearch 从入门到实践 小册笔记
·  倒排索引和ES相关概念对比MySQL
阅读排行：
· TypeScript + Deepseek 打造卜卦网站：技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异
· 三行代码完成国际化适配，妙~啊~
点击右上角即可分享
微信分享提示
SQL AI 助手