当数据多时效率非常低
全文检索 是指计算机索引程序通过扫描文章中的每一个词,对每一个词建立一个索引,指明该词在文章中出现的次数和位置,当用户查询时,检索程序就根据事先建立的索引进行查找,并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。全文检索搜索引擎数据库中的数据
总结: 数据库里的数据,一共 100 万条,按照之前的思路,其实就要扫描 100 万次,而且每次扫描,都需要匹配那个文本所有的字符,确认是否包含搜索的关键词,而且还不能将搜索词拆解开来进行检索
Lucene 就是一个 jar 包,里面包含了封装好的各种建立倒排索引,以及进行搜索的代码,包括各种算法。我们使用 Java 开发的时候,引入 lucene.jar,然后基于 lucene 的 api 去进行开发就可以了
ElasticSearch,简称 ES,ES 是一个开源的高扩展的分布式全文检索引擎,它可以近乎实时的存储、检索数据;本身扩展性很好,可以扩展到上百台服务器,处理 PB 级别的数据。ES 也使用 Java 开发并使用 Lucene 作为其核心来实现所有索引和搜索功能,但是它的目的是通过简单的 RESTful 来隐藏 Lucene 的复杂性,从而让全文搜索变得简单
ElasticSearch 是一个实时分布式搜索和分析引擎,它用于全文搜索、结构化搜索、分析
全文检索,将非结构化数据中的一部分信息提取出来,重新组织,使其变得有一定结构,然后对此有一定结构的数据进行搜索,从而达到搜索相对较快的目的
ElasticSearch 是面向文档(document oriented)的,这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储,还会索引(index)每个文档的内容使之可以被搜索,在 ElasticSearch 中,你可以对文档(而非成行成列的数据)进行索引、搜索、排序、过滤。ElasticSearch 对比传统关系型的数据库如下:
Relational DB -> Databases -> Tables -> Rows -> Columns
ElasticSearch -> Indices -> Types -> Documents -> Fields
索引包含一堆有相似结构的文档数据,比如可以有一个客户索引,商品分类索引,订单索引,索引有一个名称,一个 index 包含很多 document,一个 index 就代表了一个类似的或者相同的 document。比如说建立一个 product index,商品索引,里面可能就存放了所以的商品数据,所有的商品 document
在一个索引中,你可以定义一种或多种类型,一个类型是你的索引的一个逻辑上的分类 / 分区,其语义完全由你来定义。通常,会为具有一组共同字段的文档定义一个类型。比如说,我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中,你可以为用户数据定义一个类型,为博客数据定义另一个类型,当然,也可以为评论数据定义另一个类型
相当于是数据表字段,对文档数据根据不同属性进行的分类标识
Mapping 是处理数据的方式和规则方面做一些限制,如某个字段的数据类型、默认值、分析器、是否被索引等等,这些都是映射里面可以设置的,其它就是处理 ElasticSearch 里面数据的一些使用规则设置也叫做映射,按着最优规则处理数据对性能提高很大,因此才需要建立映射,并且需要思考如何建立映射才能对性能更好
一个文档是一个可被索引的基础信息单元。比如,你可以拥有某一个客户的文档,某一个产品的一个文档,当然,也可以拥有某个订单的文档,文档以 JSON 格式来表示,而 JSON 是一个到处存在互联网数据交互格式
在一个 Index / Type 里面,你可以存储任意多的文档。注意,尽管一个文档,物理上存在于一个索引之中,文档必须被索引 / 赋予一个索引的 Type
近实时,两个意思,从写入数据到数据可以被搜索到一个小延迟(大概 1 s);基于 ES 执行搜索和分析可以达到秒级
集群包含多个节点,每个节点属于哪个集群是通过一个配置(集群名称,默认是 elasticsearch)来决定的,对于中小型应用来说,刚开始一个集群就一个节点很正常
集群中的一个节点,节点也有一个名称(默认是随机分配的),节点名称很重要(在执行运维管理操作的时候),默认节点会加入一个名称为 “elasticsearch” 的集群,如果直接启动一堆节点,那么它们会自动组成一个 elasticsearch 集群,当然一个节点也可以组成一个 elasticsearch 集群
一个索引可以存储超出单个节点硬件限制的大量数据。比如,一个具有 10 亿文档的索引占据 1 TB 的磁盘空间,而任一节点都没有这样大的磁盘空间;或者单个节点处理搜索请求,响应太慢。为了解决这个问题,ElasticSearch 提供了将索引划分成多份的能力,这些份就叫做 分片。当你创建一个索引的时候,你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的 “索引”,这个 “索引” 可以被放置到集群中的任何节点上。分片很重要,主要有两方面的原因:
至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由 ElasticSearch 管理的,对于作为用户请求的你来说,这些都是透明的
在一个网络 / 云的环境里,失败随时都可能发生,在某个分片 / 节点不知怎么的就处于离线状态,或者由于任何原因消失了,这种情况下,有一个故障转移机制是非常有用并且是最强烈推荐的。为此目的,ElasticSearch 允许你创建分片的一份或多份拷贝,这些拷贝叫做复制分片,或者直接叫做复制
复制之所以重要,有两个主要原因:在分片 / 节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与原 / 主要(original / primary)分片置于同一节点上是非常重要的,扩展你的搜索量 / 吞吐量,因为搜索可以在所有的复制上并行运行。总之,每个索引可以被分成多个分片,一个索引也可以被复制 0 次(意思是没有复制)或多次,一旦复制了,每个索引就有了主分片(作为复制源的原来的分片)和复制分片(主分片的拷贝)之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后,你可以在任何时候动态地改变复制的数量,但是你事后不能改变分片的数量
默认情况下,ElasticSearch 中的每个索引被分片成 5 个主分片和 1 个复制,这意味着,如果你的集群中至少有两个节点,你的索引将会有 5 个主分片和另外 5 个复制分片(1 个完全拷贝),这样的话每个索引总共有 10 个分片