ElasticSearch第1天 了解ElasticSearch
今日目标
简单了解ElasticSearch的核心概念，历史
1.ElasticSearch是什么，做什么的
ElasticSearch（简称ES）是一个基于Lucene的搜索服务器，是一个 【开源】 的，【高扩展】 的 分布式搜索引擎，可以用于搜索！是排名第一的搜索引擎类应用，可以近乎实时的存储，检索数据。
2.ElasticSearch和Lucene的关系
Lucene是最先进、功能最强大的搜索库，但如果直接基于lucene开发，api非常复杂，实现一些简单的功能，也需要在深入理解原理（各种索引结构）的基础上写大量的java代码，ElasticSearch基于Lucene进行了封装，隐藏复杂性，提供了简单易用的restful api接口，提供了对多种语言的支持，开箱即用。
关于ElasticSearch的一个传说，有一个程序员失业了，陪着自己老婆去英国伦敦学习厨师课程。程序员在失业期间想给老婆写一个菜谱搜索引擎，觉得Lucene实在太复杂了，就开发了一个封装了Lucene的开源项目，compass。后来程序员找到了工作，是做分布式的高性能项目的，觉得compass不够，就写了ElasticSearch，让Lucene变成分布式的系统。
3.使用场景
1、检索。ES本身作为一个搜索引擎，用来处理检索的任务再合适不过。你可以在线上项目中直接将内容写入ES以提供检索服务，也可以把以往的数据导入ES以处理特定的需求。
2、统计。ES的统计也是基于检索功能的，聚合功能使得统计结果处理起来非常方便。如果你只需要统计而不用检索，可能有其他工具更适合你，比如Spark SQL。
3、其他的诸如文档存错查询，日志存储和索引，监控基础信息、应用程序性能和使用情况，地理数据存储和分析。
总之就是可以对静态数据进行存储搜索，对动态数据（时间序列数据）进行产品分析、报告、异常检测 ……
4.为什么不用mysql做全文搜索
mysql做全文检索的话，查询速度会非常的慢，比如 %xxx% 所以在大数据量的情况下，用ES可以以前所未有的速度进行检索。
5.为什么Elasticsearch不适合做数据存储？
ES同时还是一个文档数据库，但并不能完全代替数据库，因为ES的核心是检索，没有用户验证和权限控制，无法多对多，MYSQL支持事务和访问权限控制，ES不支持事务和访问权限控制，虽然ElasticSearch 比 MySQL 更适合复杂条件查询，但是有好就有弊，ES为了查询做很多的准备工作，插入速度就会慢于 MySQL，而且数据存入ES后并不是立马就能检索到（可以配置，但会非常影响性能），所以在存储时使用mysql，而在搜索，统计时使用ES时一个非常棒的选择。
6.关于ES和Solr的比较，同类产品，如何选择
Elasticsearch 的竞争对手只有一个，Apache Solr，有着和 Elasticsearch 相似的特性，但 Solr 的发展势头远不及 Elasticsearch。Solr学习成本相对较高，但功能更丰富，生态更好，如果你已经在使用solr了，请继续使用它，因为迁移到Elasticsearch并不会带来具体的优势。如果你刚开始使用全文索引，推荐ES，Elasticsearch由于其易用性而在较新的开发人员中更受欢迎。
7.PHP开发者如何使用ElasticSearch？其他语言如何使用
和Redis的使用一样，php也提供了对应的扩展包，Elasticsearch-PHP是PHP连接Elasticsearch库的扩展，是用PHP语言开发的，类似于PHP通过Predis操作redis库的功能。可以通过composer或者github下载，集成到现有的php项目中，实现对ES的使用。
8.ElasticSearch 是不是可以替换mysql了呢
完全替代肯定不行，脱离业务场景谈技术选型都是瞎扯。es和mysql两者都能解决一部分问题，能力也有交集。而各自都有独特能力的一面，不能空谈取代。难易程度来说，Mysql学习成本要比ES低的多，ES的技术栈主要也是ELK（ELK技术，elasticsearch+logstash+kibana）。所以其具体用途可以有以下几个：用户行为日志（点击，浏览，收藏，评论）等的分析；电商网站检索商品；日志数据分析（logstash采集日志，ES进行复杂的数据分析，kibana展示）
9.ElasticSearch 中的重要术语
- NRT Near RealTime(NRT) 近实时
elasticsearch是一个近似实时的搜索平台,近实时有两种意思，一种是从索引文档到可搜索也就是从写入数据到可以被搜索到有一个小延迟（通常为1秒），还有一种就是基于ElasticSearch 进行搜索和分析可以达到秒级,实时又分为准实时和近实时，准实时是毫秒级，近实时是秒级, - 集群 Cluster
集群就是一个或多个节点存储数据，其中一个节点为主节点，这个主节点是可以通过选举产生的，并提供跨节点的联合索引和搜索的功能。集群有一个唯一性标示的名字，默认是elasticsearch，集群名字很重要，每个节点是基于集群名字加入到其集群中的。因此，确保在不同环境中使用不同的集群名字。一个集群可以只有一个节点。强烈建议在配置elasticsearch时，配置成集群模式。 - 节点 Node
节点就是一台单一的服务器，是集群的一部分，存储数据并参与集群的索引和搜索功能。像集群一样，节点也是通过名字来标识，默认是在节点启动时随机分配的字符名。当然啦，你可以自己定义。该名字也蛮重要的，在集群中用于识别服务器对应的节点。
节点可以通过指定集群名字来加入到集群中。默认情况下，每个节点被设置成加入到elasticsearch集群。如果启动了多个节点，假设能自动发现对方，他们将会自动组建一个名为elasticsearch的集群。 - 索引 Index
索引是有几分相似属性的一系列文档的集合。如nginx日志索引、syslog索引等等。索引是由名字标识，名字必须全部小写。这个名字用来进行索引、搜索、更新和删除文档的操作。
索引相对于关系型数据库的库。 - 类型 Type
在一个索引中，可以定义一个或多个类型。类型是一个逻辑类别还是分区完全取决于你。通常情况下，一个类型被定于成具有一组共同字段的文档。如ttlsa运维生成时间所有的数据存入在一个单一的名为logstash-ttlsa的索引中，同时，定义了用户数据类型，帖子数据类型和评论类型。
类型相对于关系型数据库的表。
*文档 Document
文档是信息的基本单元，可以被索引的。文档是以JSON格式表现的。
在类型中，可以根据需求存储多个文档。
虽然一个文档在物理上位于一个索引，实际上一个文档必须在一个索引内被索引和分配一个类型。
文档相对于关系型数据库的列。 - 分片和副本 shards & replica
在实际情况下，索引存储的数据可能超过单个节点的硬件限制。如一个十亿文档需1TB空间可能不适合存储在单个节点的磁盘上，或者从单个节点搜索请求太慢了。为了解决这个问题，elasticsearch提供将索引分成多个分片的功能。当在创建索引时，可以定义想要分片的数量。每一个分片就是一个全功能的独立的索引，可以位于集群中任何节点上。
分片的两个最主要原因：
a、水平分割扩展，增大存储量
b、分布式并行跨分片操作，提高性能和吞吐量
分布式分片的机制和搜索请求的文档如何汇总完全是有elasticsearch控制的，这些对用户而言是透明的。
网络问题等等其它问题可以在任何时候不期而至，为了健壮性，强烈建议要有一个故障切换机制，无论何种故障以防止分片或者节点不可用。
为此，elasticsearch让我们将索引分片复制一份或多份，称之为分片副本或副本。
副本也有两个最主要原因：
高可用性，以应对分片或者节点故障。出于这个原因，分片副本要在不同的节点上。
提供性能，增大吞吐量，搜索可以并行在所有副本上执行。
总之，每一个索引可以被分成多个分片。索引也可以有0个或多个副本。复制后，每个索引都有主分片(母分片)和复制分片(复制于母分片)。分片和副本数量可以在每个索引被创建时定义。索引创建后，可以在任何时候动态的更改副本数量，但是，不能改变分片数。
默认情况下，elasticsearch为每个索引分片5个主分片和1个副本，这就意味着集群至少需要2个节点。索引将会有5个主分片和5个副本(1个完整副本)，每个索引总共有10个分片。
每个elasticsearch分片是一个Lucene索引。一个单个Lucene索引有最大的文档数LUCENE-5843, 文档数限制为2147483519(MAX_VALUE – 128)。 可通过_cat/shards来监控分片大小。
明日学习计划
Elasticsearch的安装配置和在PHP-Laravel项目中集成
总结
现在是大数据时代，任何网站都会面临 “搜素” 体积不断增大的问题，而这些问题mysql并不能很好的解决，所以是不是一开始就可以“预见性”的使用ES进行数据的检索，不建议完全采用ES作为数据库，而是作为一个分布式搜索服务，和数据库配合使用，让其自动同步mysql数据库数据。
