精华内容
下载资源
问答
  • 给left join关联关系字段加索引
    千次阅读
    2021-05-01 06:21:10

    给left join关联关系字段加索引

    2018-07-04

    left join是相当耗资源的操作,如果关联的字段没有索引的话,速度是很慢的,所以如果有left join的话,最好用索引字段取关联。

    创建索引会消耗大量资源,会导致数据库死锁,最好在非高峰时段创建。

    1、将left join关联关系字段都加为索引,

    2、prepare TS

    ym=`date +%Y%m`

    nm=`date -d '1month' +%Y%m`

    its_src=CONTACT_DATA_IDX_TS

    its_dst=CONTACT_DATA_IDX_TS_${ym}

    idx_ts1=/data3/oracle/contact_data_idx_ts_${nm}_1.dbf

    sqlplus abc/ta123456 << EOF

    set hea off

    --alter tablespace $its_src rename to $its_dst;

    CREATE TABLESPACE $its_src DATAFILE '$idx_ts1' SIZE 512M AUTOEXTEND ON NEXT 256M MAXSIZE UNLIMITED BLOCKSIZE 8k;

    3、创建索引并指定表空间。

    CREATE INDEX IDX_LOGIN_MESSAGE_CID on LOGIN_MESSAGE(COMPANY_ID);DROP INDEX index_name ON table_name

    CREATE INDEX IDX_contact_data_view_user_id on contact_data(view_user_id) TABLESPACE CONTACT_DATA_IDX_TS;--为索引指定表空间

    CREATE INDEX IDX_contact_data_NAME on contact_data(NAME) TABLESPACE CONTACT_DATA_IDX_TS;

    4、修改index的表空间

    alter index pk_t_user rebuild tablespace 111_inx;

    5、索引能提高检索数据的效率,会一定程度降低数据insert的效率;如果新增的数据是按照索引的顺序递增或递减,则无需定期重建索引;反之,则应该定期重建。

    相关日志

    更多相关内容
  • 通过图文给大家介绍了关于MySQL中两表关联的连接表如何创建索引的相关资料,文中介绍的非常详细,对大家具有一定的参考学习价值,需要的朋友们下面来一起看看吧。
  • 电信设备-地理信息模型与建筑信息模型一体化关联索引构件方法.zip
  • 情况描述:在MySQL的user表中,对a,b,c三个字段建立联合索引,那么查询时使用其中的2个作为查询条件,是否还会走索引?根据查询字段的位置不同来决定,如查询a, a,b a,b,c a,c 都可以走索引的,其他条件的查询不能...

    情况描述:在MySQL的user表中,对a,b,c三个字段建立联合索引,那么查询时使用其中的2个作为查询条件,是否还会走索引?

    根据查询字段的位置不同来决定,如查询a,     a,b    a,b,c    a,c   都可以走索引的,其他条件的查询不能走索引。

    组合索引 有“最左前缀”原则。就是只从最左面的开始组合,并不是所有只要含有这三列存在的字段的查询都会用到该组合索引。

    验证过程如下所示:

    首先,在SQLyog中建立一个user表,如下图所示;

    b5cf76940fe5a3d0a3eddf68b1507c50.png

    对中间3个字段(user_name,user_age,user_password)进行联合索引 index_user_join

    查询情况如下所示:

    1.同时查询这3个字段作为条件的SQL,索引情况及SQL语句如下所示:

    SELECT *FROM t_user WHERE  user_name='zs' AND user_age=20 AND user_password='123456';

    其使用索引情况如下所示:

    321174b7dfe30d94ac3976f2f9b24dfb.png

    从执行结果上可以看到是从走索引进行查询的

    2.使用user_age和user_password作为查询条件进行查询,索引及SQL语句如下所示:

    a0e0cd1f6e02c233cb855255e2ccaccb.png

    3.使用user_name和user_password作为查询条件进行查询,索引及SQL语句如下所示:

    13d35d81f1167b12c9d10ca6677d2ae3.png

    4.使用user_name作为查询条件进行查询,索引及SQL语句如下所示:

    062395a83308543dfab7a40f74252137.png

    5.使用user_age作为查询条件进行查询,索引及SQL语句如下所示:

    cb81ee46124bb303a5d02fe1e6ab8eef.png

    6.使用user_password作为查询条件进行查询,索引及SQL语句如下所示:

    21fb245a185fa3e6172731e46906dbbd.png

    以上是针对普通的字段建立联合索引的测试情况及截图,欢迎小伙伴们来补充~

    展开全文
  • Elasticsearch 可以用于:分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索;实时分析的分布式搜索引擎;可以扩展到上百台服务器,处理PB级别的结构化或非结构化数据。 Elasticsearch的文件存储   ...
  • php中的索引数组是指以数字为键的数组。并且这个键值 是自增的 关联数组指的是一个键值对应一个值,并且这个键值是不...以上这篇基于php数组中的索引数组和关联数组详解就是小编分享给大家的全部内容了,希望能给大家一
  • MySQL 视图、索引、外键关联策略

    千次阅读 2020-05-30 11:29:12
    目录视图索引外键关联策略   视图 视图是一张虚表,将查询结果集保存起来,作为视图使用。实际存在的表叫作基本表。   视图的作用 提高安全性。grant授权用户只能操作视图,通过视图来操作基本表,可以...


     

    视图

    视图是一张虚表,将查询结果集保存起来,作为视图使用。实际存在的表叫作基本表。
     

    视图的作用

    • 提高安全性。grant授权用户只能操作视图,通过视图来操作基本表,可以保护基本表中的数据
    • 提高查询性能。视图只是基本表的一部分,查视图比查全表快。尤其是多表查询的时候,查视图一张表比连接多张表查询要快很多

     

    视图常用操作

    -- 创建视图,as指定结果集,假设cs系的id是1
    create view view_dep_cs as (select * from tb_student where dep_id=1);  -- 可以把这个视图作为cs系学生信息表来使用
    
    
    -- 修改视图定义,用新结果集覆盖原来的结果集。如果视图不存在,会自动创建
    create or replace view view_dep_cs as (select id,name from tb_student where dep_id=1);  
    
    
    -- 从视图查询数据
    select * from view_dep_cs where name='chy';  --查询cs系名字是chy的学生
    
    
    -- 删除视图
    drop view view_dep_cs;
    

     

    创建视图的完整语法

    create [algorithm=merge] view view_dep_cs as (select * from tb_student where dep_id=1) [with check option] ;
    

    algorithm指定视图执行机制,有3个可选的值

    1、merge 合并

    不创建临时表,执行时会先用视图定义替换视图名,每次都是操作基本表,并不会提高查询性能,但可以增改删查。
     

    2、temptable 临时表

    把结果集保存为临时表,每次操作的都是临时表,可以提高查询性能,但只读,不能增删改。
     

    3、undefined 未定义
    不指定algorithm就是undefined,使用数据库设置的默认值,mysql默认使用merge。

     

    如果使用merge,还可以设置一个可选参数:with check option 检查条件。

    创建视图时设置了条件where dep_id=1,即视图中的记录都是dep_id=1的。

    如果指定了with check option,往视图中插入、更新记录时,都要满足记录的dep_id=1这个条件,否则不执行操作;如果不指定with check option,则不要求dep_id=1。

    使用merge时往往要设置with check option。

     

    不可更新的视图

    即使使用merge,也不一定可以进行增删改,as指定视图数据来源,如果视图来源中使用了一下任一项,则创建的视图只读(只能查询)、不能增删改

    • 聚合函数
    • group by子句
    • having子句
    • distinct关键字
    • union运算符
    • from来源于多个表或者来源于不可更新的视图

    一句话:不是直接来源于一个基本表的视图,则该视图只读、不能更新视图数据。

     

    索引

    不使用索引时,要操作某些记录,需要遍历整张表来找到匹配的记录,时间开销大。

    索引相当于数据表的目录,根据目录可直接定位到章节,根据索引可直接定位到数据表的记录,无需遍历整张表。

     

    索引的优缺点

    • 极大提高了检索速度,尤其是记录数很多的时候(优)
    • 索引也是一张表,要占硬盘空间,有额外的空间开销(缺)
    • 对基本表进行增改删时会同步到索引(维护索引),有额外的时间、资源开销(缺)

    相较于优点,索引的缺点微不足道。

     

    常见的几种索引

    • 单值索引:索引中只包含数据表的一列(一个字段)
    • 唯一索引:索引中列的值唯一,一般是数据表的主键列
    • 联合索引:也叫作符合索引,索引中包含数据表的多个列
    • 全文索引:只能对MyISAM引擎的表使用,且索引中的列要是char、varchar、text等文本类型
    • 覆盖索引:如果索引中已经包含了查询sql要用到的所有字段,则会直接在索引中进行查询,不再回表。如果不是覆盖索引,则先查索引定位记录在表中的位置,再回表查询。

     

    常用的索引操作

    create index index_ts on tb_student(id,name);  -- on指定使用哪张表的哪些字段来创建索引。经常使用学号、姓名定位学生(记录),所以使用这2列创建索引
     
    show index from tb_student;  -- 查看某个表上所有的索引
     
    drop index index_ts on tb_student;  -- 删除索引
    

    索引、视图都可以在数据库管理工具(比如Navicat)中直接操作。索引是在 “设计表” 中操作的。

     

    常见的索引方式

    1、b+树

    eg. 以id字段创建索引,假设有7条记录,id 1~7
    在这里插入图片描述
    查找id=7的记录的地址:4 -> 6 -> 7
     

    2、hash  通过hash值直接定位记录位置

    eg. 使用id字段建立索引,查找id=7的记录:计算7的hash值 -> 根据hash值直接确定记录在表中的位置。
     

    b+树要一级一级地找,hash直接定位,效率远高于b+树。但一般都是使用b+树,因为大多数存储引擎都支持b+树,hash只有memory存储引擎支持。

     

    mysql对使用了索引的sql语句的优化

    mysql会对使用了索引的sql语句进行优化,主要优化点如下

    • 自动调整同级别and条件的顺序,把使用了索引的字段放前面,尽量走索引。不要过度依赖于mysql自身的优化,尽量把走索引的条件写在前面。
    • 走索引的字段使用in限定范围时,in()中的值可以乱序。
    • 如果使用in()的字段走的是唯一索引,且()中只有一个值时,会自动优化为=等值判断。
    --eg. username、tel都加了唯一索引, age没加索引
    
    
    --mysql会自动调整同级别and条件的顺序、尽量用到索引、选择合适的索引,用and连接时条件时条件可以乱序
    where age>18 and username='xxx'
     
    
    --使用了or后,同级别的条件不会走索引,慎用or
    
    --三个字段都不会走索引
    where username='xxx' and tel='xxx' or age>18
    --三个字段都不会走索引,or左边的()作为整体看待不会走索引,()里面的各字段自然不会走索引
    where (username='xxx' and tel='xxx') or age>18
    --or所在级别的条件tel、age不会走索引,但username会走索引
    where username='xxx' and (tel='xxx' or age>18)
    
    
    --模糊查询尽量使用前缀匹配,只有前缀匹配的模糊查询才会走索引
    
    --username会走索引
    where username like 'x%'
    --以下2种的username都不会走索引
    where username like '%x%'
    where username like '%xx'
    

     

    联合索引的最左匹配原则

    联合索引的最左匹配原则:使用联合索引时,会从联合索引中最左边的字段向右匹配,直到遇到没有使用到联合索引中的字段,或者遇到<、>、between之类的范围限定。

    --eg. username、tel、email三个字段建立联合索引
    
    --只会用到联合索引的username字段,没有涉及tel到tel就断了,不会用到联合索引中的email字段
    where username='xxx' and email='xxx'
    
    --只会用到联合索引的username字段,遇到范围限定like直接断了
    where username='xxx' and tel like '%888%' and email='xxx'
    

     

    索引的最佳实践

    使用好索引包括2个方面:设计、建立合理的索引, sql语句中合理运用索引。
     

    哪些字段适合创建索引
    • 主键
    • 外键
    • 频繁作为条件的字段。eg. 经常要用where name=’ ',那就给name字段创建索引
    • group by分组使用的字段
    • order by排序使用的字段
    • 统计(聚合函数)使用的字段

    添加主键时,会自动给主键列创建唯一索引(Unique);添加外键时,会自动给外键列创建普通索引(Normal)。

    创建索引后,从表中查找匹配的记录时数据库会自动使用合适的索引。

     

    创建索引的注意点

    1、记录少的表不必建立索引,一般以1千行记录为界限。

    建立索引有额外的空间开销,增改删时维护索引也有额外的时间开销,记录数少时全表扫描的性能相对较高,没有必要创建索引。
     

    2、频繁增改删的字段,维护索引开销大,不适合用于创建索引。
     

    3、区分度低的字段建立索引没有多大意义,尽量选择区分度高(列值重复少)的字段建立索引;列值较长的字段不适合作为索引,就算要作为索引,也尽量只取列值的前缀作为索引。
     

    4、联合索引会覆盖其中包含的单列索引,存在联合索引时再建立其中的单列索引没有意义。
     

    5、联合索引遵循最左匹配原则,设计联合索引时,尽量将最左字段设置为值区分度高、使用频率高的字段。
     

    6、一张表建立的索引不宜太多,一般不超过5个索引。

    一张表建立太多的索引,空间占用多,数据库会花费更多的时间在索引的选择上,且增删改需要同时维护几个索引,对性能的影响较大。
     

    7、及时删除废弃的、没有必要的索引,避免维护索引带来的不必要开销。

     

    sql语句中合理运用索引

    字段加了索引后,sql语句使用索引时需要注意以下几点

    1、数据库字段为字符串类型时,sql语句中该字段的值加不加引号都行,但加了引号才会走索引,不加引号则不会走索引。

    --值没有加引号,username加了索引也不会走索引
    select ... from user where username=xxx;
    
    --username会走索引
    select ... from user where username='xxx';
    

     

    2、where子句中,比较运算符左边的列参与了数学运算,则该列不会走索引;参与了函数调用的列不管是放在比较运算符的哪边,都不会走索引。

    --比较运算符>=左边的age参与了数学运算,不会走索引
    select ... from user where age-18>=0
    
    --可以将数学运算移到右边 (以下2个sql的age都会走索引)
    select ... from user where age>=0+18
    --或者把要走索引的列移到比较运算符的右边
    select ... from user where 0+18<=age
    

     

    3、使用联合索引时,考虑到最左匹配原则,尽量把条件中联合索引中的字段放在范围限定的前面,且字段顺序尽量与联合索引中的字段顺序保持一致,保证尽可能多的使用联合索引中的字段。

     

    主键

    mysql创建表时,如果没有指定主键,且存在 整型+not null+自增 的字段,则该字段必须设置为主键才合法。

    mysql允许创建表时不指定主键,未指定主键时mysql会自动把 整型+not null 的字段作为主键,如果不存在这样的字段,InnoDB会自动生成一个隐式主键,这个隐式主键我们看不到。

    尽量手动给每个表设置主键,保证主键可控。

     

    外键关联策略

    eg. tb_order通过外键user_id关联tb_user的主键id,当update、delete tb_user的id时,如何处理与之对应的tb_order中的记录?
    在这里插入图片描述
    设计外键时,mysql提供了4种外键关联策略

    1、RESTRICT 限制(默认)

    如果有外键关联了tb_user的id,则tb_user不能删除被关联的记录、不能更新关联记录id字段的值(会报错)。

    如果要删除记录、更新id字段的值,需要先切断关联关系,比如先删除tb_order中与之关联的记录、或者把相关记录外键字段的值置为null。

     

    2、CASCADE 级联

    删除tb_user中的记录时,会自动删除tb_order中与之关联的记录;修改tb_user中id字段的值时,会自动修改tb_order中与之关联的记录的外键字段的值(同步变化)。

     

    3、NO ACTION 不做处理

    删除、更新tb_user中的user_id字段的值时,tb_order中与之关联的记录不作任何处理。此种策略需要存储引擎支持,如果存储引擎不支持,会自动换为RESTRICT。

     

    4、SET NULL 置为NULL

    删除tb_user的记录,或者更新id字段的值,会自动将tb_order中与之关联的记录的外键字段的值置为NULL。

    这种方式有一个要求:设计tb_order时,外键字段不能用NOT NULL约束。

     

    关联数据的更新、删除逻辑应该由我们在代码中控制,更可控,而非交由数据库自动处理,所以一般不设置外键,或者设置外键后使用 NO ACTION 策略。

    展开全文
  • 需求2: 在cluster1上有如a,b两索引,均有字段filed_a,索引a,b各自包含其它字段,建立新索引如c,要求c包含a索引全部文档,且在a和b索引关联字段 field_a 相同的文档中把b文档其它字段更新到索引c中。...

    1、实战项目需求

    需求1:有一个小需求

    kafka源数据:

    topicA:{"A_content":"XXX","name":"A","type":"XXX","id":1}
    topicB:{"B_content":"XXX","name":"B","type":"XXX","id":1}

    现在想将两个topic的数据写到同一个es索引中,但由于更新性能太慢,有啥思路可以加速写入性能呢(topicA和topicB的数据可能会有几天的延时)?

    需求2:

    在cluster1上有如a,b两索引,均有字段filed_a,索引a,b各自包含其它字段,建立新索引如c,要求c包含a索引全部文档,且在a和b索引关联字段 field_a 相同的文档中把b文档其它字段更新到索引c中。

    2、需求分析

    如上两个需求都涉及两个索引数据之间的关联。

    提到数据关联或者多表关联,我们都能想到的是四种多表关联核心实现:

    • 宽表,特点:空间换时间。

    • Nested 嵌套文档,特点:适合于子文档更新不频繁场景。

    • Join 父子文档,特点:适合于子文档频繁更新的场景。

    • 业务层面自己实现,特点:灵活自控。

    以上四种都无法实现上述需求涉及的问题。

    需求2的本质是:跨索引相同字段关联扩充字段实现。

    在 7.5 版本的 ingest 预处理环节新增了enrich processer 字段丰富功能,能很好的实现上述需求。

    2、enrich processor 解读

    2.1 enrich processor 全局认知

    全局来看:enrich processor 是 ingest 预处理管道中众多 processors中的一个。

    32d0eafdefad9e50e4d079049c35649b.png

    2.2 enrich processor 最早发布版本

    如前所述,Elasticsearch 7.5 版本后新增了该项功能。

    2.3 enrich processor 定义

    enrich:中文可以翻译成丰富,本质也可以理解:“使丰富”的意思。

    借助 enrich 预处理管道,可以将已有索引中的数据添加到新写入的文档中。

    官方举例如下:

    • 根据已知 IP 添加 web 服务或供应商。

    • 根据产品 ID 添加零售订单。

    • 根据电子邮件补充添加联系信息。

    • 根据用户地址添加邮政编码。

    2.4 非 enrich processor 工作原理

    为了对比,我们先讲一下:非 enrich processor 的工作原理。

    非 enrich 的预处理管道都相对“简单、直白”,如下图所示:

    2597075b59f38321b5678c05d0532eee.png

    图片来自:Elastic官方文档

    新写入的文档中间经过预处理管道预处理实现了数据的 ETL 清洗后写入到目标索引中。

    中间的 ETL 清洗包含但不限于:trim、drop、append、foreach等管道处理方式。

    2.5 enrich processor 工作原理

    区别于非 enrich processor 的“直来直去”,enrich processor 在预处理管道中间加了“秘制配方”。

    978312eb4cabf3380e6e166f36808b9e.png

    图片来自:Elastic官方文档

    加了什么呢?

    多了:enrich policy。

    大家可以回想一下,上一次您在 Elasticsearch 中听到 policy 是在什么时候?

    ILM 索引生命周期管理里面 policy 实际是阶段 phrase 和动作 action 的综合体。

    而 enrich 数据预处理环节,enrich 的组成有哪些呢?

    2.5.1 enrich policy

    对应上图中中间虚线框的圆圈部分,先上例子,建立下直观的认知。

    PUT /_enrich/policy/data-policy
    {
      "match": {
        "indices": "index_test_b",
        "match_field": "field_a",
        "enrich_fields": [
          "author",
          "publisher"
        ]
      }
    }
    • indices:一个或多个源索引的列表,存储的是待 enrich 扩展的数据。

    • match:policy 类型,除了传统的match类型,还有应用于地理位置场景的:geo_match。

    • match_field:源索引中用于匹配传入文档的匹配字段。

    • enrich_field:源索引中的字段列表,用于添加到新传入的文档中。

    2.5.2 source index 源索引

    用于丰富新写入文档 (incoming documents)的索引。

    它是目标索引中添加的待丰富数据的源头索引。没有了它,enrich 将无从谈起。

    2.5.3 enrich index 丰富索引

    这是一个咱们从来没有见过的新概念,有必要详细解读一下。

    eb617005a8a662575ab1861c7f01bd1a.png

    enrich index 是执行 enrich policy 生成的索引。

    执行命令如下:

    POST /_enrich/policy/data-policy/_execute

    enrich index 特点如下:

    • elasticsearch 内部管理的系统级索引。

    • 目的很“单一”——仅用于 enrich processor。

    • 以 .enrich-* 开头。

    • 只读,不支持人为修改。

    aa090b8ce3bffb23f2248505bb0d6914.png

    get 索引会有说明禁止修改

    e5a76808634958bff7c71c37e83bb984.png

    更新索引报错如上

    • 会被强制段合并,以实现快速检索。

    这时候,读者可能会有疑问:直接用 source 索引不香吗?费那劲干啥?

    原因:直接将传入文档与源索引中的文档进行匹配可能会很慢且需要大量资源。

    为了加快速度,enrich 索引应运而生。

    如果再引申的话,source 源索引可能会有大量的增删改查操作,而 enrich 一经创建,便不允许更改。

    除非进行重新执行 policy。

    2.6 enrich processor 适用场景

    • 日志场景

    • 其他需要预处理跨索引丰富数据的场景

    2.7 enrich processor 性能问题

    enrich processor 执行多项操作,可能会影响 ingest 管道的速度。

    官方强烈建议在将 enrich process 部署到生产环境之前对其进行测试和基准测试。

    官方不建议使用 enrich 处理器来 enrich (丰富)实时数据。enrich processor 最适合不经常更改的索引数据类型。

    3、enrich processor 实战解读

    针对文章开头的需求1、需求2:传统的索引之间的关联方式都不能解决问题。

    核心实现步骤如下图所示:

    b140191de350c465f9cb2463bcc87ca9.png

    借助 enrich processor 实现解读如下:

    如下各个步骤和上图一一对应。

    3.1 第一步:创建初始索引

    DELETE index_test_a
    PUT index_test_a
    {
      "mappings":{
        "properties":{
          "field_a":{
            "type":"keyword"
          },
          "title":{
            "type":"keyword"
          },
          "publish_time":{
            "type":"date"
          }
        }
      }
    }
    
    POST index_test_a/_bulk
    {"index":{"_id":1}}
    {"field_a":"aaa", "title":"elasticsearch in action", "publish_time":"2017-07-01T00:00:00"}
    
    
    DELETE index_test_b
    
    
    PUT index_test_b
    {
      "mappings": {
        "properties": {
          "field_a": {
            "type": "keyword"
          },
          "author": {
            "type": "keyword"
          },
          "publisher": {
            "type": "keyword"
          }
        }
      }
    }
    
    POST index_test_b/_bulk
    {"index":{"_id":1}}
    {"field_a":"aaa", "author":"jerry", "publisher":"Tsinghua"}

    3.2 第二步:创建data-policy

    DELETE _enrich/policy/data-policy
    PUT /_enrich/policy/data-policy
    {
      "match": {
        "indices": "index_test_b",
        "match_field": "field_a",
        "enrich_fields": ["author","publisher"]
      }
    }

    3.3 第三步:执行data-policy

    POST /_enrich/policy/data-policy/_execute

    3.4 第四步:创建 pipeline

    DELETE /_ingest/pipeline/data_lookup
    PUT /_ingest/pipeline/data_lookup
    {
      "processors": [
        {
          "enrich": {
            "policy_name": "data-policy",
            "field": "field_a",
            "target_field": "field_from_bindex",
            "max_matches": "1"
          }
        },
        {
          "append": {
            "field": "author",
            "value": "{{field_from_bindex.author}}"
          }
        },
        {
          "append": {
            "field": "publisher",
            "value": "{{field_from_bindex.publisher}}"
          }
        },
        {
          "remove": {
            "field": "field_from_bindex"
          }
        }
      ]
    }
    • enrich processor:实现了将 b 索引的 field_a 相关联数据,和新写入索引数据融合,使得新索引“丰富”。

    • append processor:实现了字段修改。

    • remove processor:实现了删除不需要的中间字段数据。

    3.5 第5步:reindex 索引

    DELETE index_test_c
    POST _reindex
    {
      "source": {
        "index": "index_test_a"
      },
      "dest": {
        "index": "index_test_c",
        "pipeline": "data_lookup"
      }
    }

    3.6 第6步:检索结果

    GET index_test_c/_search

    最终结果数据如下截图所示:

    cac89474920fce123e3c48f972cb5f9a.png

    索引 c 实现了索引 a 和 索引 b 的融合,索引c 变得“丰富”。

    4、小结

    新的功能或者新的概念的产生是基于特定的业务需求,追根溯源 enrich processor 起源于如下的 bug 或 新需求:

    https://github.com/elastic/elasticsearch/issues/32789

    最早版本的这张图:

    fca1a04720efe2915c5ad607844612e9.png

    更能够说明:enrich processor 的本质。

    一句话:新写入的文档通过 enrich processor 达到了跨索引丰富数据的目的,最终写入目标索引。

    而丰富数据的实现是借助:enrich policy 将源索引 source orgin data 生成系统只读索引 enrich index 实现的。

    本文的 enrich processor 预处理可以算作跨索引处理数据的扩展。

    希望本文的解读,对于您理解 Elasticsearch 跨索引关联数据有所帮助!

    也欢迎留言交流您对 enrich processor 的看法。

    参考

    https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest-enriching-data.html

    https://www.alibabacloud.com/blog/how-do-we-use-an-ingest-node-in-elasticsearch-to-enrich-logs-and-metrics_597453

    https://www.elastic.co/cn/blog/introducing-the-enrich-processor-for-elasticsearch-ingest-nodes

    推荐

    1、重磅 | 死磕 Elasticsearch 方法论认知清单(2021年国庆更新版)

    2Elasticsearch 7.X 进阶实战私训课(口碑不错)

    3、干货 | Elasticsearch多表关联设计指南

    c2a5e4bc658e5bd15369c40eb9487804.png

    更短时间更快习得更多干货!

    已带领80位球友通过 Elastic 官方认证!

    76877830774957f9661686cb15345572.gif

    比同事抢先一步学习进阶干货!

    展开全文
  • 下面小编就为大家分享一篇php关联数组与索引数组及其显示方法,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
  • 关联表查询和索引使用的探讨一则

    千次阅读 2021-05-03 09:51:51
    关联表查询和索引使用的探讨一则今天碰到一个小的查询统计需求,总结一番确实有些意思。在一张超多200万行的表中,需要查询在某个时段,符合全部10个类型的信息。即:例如某个手机号码,在某个时段完成了全部10种...
  • 两张表test_a,test_b结构和索引信息如下,通过主键inner join关联时,外表为什么不走索引呢?create table test_a (id int,birthday date not null,comment varchar (50) not null,primary key test_a_pk (id),...
  • 多表关联如何建立索引

    千次阅读 2019-10-22 11:23:16
    我是用的三张表进行关联的,一大两小。下面看一下三张表的具体结构。 三张图对应三张表,然后下面是我写的查询sql select a.*, b.*, c.* from statjiankong_etl a left join ibnr b on a.anadate = b....
  • MySQL多表之间关联查询,如果要命中索引,一定要保证关联字段类型一致! 最近利用flowable流程框架开发,需要业务表与流程历史记录之间,用PROC_INST_ID_字段关联,查询非常慢,最慢几乎达到10s。查看SQL执行计划时...
  • MySQL:多表关联查询添加索引

    千次阅读 2021-08-12 15:23:12
    目标sql: select * from copy666 jee left join ga_bu ogb on jee... 过程中遇到的问题 过程中遇到了大表和小表的关联字段格式不一致导致索引失效问题: 发现索引失效是可以找找是不是关联字段的类型不一致。
  • 遇到如下这种情况,用户表(user)与部门表(dept)通过部门用户关联表(deptuser)连接起来,如下图所示:针对该表,有如下四种选择:针对于user_uuid建立单列索引idx_user针对于user_dept建立单列索引idx_dept建立组合...
  • 1、场景:当使用关联查询(inner 、left、right join)等进行查询时候,关联条件都已建立索引,但查看执行计划发现并未走索引。  原因:两表字段的字符集不相同导致关联查询索引失效  解决方案:修改表字段字符...
  • 本文实例讲述了php实现数组中索引关联数据转换成json对象的方法。分享给大家供大家参考。具体实现方法如下: public static function encode(&$var) { return '{'.implode(',',self::encodeExcute($var)).'}'; } ...
  • 1、从数组的下标分为索引数组、关联数组 代码如下: /* 索引数组,即通常情况下所说的数组 */ var ary1 = [1,3,5,8]; //按索引去取数组元素,从0开始(当然某些语言实现从1开始) //索引实际上就是序数,一个整型...
  • oracle 三种索引

    2013-05-19 21:45:58
    oracle 三种索引的简单描述,位图、B树、全文索引
  • 本文通过图文给大家介绍了关于MySQL中两表关联的连接表如何创建索引的相关资料,文中介绍的非常详细,对大家具有一定的参考学习价值,需要的朋友们下面来一起看看吧。问题介绍创建数据库的索引,可以选择单列索引,...
  • 客户信息36万,中间表62万,关联了却没用到中间表的城市id去查导致没有用到索引 优化之后我的分页查询是这样的 if("2".equals(customer.getSourceType()) &&customer.getHoHouseCustomer()!=null &...
  • mysql关联表查询索引有用么

    千次阅读 2020-06-17 11:02:04
    今天在执行sql语句时,使用表关联查询,结果发现子查询中的索引未使用,直接使用了全表查询,如图所示: 找了半天原因,最后发现,是由于字符集设置问题导致的 当将两个字段的字符集统一后,查询结果如下: ...
  • sql 关联查询索引不生效的原因

    千次阅读 2019-10-31 16:51:42
    sql语句如下: SELECT a.id, a.CODE, a.id, b.CODE FROM table_1 a LEFT JOIN table_2 b ON a.CODE =...问题:关联sql查询时发现索引无效 原因:表a字段的code和表b字段的code字符集编码不一样导致索引失效 ...
  • Mysql-Join 关联查询之索引失效问题

    千次阅读 2019-09-25 13:01:46
    mysql 关联查询时,索引失效问题 案例分析 #常规查询 ​select po.columA, po.columB, tr.id bId from tableNameA tr inner join tableNameB po on tr.columC = po.columC and po.mark = 0 where tr.mark = 0...
  • 今天在执行sql语句时,使用表关联查询,结果发现子查询中的索引未使用,直接使用了全表查询,如图所示: 找了半天原因,最后发现,是由于字符集设置问题导致的 当将两个字段的字符集统一后,查询结果如下: ...
  • 场景: 现在有两个索引分别是 hotel 和 price 1. hotel索引有【id,name,address】 2. price索引有【id,price,date,hotel_id】 price索引里面的hotel_id与hotel索引... 问题: 在这样的场景下,如何实现关联查询?
  • 索引数组&关联数组

    千次阅读 2018-11-12 11:12:52
    &lt;?... //php(数字)索引数组一般表示数组元素在数组中的位置,是有数字组成,下列标从0开始; //数组的构成是有 键 和 值 ...//指定索引号 键=&gt;值 在数组中,键是不相同的,值可以相同 键如果相同时最...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 364,093
精华内容 145,637
关键字:

关联索引