9.mysql的数据迁移到es中

背景

• 从开发的角度说，就是老板叫我用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中

以后再说吧