2019/07/24 搜索引擎及ES概述(01)

**典型站点架构：
1。负载层，
2.动态内容和静态内容分离
缓存服务器，图片会到专门的图片服务器
css/html 等 非图片类的但是会随着网站更新修改的放到动态内容服务器组上去
对于动态内容可以用调度器分发给后端的动态内容服务器，
**
对于程序而言，是由指令加数据组成的,程序文件一般只包含，代码，php，ruby等jsp研发的动态站点内容，，数据一般是放在存储系统当作的，三类存储
1.关系型数据库
2.非关系型数据库 redis ，mongodb
3.非结构化数据，分布式存储之上，HDFS,CLUSTERFS（站点规模没有太大，用这个是自讨苦吃）
图片一般放在分布式存储之上

对于站点，用户每天访问请求站点到达时，页面资源中，哪些url被请求的最多，需要统计，排序，查看
用户的所有请求在访问日志中，如何统计日志，分析数据，之前用的AWK（对于大文件性能有限）
需要一个高效的存储搜索引擎 elasticsearch
全文搜索引擎，能够支持按关键词，整个内容进行搜索
搜索引擎组件，也需要存储，有了数据才能搜索，搜索要高效，搜索是基于索引，所以是基于数据构成的，

需要让每一个服务（tomcat，mysql之类的）的节点，商品信息也需要从MySQL中导入到一个组件里，日志信息每产生都记录到搜索引擎，这是两类数据，日志和站点数据，
所以搜索引擎应该能区分这两类数据是属于不同的集合
一个搜索引擎要想完成搜索，必须完成两个核心步骤/两类组件
第一类组件，把数据拿过来，构建成能搜索的格式，索引
第二类组件，能够接受请求来通过索引进行查询
所以需要量大核心部件组成
索引组件，构建出索引等待用户区搜索的
搜索组件，能接收用户请求完成查询过程
原始内容raw content需要一个数据抽取工具抽取出来acquire content，数据抽取导入工具ETL，加载到内容后，构建成一个核心组件build document （非关系型数据的4大流派，文件document流派，mongodb就是文档存储，简单来说就是基于jscon格式自描述来存储的。key-value）构建成文档，apache日志combind第一个字段通常是客户端IP，需要把这些日志信息抽取出来加标签KV，比如IP:XXXX,NAME:XXX,只有构建出这种格式才叫文档，、
这个抽取工具需要抽取出来，加上表头转换成文档格式
构建成文档还是无法搜索的，深色的组件是非常关键的，分析文档，需要做切词
anaylze document主要的功能在于切词，移除不必要的内容，同义词替换，比如bike，bicycle
把分析的结果构建成索引index document，倒排索引，不是先有数据再去索引，而是存的时候就用关键词
假如要存这三句话，将来要找is哪个包含，winter 哪个包含
1.先切词，完全切成一个单词
2.出现的频次
3.每个次出现在第几个文档中
找choice，就找3号文档返回给你
如果找winter is 就找俩个的交集
有一个权重算法，这个词出现的文档越少，对于权重则越高，
2.一个词在文档中出现的次数越少，则权重越高
因此index document 就构建了索引内容

接下来就需要给用户一个搜索界面，文档框
build query 构建查询，根据你输入的内容照样切词，跟你构建索引的方式必须一样才可以，
一样需要切词转换的分析过程。
切词完以后还需要构建查询
构建查询极其复杂，与或非，同义词，大小转换，模糊匹配
构建完查询即可执行查询
有量大组件，互联网有些开源程序，能帮你完成其中某一部分功能，把数据给它，帮你分析构建成索引，但不能构建文档，需要自己做，提供文档给它分析生成索引，著名的项目lucence
三个组件

高性能的全特征的文本搜索引擎库，既然是库就需要自己写程序调用才可以
Lucene Core：
Apache LuceneTM is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform.
几乎适用所有规模的要求要使用文本或者全文搜索功能的应用程序，尤其是跨平台时，是使用java编写
Solr：
SolrTM is a high performance search server built using Lucene Core, with XML/HTTP and JSON/Python/Ruby APIs, hit highlighting, faceted search, caching, replication, and a web admin interface.
solr就是一个搜索服务器，结合lucene就是一个完整的搜索引擎了，现在可以支持分布式了
elasticsearch 本来就是支持分布式和solr是竞争产品，但核心都是Lucene core
ElasticSearch：
Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases. As the heart of the Elastic Stack, it centrally stores your data so you can discover the expected and uncover the unexpected.
高性能索引

elasticsearch需要一个组件来实现文档构建，logstash，kibana 用户搜索界面
lucene 来构建索引，通常简称为ELK，后来称为elastic stack，因为包含的工具变多了
二elasticsearch只是搜索组件，核心是lucene
但是elasticsearch，支持分布式，协同起来一起工作，不以服务器为单位进行分，而是以数据为单位进行分，数据很大，可以64M为一片，再64M为第二片
但是ES没这么灵活，数据分几片在构建的时候就需要确定好，10G分5片，100M可能也分5片，不是固定大小的片，而是固定数量的片，每一片是应该有副本，在这个节点挂了，在其他节点上还有数据的
分片至少有一个副本replyca，主的primary，主节点在节点1，副节点必须在另外节点上，这样任何主机宕了，不至于任何数据不完整
集群有三种状态
green, 所有分片主副本都在，正常状态
yellow, 有些分片数量不够，自己会创建副本出来，创建完恢复到green状态，创建过程中是yellow状态
red 某一次故障，导致主副都没有，搜索出来的结果不是精准结果了
就算只是单机也是分片的，一个主机，主副都存在一起也没多大意义
对于集群最少三节点，只要是分布式系统都有可能发生分区，只要被分区，就有可能脑裂（两边节点分开 了，都认为自己是集群，少了副节点，都去补，这样就导致不协调，在某时刻只能由一个节点代表集群继续工作，拥有法定票数）
现在大多数新建站点的搜索引擎都是用的elasticsearch
**ElasticSearch：
Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases. As the heart of the Elastic Stack, it centrally stores your data so you can discover the expected and uncover the unexpected.
天生的分布式特性，非常拥有弹性， Elasticsearch 只是一个组件不能构建成一个完整的搜索引擎来，要构建易用的需要Elastic Stack **

Elastic Stack：
ElasticSearch
Logstash 作为日志的抽取工具，弱爆了，性能差，python是使用c语言写，json是java用的python，ruby是C语言
jruby是java写的ruby
Logstash is an open source, server-side data processing pipeline（流水线，管道） that ingests data from a multitude of sources simultaneously, transforms it, and then sends it to your favorite “stash.” (Ours is Elasticsearch, naturally.)
要放到产生数据一侧，能收集N个数据源的数据，转换，构建成文档化
Beats：go语言 一堆组件，数据收集器
Filebeat：Log Files 文件收集器，一般处理log文件
Metricbeat：Metrics 度量数据
Packetbeat：Network Data 通信报文数据
Winlogbeat：Windows Event Logs windows日志收集器
Heartbeat：Uptime Monitoring 运行监控数据，监控你的服务器数据是否处于正常状态
这一堆beats的存在可以不用logstash来收集了，可以直接beats收集好后，来发送给elasticsearch，logstash有些功能，beats没有，所以logstash依然会用到
Kibana：
Kibana lets you visualize your Elasticsearch data and navigate the Elastic Stack, so you can do anything from learning why you’re getting paged at 2:00 a.m. to understanding the impact rain might have on your quarterly numbers.
可视化组件，能把ES中的数据直观展示出来，非常强大
对于ELK这四个是核心组件

TF/IDF算法：
https://zh.wikipedia.org/wiki/Tf-idf
这些组件其实是可以打包的，x-pack是组合包
直接买服务

多个节点构成的集合就叫集群，有了集群就可以自行提供分片级的冗余能力，一个节点只能属于一个集群，集群之间的识别靠集群名称
ES的核心组件：
物理组件：
集群：
状态：
green,
yellow,
red
节点：
Shard：节点上分片

Lucene的核心组件： ES不自己提供索引组件而是Lucene
1索引（index）：数据库(database)
2类型（type）：表(table)
3文档（Document）：行(row)
4映射（Mapping）：
对lucene来讲，同类的组件，库级别的叫索引，对一个ES集群来讲，索引是可以有多个的（类似mysql，库可以有多个），一个索引要存储多种不同类别的数据，为了区分不同的集合，用类型来表示，用于区别不同对象，每一个type中，有多个内容类型的数据的实体，文档（每一个类型当中有N个文档组成）当搜索的时候是向索引发送请求的，基于文档返回结果信息
要定义json格式的字段是什么类型，比如ip是字符串等，不指定，就会按照一些值自行判定属于什么类型，但是未必准，每一个索引内部所存储的每一个字段，字段标签名称，数据类型是怎么样的需要自己定义
映射mapping 识别这个字段是什么类型，
对lucene而言，每个数据存入索引之前，需要文档化，jason格式文档，key1:value1，我们必须给出这个转换的文档才可以
哪些字段要分析，哪些不要，这些用户定义的时候也可以自定义
域选项：来控制lucene 将文档添加进域索引后对该域执行的操作；
域选项：来控制Lucene将文档添加进域索引后对该域执行的操作：
Index.ANALYZED：切词和分析；
Index.NOT_ANALYZED：做索引，但不做分析；做索引才能搜索，直接把字段当精确匹配，直接索引而不做分析
Index.NO：不做索引；就不做搜索，不打算给这个字段做索引

elasticseach是一个rest form 风格的搜索服务器，所有接口都是http协议的，所以你的所有elasticsearch的操作命令都能使用curl命令来实现
使用场景
每一个nginx服务器上使用logstash/filebeat，把日志抽取出来发送给elasticseacher集群，ES集群前面需要一个展示页面，kibana，
一旦略具规模，需要加一些组件，logstash server 是一个管道。，所有日志拿到以后，可以做处理，输出给ES
所以logstash server有三个组件（input，filter，output，）
如果数据了过大，就需要中间加队列，通常是redis，日志先发给我nginx，再发给logstash server集群
所有主机，日志未处理前，所有数据发给redis，logstash 每次取一个redis队列，处理完之后，直接发给ES
redis可以作为buffer server 缓冲一下