背景
- 从开发的角度说，就是老板叫我用es了，没那么多为什么，爸爸说了算 😂
- 从业务角度，mysql已经不能满足我对全文检索的需求了。我需要检索某一个字段包含"圣诞节刚刚过去"这一字符串的记录。这对mysql是个很头疼的问题，但在es中，是个很简单的事。
- 此外es结合kibana还能实现很多数据可视化和数据分析的功能。
问题
- mysql的结构化数据如何平铺成es中的文档结构的数据
- 使用什么方式把数据本身从mysql迁移到es中
解决方案
如果你被上述问题困扰过，可以参考以下方案
- 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结构
- 使用什么方式把数据本身从mysql迁移到es中
以后再说吧😂
