我对搜索的理解

在2年前我并不知道搜索是怎么做的,感觉搜索特别深奥,离我遥不可及,例如为
么在搜索框中输入你想要的概念就可以立马响应到你想要的大致内容,但有时搜索出来
的东西确并不是你你想要的东西,这时,你就应该提取你的搜索关键词,重新设置,然
后再次尝试,反复尝试...直到找到你想要的内容,都是也有一种情况,你想要的内容或
许一直出现不了...
首先我想从elasticsearch开始说起,这个东西第一次接触是因为公司的业务拓展,数
据量的暴增,使得mysql数据库的join关联反应速度变的非常缓慢,这个时候,我们通过
中间件canal来同步数据到elasticsearch中,然后在elasticsearch中查询出我们需要的内
容,这里我说的是查询,而当时的我对于查询与搜索的概念是这样理解的,查询好像是
精确匹配,而搜索呢是模糊匹配,刚开始因为是从mysql数据库中迁移过来,因此很多的
业务都是精确匹配,用到的也仅仅是es中的term,range等语法就够用了,至多再加上
wildard模糊匹配就可以(前提是对存储的数据没有进行分词,当然当时的我对什么是分
词也是不清楚的,只是将其当成是与mysql中的like的用法),后来来了一个需求是这样
的:es中的存储的docment中有个name的field,例如Lilong,而我要是输入lilong,那么也
需要出来,刚看不是很简单么,只是将存储的字段利用一个函数将其都转化为全部小写的子串,然后再将输入的字段通过lowcase转化为小写然后进行匹配不就行了,这里注意到需要es本身提供一种函数转化为小写的就可以了(当时我觉得应该有,因为mysql有,
我将es当成数据库了),查找了一些资料后发现并没有找到,这个时候我就想着,算
了,直接在数据入es的时候进行转化进好了(其实这样是不行的,因为需求展现的时候
需要按照Lilong来展现,而不是lilong),然后想着多做一个字段吧(刚开始的认知),这
样就可以解决问题了,但是我非常的排斥用这样方式解决,因为我需要通过代码来维护2
个字段的数据,这样对于后期的维护无形中就加大的成本,或许是因为执着吧,并且我
不想影响功能的正常上线,因此我在周末的时候翻阅了1天的es官方文档,终于让我找到了分析器,当时我的心情是很激动的
什么是分析器呢,分析器是有分词器,过滤器和字符映射器组成的

  • 分词器:将文本分割成词项,记录下词项的位置与长度
  • 过滤器:小写过滤器,ASCII过滤器,同义词过来器,词干过滤器等
  • 字符映射器: 字符预操作,去html标签等等
    我只要定义 "caseSensitive": {
    "filter": "lowercase",
    "type": "custom",
    "tokenizer": "keyword"
    }就可以解决问题,
    后来又来了需求:存储的数据为李小龙,输入李龙可以出来,这样的话我就开始研究跨度查询,然后是分词也就是人们常说的倒排索引的原理,常见的分词器,为什么倒排搜索响应速度比mysql的响应速度快(关键是使用了二分法),我也逐渐明白换个角度思考问题有时候可以很好的解决问题,例如,在提升反应速度的时候,要是我们一直在思考如何的实现一个好的算法来实现问题,到不如可以想着在存储数据的时候就开始做文章,怎么算呢,我觉得计算有时与存储根本就是分不开的,你要是想实现一个好的算法,那么你就应该需要首先将你的数据存储的一个你想要的地方,或者是你觉得很好的
    格式存储,像要是mapreduce要是没有HDFS的支撑我觉得也是不行的,这样的话,算法与数据结构其实也根本就是分不开的,要是算法离开了数据结构,就好像是鱼儿离开了水,同样的,光有数据结构没有合适的算法,那么存储的数据将没法提取,这个问题讨论偏了,弯回来再讨论一下搜索的事情
    上面提到了分词的一些东西,我自认为我对es的知识点理解的很多了,对于搜索了解的也可以了,从es的一些基本知识点,到es的集群理论,再到项目中遇到的一些坑(例如要是输入的子串特别长,将导致es反应速度变的非常缓慢,cpu立刻飙升等等)
    然而事实的情况并不是这样的,我了解的只是明确用户的搜索关键字,然后在一个大型的数据仓库中进行匹配,然后给用户返回相似度很高的条目,但是前期的一些用户意图之类的东西我并不知道,或者这个才是搜索的核心;举个例子:用户输入 附近的酒店;要是你将这哥字段进行分词,去掉停词的,然后是附近,酒店,然后在数据仓库中匹配这2个词,我觉得匹配出来的效果并不是我想要的,正确的结果应该是我需要离我较近的酒店,做法应该是我在数据库中搜索酒店然后再按照离我的距离进行由近到远的排序,输出的结果才是我想要的,到了这个时候,我研究发现这些关于用户意图识别的东西尽然是人工智能方面的东西,我非常开心,可能是因为人工智能比较火的原因吧,不管怎么样,我就是想知道这些东西怎么弄,或许是好奇吧,我开始研究人工智能的东西,刚开始研究时,发现需要很多微积分与数理统计方面的知识,我很开心,我认为终于可以用到自己以前学习的一些东西了(曾经数学那可是我的强项)
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,864评论 6 494
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,175评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,401评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,170评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,276评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,364评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,401评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,179评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,604评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,902评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,070评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,751评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,380评论 3 319
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,077评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,312评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,924评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,957评论 2 351