Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单,它不仅包括了全文搜索功能,还可以进行以下工作:
正排索引: 正排索引是指文档ID为key,表中记录每个关键词出现的次数,查找时扫描表中的每个文档中字的信息,直到找到所有包含查询关键字的文档。 正排是以 docid 作为索引的,但是在搜索的时候我们基本上都是用关键词来搜索。所以,试想一下,我们搜一个关键字(Tom),当100个网页的10个网页含有Tom这个关键字。但是由于是正排是doc id 作为索引的,所以我们不得不把100个网页都扫描一遍,然后找出其中含有Tom的10个网页。然后再进行rank,sort等。效率就比较低了。尤其当现在网络上的网页数已经远远超过亿这个数量后,这种方式现在并不适合作为搜索的依赖。 不过与之相比的是,正排这种模式容易维护。由于是采用doc 作为key来存储的,所以新增网页的时候,只要在末尾新增一个key,然后把词、词出现的频率和位置信息分析完成后就可以使用了。 所有正排的优点是:易维护;缺点是搜索的耗时太长; 倒排索引: 由于正排的耗时太长缺点,倒排就正好相反,是以word作为关键索引。表中关键字所对应的记录表项记录了出现这个字或词的所有文档,一个表项就是一个字表段,它记录该文档的ID和字符在该文档中出现的位置情况。 倒排包含两部分: 1、由不同的索引词(index term)组成的索引表,称为“词典”(lexicon)。其中包含了各种词汇,以及这些词汇的统计信息(如出现频率nDocs),这些统计信息可以直接用于各种排名算法。 2、由每个索引词出现过的文档集合,以及命中位置等信息构成。也称为“记录表”。就是正排索引产生的那张表。当然这部分可以没有。具体看自己的业务需求了。 倒排的优缺点和正排的优缺点整好相反。倒排在构建索引的时候较为耗时且维护成本较高,但是搜索耗时短。 我们借助单词——文档矩阵模型, 通过这个模型我们可以很方便知道某篇文档包含哪些关键词,某个关键词被哪些文档所包含。 单词-文档矩阵的具体数据结构可以是倒排索引、签名文件、后缀树等。 倒排索引源于实际应用中需要根据属性的值来查找记录,lucene是基于倒排索引实现的。 这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。 由于不是由记录来确定属性值,而是由属性值来确定记录的位置,因而称为倒排索引(inverted index)。 带有倒排索引的文件我们称为倒排索引文件,简称倒排文件(inverted file)。 倒排索引一般表示为一个关键词,然后是它的频度(出现的次数),位置(出现在哪一篇文章或网页中,及有关的日期,作者等信息),它相当于为互联网上几千亿页网页做了一个索引,好比一本书的目录、标签一般。读者想看哪一个主题相关的章节,直接根据目录即可找到相关的页面。不必再从书的第一页到最后一页,一页一页的查找。 倒排索引由两个部分组成:单词词典和倒排文件。
ElasticSearch已经可以与YARN、Hadoop、Hive、Pig、Spark、Flume等大数据技术框架整合起来使用,尤其是在添加数据的时候,可以使用分布式任务来添加索引数据,尤其是在数据平台上,很多数据存储在Hive中,使用Hive操作ElasticSearch中的数据,将极大的方便开发人员。
在传统的数据库里面,对数据关系描述无外乎三种,一对一,一对多和多对多的关系,如果有关联关系的数据,通常我们在建表的时候会添加主外键来建立数据联系,然后在查询或者统计时候通过join来还原或者补全数据,最终得到我们需要的结果数据,那么转化到ElasticSearch里面,如何或者怎样来处理这些带有关系的数据。 ElasticSearch是一个NoSQL类型的数据库,本身是弱化了对关系的处理,因为像lucene,es,solr这样的全文检索框架对性能要求都是比较高的,一旦出现join这样的操作,性能会非常差,所以在使用搜索框架时,我们应该避免把搜索引擎当做关系型数据库用。