ES应用场景
实际项目的ES性能问题,大家看看该场景是否适合用ES,如何提高?
Elasticsearch • kennywu76 回复了问题 • 9 人关注 • 4 个回复 • 9681 次浏览 • 2017-03-21 16:08
根据范例里给的mapping定义来看,每个内嵌类型tab_x内部并非用于存放一个object,而是只有一个属性code,这种情况下完全没有必要用nested type,直接用object type就可以了,比如:
{
"index1&quo... 显示全部 »
{
"index1&quo... 显示全部 »
根据范例里给的mapping定义来看,每个内嵌类型tab_x内部并非用于存放一个object,而是只有一个属性code,这种情况下完全没有必要用nested type,直接用object type就可以了,比如:
{
"index1": {
"mappings": {
"tag_type": {
"dynamic": "false",
"_all": {
"enabled": false
},
"properties": {
"tab_a": {
"properties": {
"code": {
"type": "string",
"index": "not_analyzed"
}
}
},
"tab_b": {
"properties": {
"code": {
"type": "string",
"index": "not_analyzed"
}
}
},
......
}
}
}
}
}
其效果等同于一系列扁平的属性:
tab_a.code
tab_b.code
....
nested documents主要应用于外层文档和内层文档有需要join,并且需要维护内层object的独立性的场景。 在索引上实际每个内嵌的object都是单独成一条文档,因此实际生成索引的文档数会远大于外层文档数量。 而使用普通的object类型,内嵌的object被flatten成文档的一条属性而已,实际生成的文档数量小得多。 查询和聚合速度都会快很多。
{
"index1": {
"mappings": {
"tag_type": {
"dynamic": "false",
"_all": {
"enabled": false
},
"properties": {
"tab_a": {
"properties": {
"code": {
"type": "string",
"index": "not_analyzed"
}
}
},
"tab_b": {
"properties": {
"code": {
"type": "string",
"index": "not_analyzed"
}
}
},
......
}
}
}
}
}
其效果等同于一系列扁平的属性:
tab_a.code
tab_b.code
....
nested documents主要应用于外层文档和内层文档有需要join,并且需要维护内层object的独立性的场景。 在索引上实际每个内嵌的object都是单独成一条文档,因此实际生成索引的文档数会远大于外层文档数量。 而使用普通的object类型,内嵌的object被flatten成文档的一条属性而已,实际生成的文档数量小得多。 查询和聚合速度都会快很多。
实际项目的ES性能问题,大家看看该场景是否适合用ES,如何提高?
回复Elasticsearch • kennywu76 回复了问题 • 9 人关注 • 4 个回复 • 9681 次浏览 • 2017-03-21 16:08