elasticsearch初识

一、产生背景

1、大规模数据：当系统数据量上了10亿、100亿条的时候，在做系统架构的时候通常会考虑一些问题

①数据库的选择：mysql、oracle、mongodb、hbase等

②单点故障的解决：lvs、F5、A10、Zookeeper、MQ等

③保证数据安全性：热备、冷备、异地多活

④检索难题：数据库代理中间件，mysql-proxy、Cobar、MaxScale等

⑤统计分析：离线、近实时

2、传统关系型数据库的应对方案

①通过主从备份解决数据安全性问题

②通过数据库代理中间件心跳监测，解决单点故障问题

③通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果

3、非关系型数据库解决方案

①以mongodb为例

②通过副本备份保证数据安全性

③通过节点竞选机制解决单点问题

④先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果

4、内存数据库解决方案

①完全把数据放在内存中是不可靠的，实际上也不太现实，当数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，需要的机器是，1PB=1024T=1048576G，节点数=1048576/96=10922个，实际上，考虑到数据备份，节点数往往在2.5万台左右，成本巨大决定了其不现实

②所以把数据放在内存也好，不放在内存也好，都不能完完全全解决问题，全部放在内存速度问题是解决了，但成本问题上来了

5、结论：为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法，存储数据时按有序存储 => 将数据和索引分离 => 压缩数据，这就引出了Elasticsearch

二、简介

1、Elasticsearch 是一个基于Lucene的分布式搜索和分析引擎

①Elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据

②Elasticsearch使用Java开发，在Apache许可条款下开放源码发布，是当前流行的企业级搜索引擎，设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便

③使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，使得全文检索变得简单

④设计理念即是用于分布式全文检索，通过HTTP使用JSON进行数据索引，速度快

2、Lucene与Elasticsearch关系

①Lucene只是一个库，想要使用它，必须使用Java来作为开发语言并将其直接集成到应用中，更糟糕的是，Lucene非常复杂，需要深入了解检索的相关知识来理解它是如何工作的

②Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单

3、Elasticsearch vs solr

①Solr是Apache Lucene项目的开源企业搜索平台，其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理

②Solr是高度可扩展的，并提供了分布式搜索和索引复制，Solr是最流行的企业级搜索引擎，Solr4 还增加了NoSQL支持

③Solr是用Java编写、运行在Servlet容器（如 Apache Tomcat 或Jetty）的一个独立的全文搜索服务器，Solr采用了 Lucene Java 搜索库为核心的全文索引和搜索，并具有类似REST的HTTP/XML和JSON的API

④Solr强大的外部配置功能使得无需进行Java编码，便可对 其进行调整以适应多种类型的应用程序，Solr有一个插件架构，以支持更多的高级定制

⑤Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能

⑥Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式

⑦Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供

⑧Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch

⑨Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用

三、核心概念

1、集群(Cluster)：ES可以作为一个独立的单个搜索服务器，不过，为了处理大型数据集，实现容错和高可用性，ES可以运行在许多互相合作的服务器上，这些服务器的集合称为集群

2、节点(Node)：形成集群的每个服务器称为节点

3、分片(Shard)：当有大量的文档时，由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等，一个节点可能不够，这种情况下，数据可以分为较小的分片，每个分片放到不同的服务器上，当查询的索引分布在多个分片上时，ES会把查询发送给每个相关的分片，并将结果组合在一起，而应用程序并不知道分片的存在，即这个过程对用户来说是透明的

4、副本(Replia)：为提高查询吞吐量或实现高可用性，可以使用分片副本，副本是一个分片的精确复制，每个分片可以有零个或多个副本，ES中可以有许多相同的分片，其中之一被选择更改索引操作，这种特殊的分片称为主分片，当主分片丢失时，如，该分片所在的数据不可用时，集群将副本提升为新的主分片

5、全文检索：全文检索就是对一篇文章进行索引，可以根据关键字搜索，类似于mysql里的like语句，全文索引就是把内容根据词的意义进行分词，然后分别创建索引，例如”今日是周日我们出去玩” 可能会被分词成，“今天“，”周日“，“我们“，”出去玩“ 等token，这样当搜索“周日” 或者 “出去玩” 都会把这句搜出来

四、与关系型数据库Mysql对比

1、关系型数据库中的数据库（DataBase），等价于ES中的索引（Index）

2、一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type）

3、一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成

4、在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。 与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等

5、在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改Update、查GET

五、ES逻辑设计（文档-->类型-->索引）

1、一个索引类型中，包含多个文档，比如说文档1，文档2，当索引一篇文档时，可以通过这样的顺序找到它，索引▷类型▷文档ID，通过这个组合就能索引到某个具体的文档，注意，ID不必是整数，实际上它是个字符串

2、文档：之前说elasticsearch是面向文档的，那么就意味着索引和搜索数据的最小单位是文档，elasticsearch中，文档有几个重要属性

①自我包含，一篇文档同时包含字段和对应的值，也就是同时包含key:value

②可以是层次型的，一个文档中包含自文档，复杂的逻辑实体就是这么来的

③灵活的结构，文档不依赖预先定义的模式，我们知道关系型数据库中，要提前定义字段才能使用，在elasticsearch中，对于字段是非常灵活的，有时候，我们可以忽略该字段，或者动态的添加一个新的字段

④文档是无模式的，也就是说，字段对应值的类型可以是不限类型的

⑤尽管我们可以随意的新增或者忽略某个字段，但是，每个字段的类型非常重要，比如一个年龄字段类型，可以是字符串也可以是整型，因为elasticsearch会保存字段和类型之间的映射及其他的设置，这种映射具体到每个映射的每种类型，这也是为什么在elasticsearch中，类型有时候也称为映射类型

3、类型

①类型是文档的逻辑容器，就像关系型数据库一样，表格是行的容器

②类型中对于字段的定义称为映射，比如name映射为字符串类型

③文档是无模式的，它们不需要拥有映射中所定义的所有字段，比如新增一个字段，elasticsearch会自动的将新字段加入映射，但是这个字段的不确定它是什么类型，elasticsearch就开始猜，如果这个值是18，那么elasticsearch会认为它是整型

④但是elasticsearch也可能猜不对，所以最安全的方式就是提前定义好所需要的映射，这点跟关系型数据库殊途同归了，先定义好字段，然后再使用

4、索引：索引是映射类型的容器，elasticsearch中的索引是一个非常大的文档集合，索引存储了映射类型的字段和其他设置，然后它们被存储到了各个分片上了

六、ES物理设计

1、一个集群包含至少一个节点，而一个节点就是一个elasticsearch进程，节点内可以有多个索引

2、默认的，如果创建一个索引，那么这个索引将会有5个分片（primary shard，又称主分片）构成，而每个分片又有一个副本（replica shard，又称复制分片），这样，就有了10个分片

3、图中有3个节点的集群，可以看到主分片和对应的复制分片都不会在同一个节点内，这样有利于某个节点挂掉了，数据也不至于丢失，实际上，一个分片是一个Lucene索引，一个包含倒排索引的文件目录，倒排索引的结构使得elasticsearch在不扫描全部文档的情况下，就能告诉你哪些文档包含特定的关键字

七、ELK

1、ELK=elasticsearch+Logstash+kibana

2、elasticsearch：后台分布式存储以及全文检索

3、logstash: 日志加工、“搬运工”

4、kibana：数据可视化展示

5、ELK架构为数据分布式存储、可视化查询和日志解析创建了一个功能强大的管理链，三者相互配合，取长补短，共同完成分布式大数据处理工作

八、Elasticsearch特点和优势

1、分布式实时文件存储，可将每一个字段存入索引，使其可以被检索到

2、实时分析的分布式搜索引擎，分布式，索引分拆成多个分片，每个分片可有零个或多个副本，集群中的每个数据节点都可承载一个或多个分片，并且协调和处理各种操作，负载再平衡和路由在大多数情况下自动完成

3、可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据，也可以运行在单台PC上

4、支持插件机制，分词插件、同步插件、Hadoop插件、可视化插件等

九、Elasticsearch业务场景

1、2013年初，GitHub抛弃了Solr，采取ElasticSearch 来做PB级的搜索，“GitHub使用ElasticSearch搜索20TB的数据，包括13亿文件和1300亿行代码”

2、维基百科：启动以elasticsearch为基础的核心搜索架构

3、SoundCloud：“SoundCloud使用ElasticSearch为1.8亿用户提供即时而精准的音乐搜索服务”

4、百度：百度目前广泛使用ElasticSearch作为文本数据分析，采集百度所有服务器上的各类指标数据及用户自定义数据，通过对各种数据进行多维分析展示，辅助定位分析实例异常或业务层面异常，目前覆盖百度内部20多个业务线（包括casio、云分析、网盟、预测、文库、直达号、钱包、风控等），单集群最大100台机器，200个ES节点，每天导入30TB+数据

5、新浪ES 如何分析处理32亿条实时日志

6、阿里ES 构建挖财自己的日志采集和分析体系

7、有赞ES 业务日志处理

8、实际项目开发实战中，几乎每个系统都会有一个搜索的功能，当搜索做到一定程度时，维护和扩展起来难度就会慢慢变大，所以很多公司都会把搜索单独独立出一个模块，用ElasticSearch等来实现

9、近年ElasticSearch发展迅猛，已经超越了其最初的纯搜索引擎的角色，现在已经增加了数据聚合分析（aggregation）和可视化的特性，如果你有数百万的文档需要通过关键词进行定位时，ElasticSearch肯定是最佳选择，当然，如果你的文档是JSON的，你也可以把ElasticSearch当作一种“NoSQL数据库”， 应用ElasticSearch数据聚合分析（aggregation）的特性，针对数据进行多维度的分析

10、尝试使用ES来替代传统的NoSQL，它的横向扩展机制太方便了，新系统开发可以尝试使用ES作为存储和检索服务器，现有系统升级需要支持全文检索服务，可以使用ES

十、Elasticsearch索引到底能处理多大数据

1、单一索引的极限取决于存储索引的硬件、索引的设计、如何处理数据以及为索引备份了多少副本

2、通常来说，一个Lucene索引（也就是一个elasticsearch分片，一个es索引默认5个分片）不能处理多于21亿篇文档，或者多于2740亿的唯一词条，但达到这个极限之前，我们可能就没有足够的磁盘空间了

3、当然，一个分片如何很大的话，读写性能将会变得非常差