精华内容
下载资源
问答
  • 五行匹配查询
    千次阅读
    2019-12-20 11:45:17

    grep 的 -A 参数可以实现

    [crsusr@rwsaa192 bin]$ ./crsctl stat res -t | grep ora.cvu -A 1
    ora.cvu
          1        ONLINE  ONLINE       rwsaa192                 STABLE
    [crsusr@rwsaa192 bin]$ ./crsctl stat res -t | grep ora.cvu
    ora.cvu
    
    更多相关内容
  • 难道就不能既可以高效实现文本检索,又可以高效处理事务处理、数据更改、关联查询、相似度匹配、复杂正则表达式? 等等······· 新方案的探索 这里尝试探索一种基于DB搭建的搜索引擎方案,如果可以支持高效...

    阅读使人充实,讨论使人敏捷,写作使人精确。

    需求场景假设

    Aken某天在咖啡店听到一首歌,觉得很好听,但不知道具体的歌名,只知道歌曲是“民谣”,歌词包含“一把破吉他”、“旅人”,然后是男歌手。
    如果我想收藏该歌曲,请问小编如何为我找到目标歌曲、对应的歌手、专辑?

    为什么要讨论这个问题

    首先,搜索需求的实际场景实在太多了,可以说处处可见,比如:

    • 百度、Google输入关键字搜索信息;
    • 泛娱乐行业搜索对应的目标音视频文件;
    • 人脸识别、指纹验证、特定动作捕捉认证等。

    其次,物联网时代网络产生的数据信息浩如烟海,需要高效的搜索引擎技术帮助我们快速捕捉到相关度极高的匹配信息。

    所以,如果我们不做和业务应用场景格格不入的技术研究,那么我们不妨就多看看和业务比较契合的技术。

    然后这里讨论的技术问题与当今、未来的业务场景的联系都非常密切,相关技术问题的解决,也一定可以很好的推动应用的落地。

    基于DB的传统解决方案

    如果我们是一个使用过关系型数据库的同学,我们很容易就想到SQL模糊搜索。如:

    • 通过Btree实现的后模糊搜索
    select * from tab_aken where col like 'aken%';
    
    • 或者Btree反向索引实现的前模糊搜索
    select * from tab_aken where col like '%aken';
    

    但是,很多时候用户并不知道需要的前缀或后缀是什么,通常只记得其中的某些关键字或残缺的信息,然后查找最相似的目标。

    比如目击者只记得罪犯有部分特征:胡子、脸上刀疤、黑夹克、猥琐·········,然后根据关键字模糊查询锁定一定范围的嫌疑犯。

    于是,现实中更多的查询需求可能是下面这样的:

    • 前后模糊
    select * from tab_aken where col like '%aken%';
    
    • 多字段组合
    select * from tab_aken where a=? and b=? or c=? and d=? or e between ? and ? and f in (?);
    
    • 相似查询、向量距离
    select * from tab_aken order by similarity(col, 'aken') desc limit    100;
    

    此处省略N种查询场景··················

    那么问题来了,数据库通常并不具备上述前后模糊查询及其后的更多场景的高效检索能力。

    下面以MySQL为例,看一个反面案例。

    在32C-64G-SSD高端存储的设备上,这里运行了一个mysql-5.7.27,实例中有一个800w左右数据量的表:

    mysql> select count(*) from test.tab_test_txt;
    +----------+
    | count(*) |
    +----------+
    |  8814848 |
    +----------+
    1 row in set (3.46 sec)
    mysql> 
    mysql>select table_name,sum(truncate((data_length+index_length)/1024/1024/1024, 2)) data_GB,sum(truncate((data_length)/1024/1024/1024, 2)) tabsize_gb,sum(truncate((index_length)/1024/1024/1024, 2)) idxsize_gb from information_schema.tables where table_name
    +--------------+---------+------------+------------+
    | table_name   | data_GB | tabsize_gb | idxsize_gb |
    +--------------+---------+------------+------------+
    | tab_test_txt |    5.59 |       4.12 |       1.47 |
    +--------------+---------+------------+------------+
    1 row in set (0.00 sec)
    mysql>
    

    然后使用字段name做模糊查询,命中600w多数据,性能非常查,耗时11.14秒。

    mysql> SELECT name from test.tab_test_txt
    WHERE (NOT (`tab_test_txt`.`name` LIKE BINARY '%娴嬭瘯%' AND `tab_test_txt`.`name` IS NOT NULL) 
    AND NOT (`tab_test_txt`.`name` LIKE BINARY '%绂荤嚎%' AND `tab_test_txt`.`name` IS NOT NULL) 
    AND NOT (`tab_test_txt`.`name` LIKE BINARY '%寮€鍙戞満%' AND `tab_test_txt`.`name` IS NOT NULL)) ;
    +--------------------------------------+
    | name                                 |
    +--------------------------------------+
    | [N][QQ闊充箰]                        |
    | [N][鍏ㄦ皯K姝宂                      |
    | [newPC瀹㈡埛绔帴鍏[鐧婚檰蹇冭烦] |
    |            .............             |
    | [浼村淇℃伅閫昏緫server_涓婃捣]    |
    | [浼村淇℃伅閫昏緫server_娣卞湷]    |       
    +--------------------------------------+
    6578432 rows in set (11.14 sec)
    

    为了排除大结果的影响,我们再看看小结果的情况。来个最简单的查询:

    mysql> SELECT * from test.tab_test_txt  where name like '%鎼滅储娴嬭瘯妯%';
    Empty set, 1 warning (11.86 sec)
    mysql>
    

    可以看到,无匹配结果,或者单行记录,耗时11.86秒,和大量结果集的情况差别不大,因为都是全扫。

    mysql> insert into test.tab_test_txt(id,name) values(666666,'MYSQL全文检索测试');
    Query OK, 1 row affected, 0 warnings (0.59 sec)
    mysql> select count(*) from test.tab_test_txt  where id = 666666;
    +----------+
    |  count(*)   |
    +----------+
    |        1   |
    +----------+
    1 row in set (0.00 sec)
    mysql> SELECT * from test.tab_test_txt  where name like '%SQL全%';
    +--------+---------+--------+-----------+-------+------+-------+---------------------+---------------------+------------+----------------+----------------+--------------+--------+----------+--------------+------------+--------+--------+
    | id     | name    | owners | parent_id | busid | uid  | level | update_date         | create_date         | limit_load | children_count | limit_low_load | history_load | status | group_id | _alarm_types | star_level | remark | enable |
    +--------+---------+--------+-----------+-------+------+-------+---------------------+---------------------+------------+----------------+----------------+--------------+--------+----------+--------------+------------+--------+--------+
    | 666666 | MySQL全 | NULL   |      NULL |  NULL | NULL |  NULL | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |         65 |              0 |             30 | NULL         |      0 |    21576 | NULL         |          0 | NULL   |      1 |
    +--------+---------+--------+-----------+-------+------+-------+---------------------+---------------------+------------+----------------+----------------+--------------+--------+----------+--------------+------------+--------+--------+
    1 row in set (12.69 sec)
    mysql>
    

    而实际上,当今搜索需求越来越朝着社会化、实时化、情景化、移动化等趋势发展,会混入更多的关联关系、复合条件等因素,使得查询变更更加复杂化。

    比如考虑到社会化关系因素,上面的语句稍微升级就是一个多表关联的例子:

    SELECT `core_data`.`id` FROM `core_data` 
    INNER JOIN `core_extend` ON ( `core_data`.`ip` = `core_extend`.`ip` ) 
    INNER JOIN `core_business` ON ( `core_extend`.`business_id` = `core_business`.`busid` ) 
    WHERE (NOT (`core_business`.`name` LIKE BINARY '%娴嬭瘯%' AND `core_business`.`name` IS NOT NULL) 
           AND NOT (`core_business`.`name` LIKE BINARY '%绂荤嚎%' AND `core_business`.`name` IS NOT NULL) 
           AND NOT (`core_business`.`name` LIKE BINARY '%寮€鍙戞満%' AND `core_business`.`name` IS NOT NULL) 
           AND NOT (`core_extend`.`business_id` IN (789274, 879201, 1334489, ......,1121451, 1162547, 1168113, 1071955))
           AND `core_data`.`is_pushed` IS NULL 
           AND `core_data`.`update_date` > '2020-12-03 23:47:00');
    

    我们先不讨论上述语句的在写法上有没有优化空间,这是最近在生产环境中遇到的真实例子,命中了MySQL多表关联及文本检索的弱点。

    关于MySQL在文本检索方面的性能,可参见如下文章:《MySQL全文检索性能测试及问题总结》

    所以,如果应用中有全文检索的需求,直接在数据库运行类似的查询可能会是一个走不远的方案,数据量和性能稍微要求高一点就无法支持,也就不用谈什么海量实时高并发了。

    行业通用解决方案

    文本检索通常是搜索引擎的特长,因此目前行业内流行的通用方案是将数据同步到专业是搜索引擎系统以支持用户搜索需求,比如使用es集群。

    但该方案同时也引入了跨产品交互问题,因此会存在数据同步延迟及数据一致性问题,对于实时性、一致性要求高的场景还是有不少挑战。

    另外,在相似度检索、正则表达式、前后模糊查询方面,目前搜索引擎的在功能上并未完善。

    目前ES集群在静态文本检索的精确查询中能做到毫秒级,但对于上面这种既有多表关联又有文本搜索的需求场景,ES明显是解决不了,如果数据还会频繁变更,那么可能就要考虑融合其他方案了。

    那么,有没有一种搜索引擎方案可以高效的实现数据检索,又不失数据库固有的属性呢?

    难道就不能既可以高效实现文本检索,又可以高效处理事务处理、数据更改、关联查询、相似度匹配、复杂正则表达式?

    等等·······

    新方案的探索

    这里尝试探索一种基于DB搭建的搜索引擎方案,如果可以支持高效文本检索的情况下依然保持数据库固有的属性,那么不失为一种比较友好的替代方案,尤其是对于不想消耗额外的技术成本搭建专门搜索引擎的公司来说,这样还不需要多维护一个技术组件。

    这里涉及到分词切分算法、向量距离计算、模糊及正则等特性,PostgreSQL作为功能最为丰富的开源数据库产品,这些特性很早就已经具备。例如:

    • 分词切分
    akendb=# select to_tsvector('english', 'akengan-love-db,oracle mysql postgresql');
                                        to_tsvector                                   
    --------------------------------------------------------------------------------
     'akengan':2 'akengan-love-db':1 'db':4 'love':3 'mysql':6 'oracl':5 'postgresql':7
    (1 row)
    akendb=# 
    akendb=# select show_trgm('hello');
                show_trgm            
    ---------------------------------
     {"  h"," he",ell,hel,llo,"lo "}
    (1 row) akendb=#
    
    • 相似计算
    akendb=# SELECT smlar('{5,2,0}'::int[], '{5,2,8}');  --计算两个数组的相似度
       smlar   
    -----------
     0.6666667
    (1 row)
    akendb=# 
    akendb=# SELECT word_similarity('aken', 'akengan');   --计算两词的相似度
     word_similarity 
    -----------------
                 0.8
    (1 row)
    akendb=#
    
    • 正则匹配

    select * from tab_account where email ~ ‘1’; --查询以A-H开头的email地址
    所以,我们不妨可以看看PostgreSQL在全文检索方面的能力如何。

    • 创建测试表

    分区表,共64个分区,并行度64。

    akendb=# \d+ tab_aken_text
                               Unlogged table "public.tab_aken_text"
     Column |  Type   | Collation | Nullable | Default | Storage  | Stats target | Description 
    --------+---------+-----------+----------+---------+----------+--------------+-------------
     id     | integer |           | not null |         | plain    |              | 
     info   | text    |           |          |         | extended |              | 
    Indexes:
        "tab_aken_text_pkey" PRIMARY KEY, btree (id)
        "idx_tab_aken_text_info" gin (info gin_trgm_ops)
    Child tables: tab_aken_text0,
                  tab_aken_text1,
                  tab_aken_text10,
                  tab_aken_text11,
                  tab_aken_text12,
                  tab_aken_text13,
                  tab_aken_text14,
                  tab_aken_text15,
                  tab_aken_text16,
                  tab_aken_text17,
                  tab_aken_text18,
                  tab_aken_text19,
                  tab_aken_text2,
                  tab_aken_text20,
                  tab_aken_text21,
                  tab_aken_text22,
                  tab_aken_text23,
                  tab_aken_text24,
                  tab_aken_text25,
                  tab_aken_text26,
                  tab_aken_text27,
                  tab_aken_text28,
                  tab_aken_text29,
                  tab_aken_text3,
                  tab_aken_text30,
                  tab_aken_text31,
                  tab_aken_text32,
                  tab_aken_text33,
                  tab_aken_text34,
                  tab_aken_text35,
                  tab_aken_text36,
                  tab_aken_text37,
                  tab_aken_text38,
                  tab_aken_text39,
                  tab_aken_text4,
                  tab_aken_text40,
                  tab_aken_text41,
                  tab_aken_text42,
                  tab_aken_text43,
                  tab_aken_text44,
                  tab_aken_text45,
                  tab_aken_text46,
                  tab_aken_text47,
                  tab_aken_text48,
                  tab_aken_text49,
                  tab_aken_text5,
                  tab_aken_text50,
                  tab_aken_text51,
                  tab_aken_text52,
                  tab_aken_text53,
                  tab_aken_text54,
                  tab_aken_text55,
                  tab_aken_text56,
                  tab_aken_text57,
                  tab_aken_text58,
                  tab_aken_text59,
                  tab_aken_text6,
                  tab_aken_text60,
                  tab_aken_text61,
                  tab_aken_text62,
                  tab_aken_text63,
                  tab_aken_text7,
                  tab_aken_text8,
                  tab_aken_text9
    Access method: heap
    Options: parallel_workers=64
    akendb=#
    
    • 测试数据准

    为模拟海量数据场景,插入10亿随机64个字符的中文文本数据。

    akendb=# select count(*)  from tab_aken_text;
       count    
    ------------
     1000000000
    (1 row)
    akendb=# 
    akendb=# select * from tab_aken_text limit 3;
       id    |                                                                                               info                                                                                               
    ---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
     2799938 | 疑鬱咼韺鏂诪澍隴龌材忝兤詐瑶鑴咑鱊彦琌顬颊還謶螒暯矦愹絘瞴沬翘烇忷採賦炻紞礃鄽隢圞譪簘巅斻休荋稑棍魫亰臘壋園麗蹚鍋鴰滃艸谙躿遏湞
     2799939 | 癙砆劚蔾霙损戀鯯娵鶅璭褏鬴魟频灐覞鞁獶鷋瓚笹籼趟杸贽脇驝鎄俫唝倆餟簳騪聕籼殄濛郈鴚漝躮屳錿喞脛涔惿逈趴摜侾豈魷犵秅掾徍婵嬽敒禑廻
     2799940 | 劂螒萙絮婓媶賬誟慮揎鯼煣啡生孺瑀镁喚犢髕粬筗壣菅请枾勨毨轊挺缄烆貽挌啇夓齮輩髮鵺酏馣鮦揹酓痰苚殻瑺悋襖攏负埾凵穄挬鼿铹署脹呩聨錇
    (3 rows)
    akendb=#
    

    为方便测试,将其中id=10325230这一行的文本信息修改成目标信息:

    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试' where id =10325230;
    
    • 查询性能验证

    1.全文检索前后模糊查询

    可以看到,10亿级的数据量,模糊查询耗时只需要9.899 ms。

    akendb=# select  * from tab_aken_text where info like '%模糊匹配%';
        id    |                                                                                         info                                                                                         
    ----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
     10325230 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试
    (1 row)
    Time: 9.899 ms
    akendb=#
    

    2.文本检索相似度查询

    在10亿数据中准备10条目标测试数据

    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标' where id =2400002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标' where id =2500002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标' where id =2600002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标' where id =2200002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模百分九十目标' where id =2000002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模百分九十目标' where id =2700002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模百分九十目标' where id =2800002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配九十五' where id =2100002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配九十五' where id =2300002;
    update tab_aken_text6 set info ='搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配九十五' where id =2900002;
    

    在10亿数据中查询相似度超过50%的目标数据,耗时61.175 ms,CPU等资源消耗基本没观察到有什么消耗。

    akendb=# select set_limit(0.5); 
     set_limit 
    -----------
           0.5
    (1 row)
    Time: 0.283 ms
    akendb=#select similarity(info, '搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试') as sml, * 
    from tab_aken_text     
    where info % '搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试'    -- 相似度超过阈值    
    order by sml desc; 
        sml     |    id    |                                                                                         info                                                                                         
    ------------+----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
              1 | 10325230 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试
     0.77272725 |  2900002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配九十五
     0.77272725 |  2100002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配九十五
     0.77272725 |  2300002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配九十五
           0.68 |  2800002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模百分九十目标
           0.68 |  2000002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模百分九十目标
           0.68 |  2700002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模百分九十目标
     0.56666666 |  2200002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标
     0.56666666 |  2400002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标
     0.56666666 |  2500002 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索的百分八十百分八十测试目标
    (10 rows)
    Time: 61.175 ms
    akendb=#
    

    查询相似度超过90%的目标,精度要求越高,查询性能则会越快,如下在10亿数据的查询中耗时只需要29.020 ms。

    akendb=# select set_limit(0.9); 
     set_limit 
    -----------
           0.9
    (1 row)
    Time: 0.239 ms
    akendb=#select similarity(info, '搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试') as sml,* 
    from tab_aken_text     
    where info % '搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试'  
    order by sml desc limit 10; 
      
     sml |    id    |                                                                                         info                                                                                         
    -----+----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
       1 | 10325230 | 搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试搜索引擎全文检索模糊匹配的测试
    (1 row)
    Time: 29.020 ms
    akendb=#
    

    因此,使用PostgreSQL可以做到10亿级以上数据毫秒检索,其实在百亿级数据量的情况下,PostgreSQL文本检索的性能依然可以和10亿级别的性能不相上下,完全可以满足实时搜索引擎的需求,而且使用PostgreSQL一个好处是,各种功能还可以按需扩展。

    参考资料
    1.https://www.postgresql.org/docs/current/pgtrgm.html
    2.https://github.com/eulerto/pg_similarity

    更多精彩内容,请关注以下平台、网站:

    中国PostgreSQL分会官方公众号(技术文章、技术活动):
    开源软件联盟PostgreSQL分会

    中国PostgreSQL分会技术问答社区:
    www.pgfans.cn

    中国PostgreSQL分会官方网站:
    www.postgresqlchina.com


    1. A-H ↩︎

    展开全文
  • 有时候我们需要两个文件来记录已执行过和待执行的记录,这个时候我们需要找到已执行文件中**具有某种特征的**,以此来确定下一个执行任务。

    有时候我们需要两个文件来记录已执行过和待执行的记录,这个时候我们需要找到已执行文件中具有某种特征的行,以此来确定下一个执行任务,比如:
    已执行记录文件executed_records.txt文件内容
    在这里插入图片描述
    待执行记录文件execute_records.txt文件内容

    当匹配到的待执行任务m大于匹配到的已执行任务n时,即m>n时,执行下一个待执行任务,下一个待执行任务就是待执行任务中匹配到的第n+1条记录。下面测试以execute_records.txt文件为例。

    1. 打印匹配内容

    sed -n -e '/Server-01/p' execute_records.txt
    

    在这里插入图片描述

    2. 打印匹配内容行号

    sed -n -e '/Server-01/=' execute_records.txt
    

    在这里插入图片描述

    3. 打印出匹配的行号与内容

    sed -n ' /Server-01/{= ; p} ' execute_records.txt
    

    在这里插入图片描述

    4. 打印出匹配结果中的2-4行

    sed -n '/Server-01/p' execute_records.txt |sed -n 2,4p
    

    在这里插入图片描述

    5. 将文件中2到4行中匹配的数据显示出来

    sed -n '/Server-01/{2,4p}' execute_records.txt
    

    在这里插入图片描述

    6. 打印匹配行总数

    方式一:(不推荐)将输出结果存为数组,数组长度就是匹配行总数。

    array=(`sed -n -e '/Server-01/=' executed_records.txt`)
    echo ${#array[@]}
    

    在这里插入图片描述
    这里的6其实就是Server-01这台机器待执行任务记录为6,已执行记录同样可以通过查询得到,查询结果为4。
    这个时候6>4,下一任务就是匹配内容的第五条。利用第3中提到的命令sed -n '/Server-01/p' execute_records.txt |sed -n 4p找到第五条待执行任务的记录,截取任务文件名20200101.db.000005.sql,将该文件内容写入数据库,并记录该任务到已执行记录文件中。
    方式二:(推荐)用find结果wc -l来统计匹配的行数。

    find execute_records.txt -type f -exec grep -H "Server-01" {} \; | wc -l
    

    在这里插入图片描述

    -type f 表示搜索的是文件 (-type d 则是目录,具体man find)
    
    -exec <cmd> <args> {} \;   表示对找到的每一个文件名执行  <cmd> <args> ,
    
    注意 {} 会被find替换成找到的文件名, \; 是必须的,用来标记 -exec 的终结
    
    grep -H <Pattern> <FILE>
    
    在 <FILE> 中搜索 <Pattern>, -H 表示在每一个匹配行前打印出文件名
    
    wc -l <FILE> 
    
    统计 <FILE> 中的行数
    

    参考:https://zhidao.baidu.com/question/35794423.html

    展开全文
  • awk 打印匹配内容之后的指定

    千次阅读 2019-06-24 19:45:35
    1、awk 匹配文档的某内容,再打印某内容之前或者之后的指定 // 先取出某内容的行号,再基于此行号来打印某内容之前或者之后的指定 # cat awk.txt 1 aa 2 bb 3 cc 4 dd 5 ee 6 ff 7 gg // 匹配 "4 dd" ...

    1、awk 匹配文档的某行内容,再打印某行内容之前或者之后的指定行

    // 先取出某行内容的行号,再基于此行号来打印某行内容之前或者之后的指定行
    # cat awk.txt 
    1 aa
    2 bb
    3 cc
    4 dd
    5 ee
    6 ff
    7 gg
    // 匹配 "4 dd" 后,打印 "4 dd" 后的第 2 行
    # awk -v line=$(awk '/dd/{print NR}' awk.txt) '{if(NR==line+2){print $0}}' awk.txt
    6 ff
    // 匹配 "4 dd" 后,打印 "4 dd" 前的第 3 行
    # awk -v line=$(awk '/dd/{print NR}' awk.txt) '{if(NR==line-3){print $0}}' awk.txt
    1 aa
    展开全文
  • 基于相关性的模板匹配其实是另一种基于灰度值的匹配的方法,不过它的特点是使用一种归一化的互相关匹配(Normalized Cross Correlation,NCC)来衡量模板图像和检测图像之间的关系,因此,在光照方面受的影响比较小...
  • python,OpenCV模板匹配、图像识别整理
  • 基于组件的模板匹配可以说是基于形状的模板匹配的加强版,加强的地方在于,这种方法允许模板中包含多个目标,并且允许目标之间存在相对运动(位移和旋转)。这决定了这种方式不适用于尺寸缩放的情况。。由于有多个...
  • 图像处理(8) : 模板匹配

    千次阅读 多人点赞 2021-06-08 21:47:06
    ​模板匹配指的是通过模板图像与测试图像之间的比较,找到测试图像上与模板图像相似的部分,这是通过计算模板图像与测试图像中目标的相似度来实现的,可以快速地在测试图像中定位出预定义的目标。匹配的主要思路是...
  • 双目测距()--匹配算法对比

    万次阅读 2016-07-26 13:21:41
    参考:... 三种匹配算法比较 BM算法: 该算法代码: view plaincopy to clipboardprint? CvStereoBMState *BMState = cvCreateStereoBMState();  int SADWindowSize=15;  BMState-...
  • nginx匹配规则详解

    千次阅读 2022-02-17 15:39:57
    本文结合语法、优先级、匹配规则做描述。 二、location指令语法 location [=|~|~*|^~|@] /uri/ { … } 或 location @name { … } location 顺序/优先级: (location =) > (location 完整路
  • ElasticSearch (ES)学习之路()ES 复杂搜索( 匹配 过滤 精准 排序 高亮) 在上文中,我们查询小红 其kinbana 语法是这样写的 GET /lei/one/_search?q=name:小丽 前文中,也是做了分析,由于有多个包含‘小丽’...
  • 在利用正则表达式的解析过程中,我们经常会遇到多行字符输出的情形,例如执行执行dir命令,如输出如下结果:1 个文件 59,629,625 字节 ...方法一:跨解析对于跨解析,首先需要解决的问题是如何匹配符,在大部分
  • (head命令与tail命令) #显示前5个字节 head -c 5 head.txt # 只显示前五行 head -n 5 test.txt # 只显示末尾五行 tail -n 5 test.txt # 只显示第三行到末尾(不显示前两行) tail -n +3 test.txt # 只显示开头到...
  • 那篇java的文章是用"[keywd1]|[keywod2]|[keywd3]"的模式来匹配,这个在py中就不行了,[]会匹配[]中的任何一个分字。在python中的应该是"keywd1|keywd2|keywd3"就了。然后我个人是喜欢直接使用re.findall() 这样.....
  • OpenCV模板匹配(cv2.matchTemplate)

    万次阅读 多人点赞 2021-05-17 21:51:04
    它实现简单,只需要2-3代码 模板匹配计算效率高 不需要执行阈值化,边缘检测等操作即可生成二进制图像(例如轮廓检测和处理) 通过基本扩展,模板匹配可以检测输入图像中相同/相似对象的多个实例(我们将在下周...
  • 1、前两种都是属于模板匹配的方法,这些概念是在《数字图像处理高级应用》里的,其是移动匹配与向量匹配很像,只是移动匹配对灰度变换的鲁棒性不好。 这里说的移动匹配:就是把模板图像在原图像上进行移动,让后计算...
  • 如同两仪中蕴藏两仪的分法,五行中同样蕴藏五行,故而子系统同样可以进行五行的分类,金的大系统中藏着土的中系统,土的中系统中又藏着水的小系统,可以把这个过程看成递归,最后递归回到金的大系统中综合显现出来...
  • $grep -5 ‘parttern’ inputfile //打印匹配行的前后5 $grep -C 5 ‘parttern’ inputfile //打印匹配行的前后5 $grep -A 5 ‘parttern’ inputfile //打印匹配行的后5 $grep -B 5 ‘parttern’ inputfile //...
  • grep匹配上下几行的方法

    千次阅读 2020-11-19 16:01:43
    -A显示匹配后和它后面的n。(After,之后) -B显示匹配行和它前面的n。(Before,之前) -C匹配行和它前后各n。(Context,上下文) 例如 cat test.log |grep -B 1 zabbix 查看test.log文件中带zabbix关键字...
  • 正则匹配含有逗号的文章总数

    千次阅读 2018-10-18 21:38:19
    正则表达式的先行断言(lookahead)和后断言(lookbehind) OK到此可以匹配出来了。 但是还是发现了一处BUG,不能匹配一位数的文章, 因此第次更改:正则表达式:(?!of) \d+,?\d* (?=results) 这次...
  • 有勇气的牛排匹配数字+一个任意符号如1.2.3.类型(1-5位数以内)
  • awk匹配案例

    千次阅读 2018-09-10 08:57:59
    awk -F"... '/root/{print $1}' /etc/passwd 匹配root,并打印第一列 awk -F":" '$4==100 {print $0}' /etc/passwd 打印第四列等于100的 awk -F":" '$1 !~ /root/ {p...
  • 二分图完全匹配算法之匈牙利算法

    千次阅读 2022-01-30 17:57:25
    最近在参加了一个小项目,里面用到二分图匹配算法,因为之前并没有接触过相关算法,于是找到一些博客进行了一番学习,但学习之后,发现部分博客或多或少存在一些另我疑惑的地方,于是,我打算写此博客以巩固对算法的...
  • 如果该参数省略,则默认为近似匹配 TRUE 或近似匹配。 本示例中是“0”,为精确查找。 (本文是VLOOKUP使用的文字描述,VLOOKUP使用的视频讲解请点击:VLOOKUP函数使用方法详解 一、需基本查找 在G3单元格输入公式: ...
  • 本文介绍了连续图像和数字图像直方图匹配(直方图规定化)的原理、处理过程,并提供了案例进行了讲解。可以看到,直方图均衡处理是直方图匹配的一个重要桥梁。 最后,对于直方图规定化这个翻译个人觉得很low,个人...
  • 正则表达式位置匹配

    千次阅读 2019-09-01 17:42:09
    正则表达式是匹配模式,要么匹配字符,要么匹配位置。请记住这句话。 然而大部分人学习正则时,对于匹配位置的重视程度没有那么高。 本章讲讲正则匹配位置的总总。 内容包括: 什么是位置? 如何匹配位置? ...
  • 基于opencv的核线影像匹配(数字摄影测量)
  • KMP模式匹配算法详解

    万次阅读 多人点赞 2020-02-23 15:48:40
    KMP算法的核心是利用匹配失败后的信息,尽量减少模式串与主串的匹配次数以达到快速匹配的目的。具体实现就是通过一个next()函数实现,函数本身包含了模式串的局部匹配信息。KMP算法的时间复杂度O(m+n)...
  • MSSQL之 连接查询与子查询

    千次阅读 2016-05-16 19:06:28
    你可以使用子查询,这里一个查询的结果被用作另一个查询的条件的输入。 本章讨论如何通过应用各种类型的连接,例如内连接,外连接,交叉连接,等值连接或自连接,来从夺标中查询数据。进一步,它解释如何使用子查询
  • 图像匹配几种常见算法与实践

    万次阅读 多人点赞 2020-08-07 19:05:18
    奇技 · 指南本文主要内容1.模版匹配2.特征匹配3.深度学习去找目标图像匹配的应用及背景图像匹配是指通过一定的匹配算法在两幅或多幅图像之间识别同名点。应用:遥感(制图更新),计算机视觉...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 267,456
精华内容 106,982
关键字:

五行匹配查询