看,灰机...

elasticsearch下index和type如何设计比较合理?

Elasticsearch | 作者 canslm | 发布于2018年03月13日 | 阅读数:12512

版本:目前使用elastisearch6.2,logstash6.2.1 filebeats6.2,kibana6.2.1版本,
业务场景:先说一下数据库mysql下的应用,有一个数据库db,数据库下面有26张不同的表,然后每张表对应用户,分为:用户,店铺,虚拟账户,订单,促销,商品,评论等等这些26个业务。
 
主要应用就是想分析用户的活动情况,登陆、地域、交易、评论、账户之间的关联等等用户习惯。目前不需要实时分析,但想能够模拟实时分析。
 
基本的框架是利用filebeats收集数据(不对接mysql数据库,而是利用数据库的导出文本txt文件),然后logstash做filter后output到elasticsearch,利用机器学习组建xpack来分析,最后kibana来展示。这个分析,基本是跨时间较长(一年、两年)、多个用户数据不同业务对比。按照mysql来说就是会有各种复杂的连接之类的操作,因为一个分析场景会涉及不同的表,比如要分析用户交易情况,就要涉及用户信息表、虚拟账号表、交易流水表等多表才能完成。
 
 
(请大神忽略我段的错误理解)数据库相当于index,表相当于type,表字段相当于field。最初设想是,建立一个index,下面设置多个了type,在我的案例里面是26个type。但是现在6.2版本已经不推荐使用一个index下面多个type了(如果在一个index模板下设置多个type,在手工加载template到elasticsearch的时候会报错说“一个index下多余1个type”,当然手工加载这个template是文档要求如果使用logstash的话,那么filebeat需要手工加载index的template)
 
 
 
那么很想请教大神,在设计的时候,下面两种方式
 
 方式一:elasticsearch中,生成一个index,一个index下分成26个type去储存不同的数据
方式二:elasticsearch中,生成26个index,每个index下都只有一个type去储存数据
 
 
 
 
方法一已经不推荐了,但是否可以实现呢?比如加custom field?这样做会对后期分析有什么影响呢?
方法二能符合未来的elk应用,可是这样的话,是不是意味着有关系的表(type)就被分割了?还能进行高效的查询吗?有帖子说单index数据越多查询越慢,没关联的数据不应该放在一起。但是我想这些表之间都是有关联的数据啊,这样分开好?特别矛盾。
 
 如果是第二种方法,
那么logstash这样做是不是可以呢?


参考配置信息:

output {
        if [type] == "log_01" {
                elasticsearch {
                        cluster => 'elasticsearch'
                        host =>         'x.x.x.x'
                        index => 'log_01-%{+YYYY-MM-dd}'
                        port => '9300'
                        workers => 1
                        template => "/data/logstash/conf/template_01.json"
                        template_name => "template_01.json"
                        template_overwrite => true
                }
        }
        if [type] == "log_02" {
            elasticsearch {
                        cluster => 'elasticsearch'
                        host =>         'x.x.x.x'
                        index => 'log_02-%{+YYYY-MM-dd}'
                        port => '9300'
                        workers => 1
                        template => "/data/logstash/conf/template_02.json"
                        template_name => "template_01.json"
                      template_overwrite => true
                }
        }
}
 

 
初学者不知道如何设置这种顶层的架构?请大神指点怎么设计比较有利于以后的分析,谢谢。
已邀请:

ziyou - 一个学习ELK的Java程序员

赞同来自: lunatictwo canslm

首先,ES是非关系性数据库,对于复杂的关系型数据,最好还是不要存储在ES中比较好,建议有好的数据模型或者好的设计方案再使用ES作为数据库。
其次,你说的方法一,肯定是不行的了,一是官方已经不建议这样了,性能方面会下降。二是有可以代替的索引设计方案来替换多类型设计。
然后,基于你的问题我有一些想法,但是没有验证过(下面1是已经在使用的,2没有验证过),你可以作为开阔思路的参考。
1、可以使用分段式的索引命名来建立索引集,把每个索引看做一个表,每个索引集作为一个数据库。单独查询的时候使用一个索引,多表查询的时候使用索引集。
例如:索引A filebeat-a-[date]
          索引B filebeat-b-[date]
          索引C filebeat-c-[date]
如果要查询表A,就使用索引集 filebeat-a-*,查询;如果要查询数据库A、B、C,就使用filebeat-*查询。
类似于这种分段式命名索引的方式来实现你上面说的方案一。
2、你在设计表的时候可以把有关联关系的字段字段名设计是样的,譬如,订单表的订单ID和订单详细表的订单ID是关联两张表的字段,在导入ES的时候就把这两个表导入两个索引中,订单ID的字段名相同,这样分析的时候可以使用这个字段进行相应的分析。

lunatictwo

赞同来自:

0. ES 确实不适合做关系型查询,应该再考虑下其他技术方案选型
1. type 会在 7.0 版本弃用

canslm

赞同来自:

首先,ES是非关系性数据库,对于复杂的关系型数据,最好还是不要存储在ES中比较好,建议有好的数据模型或者好的设计方案再使用ES作为数据库。
-------------------------------------------
我现在的应用应该是比较复杂的关系型数据库,当然目前的数据模型早已经成型了,使用mysql作为生产数据库。ES仅仅作为分析使用。目前其实也是比较困惑的,不知道如何做分析平台的选型,是cdh这种大数据平台呢?还是elasticsearch?当初选择elk完全是因为官网上有一个BANK account的例子,觉得elk可以用来分析、展示我这样的数据https://www.elastic.co/guide/e ... taset
经两位这么一说,感觉是不是elk不太符合我需要做的场景呢?
其次,你说的方法一,肯定是不行的了,一是官方已经不建议这样了,性能方面会下降。二是有可以代替的索引设计方案来替换多类型设计。
然后,基于你的问题我有一些想法,但是没有验证过(下面1是已经在使用的,2没有验证过),你可以作为开阔思路的参考。
1、可以使用分段式的索引命名来建立索引集,把每个索引看做一个表,每个索引集作为一个数据库。单独查询的时候使用一个索引,多表查询的时候使用索引集。
例如:索引A filebeat-a-[date]
          索引B filebeat-b-[date]
          索引C filebeat-c-[date]
如果要查询表A,就使用索引集 filebeat-a-*,查询;如果要查询数据库A、B、C,就使用filebeat-*查询。
类似于这种分段式命名索引的方式来实现你上面说的方案一。
----------------------------------------------------
感谢提供这种方法。非常有用。
2、你在设计表的时候可以把有关联关系的字段字段名设计是样的,譬如,订单表的订单ID和订单详细表的订单ID是关联两张表的字段,在导入ES的时候就把这两个表导入两个索引中,订单ID的字段名相同,这样分析的时候可以使用这个字段进行相应的分析。
---------------------------------
目前数据库中,不同表中相同意义的字段均为相同的字段名,如订单表订单id和订单详细表订单id字段名相同,应该可以。
--
 
l---------------
unatictwo提示es确实不适合关系型查询,现在的需求是搭建一个能够比较迅速进行数据分析(忘记那篇文章了,说大数据其实分析的是valueless数据,不那么有价值的数据,不过觉得电商交易记录应该是比较有价值的吧)的平台,希望这个平台能够承载这个关系型数据的简单筛选,机器学习、聚合、计量分析等等目前比较流行的功能,当然也希望能够方便的进行可视化,目前知道有一些工具比如smartbi之类,不过感觉还是一个基础的筛选工具和可视化工具。
 
 
如果有其他的技术方案,请不吝赐教。

要回复问题请先登录注册