ES--01
ES概念：java
垂直搜索（站内搜索）node
什么是全文检索和Lucene？算法
1 全文检索 倒排索引数据库
2 Lucene 就是一个jar包 里面包含了封装好的各类简历倒排索引 以及进行搜索的代码 包括各类算法 咱们就用java开发的时候 引入 lucene jar 而后基于lucene的api进行开发 用lucene，将已有的数据创建索引 lucene会在本地磁盘上 给咱们组织索引的数据结构json
ES的概念：api
一、Elasticsearch的功能服务器
（1）分布式的搜索引擎和数据分析引擎restful
搜索：百度，网站的站内搜索，IT系统的检索
数据分析：电商网站，最近7天牙膏这种商品销量排名前10的商家有哪些；新闻网站，最近1个月访问量排名前3的新闻版块是哪些
分布式，搜索，数据分析网络
（2）全文检索，结构化检索，数据分析数据结构
全文检索：我想搜索商品名称包含牙膏的商品，select * from products where product_name like "%牙膏%"
结构化检索：我想搜索商品分类为日化用品的商品都有哪些，select * from products where category_id='日化用品'
部分匹配、自动完成、搜索纠错、搜索推荐
数据分析：咱们分析每个商品分类下有多少个商品，select category_id,count(*) from products group by category_id
（3）对海量数据进行近实时的处理
分布式：ES自动能够将海量数据分散到多台服务器上去存储和检索
海联数据的处理：分布式之后，就能够采用大量的服务器去存储和检索数据，天然而然就能够实现海量数据的处理了
近实时：检索个数据要花费1小时（这就不要近实时，离线批处理，batch-processing）；在秒级别对数据进行搜索和分析
跟分布式/海量数据相反的：lucene，单机应用，只能在单台服务器上使用，最多只能处理单台服务器能够处理的数据量
二、Elasticsearch的适用场景
国外
（1）维基百科，相似百度百科，牙膏，牙膏的维基百科，全文检索，高亮，搜索推荐
（2）The Guardian（国外新闻网站），相似搜狐新闻，用户行为日志（点击，浏览，收藏，评论）+社交网络数据（对某某新闻的相关见解），数据分析，给到每篇新闻文章的做者，让他知道他的文章的公众反馈（好，坏，热门，垃圾，鄙视，崇拜）
（3）Stack Overflow（国外的程序异常讨论论坛），IT问题，程序的报错，提交上去，有人会跟你讨论和回答，全文检索，搜索相关问题和答案，程序报错了，就会将报错信息粘贴到里面去，搜索有没有对应的答案
（4）GitHub（开源代码管理），搜索上千亿行代码
（5）电商网站，检索商品
（6）日志数据分析，logstash采集日志，ES进行复杂的数据分析（ELK技术，elasticsearch+logstash+kibana）
（7）商品价格监控网站，用户设定某商品的价格阈值，当低于该阈值的时候，发送通知消息给用户，好比说订阅牙膏的监控，若是高露洁牙膏的家庭套装低于50块钱，就通知我，我就去买
（8）BI系统，商业智能，Business Intelligence。好比说有个大型商场集团，BI，分析一下某某区域最近3年的用户消费金额的趋势以及用户群体的组成构成，产出相关的数张报表，**区，最近3年，每一年消费金额呈现100%的增加，并且用户群体85%是高级白领，开一个新商场。ES执行数据分析和挖掘，Kibana进行数据可视化
国内
（9）国内：站内搜索（电商，招聘，门户，等等），IT系统搜索（OA，CRM，ERP，等等），数据分析（ES热门的一个使用场景）
三、Elasticsearch的特色
（1）能够做为一个大型分布式集群（数百台服务器）技术，处理PB级数据，服务大公司；也能够运行在单机上，服务小公司
（2）Elasticsearch不是什么新技术，主要是将全文检索、数据分析以及分布式技术，合并在了一块儿，才造成了独一无二的ES；lucene（全文检索），商用的数据分析软件（也是有的），分布式数据库（mycat）
（3）对用户而言，是开箱即用的，很是简单，做为中小型的应用，直接3分钟部署一下ES，就能够做为生产环境的系统来使用了，数据量不大，操做不是太复杂
（4）数据库的功能面对不少领域是不够用的（事务，还有各类联机事务型的操做）；特殊的功能，好比全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理；Elasticsearch做为传统数据库的一个补充，提供了数据库所不不能提供的不少功能
ElasticSearch 和 Lucene 的关系
一、lucene和elasticsearch的前世此生
lucene，最早进、功能最强大的搜索库，直接基于lucene开发，很是复杂，api复杂（实现一些简单的功能，写大量的java代码），须要深刻理解原理（各类索引结构）
elasticsearch，基于lucene，隐藏复杂性，提供简单易用的restful api接口、java api接口（还有其余语言的api接口）
（1）分布式的文档存储引擎
（2）分布式的搜索引擎和分析引擎
（3）分布式，支持PB级数据
开箱即用，优秀的默认参数，不须要任何额外设置，彻底开源
二、elasticsearch的核心概念
（1）Near Realtime（NRT）：近实时，两个意思，从写入数据到数据能够被搜索到有一个小延迟（大概1秒）；基于es执行搜索和分析能够达到秒级
（2）Cluster：集群，包含多个节点，每一个节点属于哪一个集群是经过一个配置（集群名称，默认是elasticsearch）来决定的，对于中小型应用来讲，刚开始一个集群就一个节点很正常
（3）Node：节点，集群中的一个节点，节点也有一个名称（默认是随机分配的），节点名称很重要（在执行运维管理操做的时候），默认节点会去加入一个名称为“elasticsearch”的集群，若是直接启动一堆节点，那么它们会自动组成一个elasticsearch集群，固然一个节点也能够组成一个elasticsearch集群
（4）Document&field：（document至关于一个row field至关于一个字段属性）文档，es中的最小数据单元，一个document能够是一条客户数据，一条商品分类数据，一条订单数据，一般用JSON数据结构表示，每一个index下的type中，均可以去存储多个document。一个document里面有多个field，每一个field就是一个数据字段。
product document
{
"product_id": "1",
"product_name": "高露洁牙膏",
"product_desc": "高效美白",
"category_id": "2",
"category_name": "日化用品"
}
（5）Index：至关于数据库 db 索引，包含一堆有类似结构的文档数据，好比能够有一个客户索引，商品分类索引，订单索引，索引有一个名称。一个index包含不少document，一个index就表明了一类相似的或者相同的document。好比说创建一个product index，商品索引，里面可能就存放了全部的商品数据，全部的商品document。
（6）Type：至关于表格 table 类型，每一个索引里均可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field，好比博客系统，有一个索引，能够定义用户数据type，博客数据type，评论数据type。
商品index，里面存放了全部的商品数据，商品document
可是商品分不少种类，每一个种类的document的field可能不太同样，好比说电器商品，可能还包含一些诸如售后时间范围这样的特殊field；生鲜商品，还包含一些诸如生鲜保质期之类的特殊field
type，日化商品type，电器商品type，生鲜商品type
日化商品type：product_id，product_name，product_desc，category_id，category_name
电器商品type：product_id，product_name，product_desc，category_id，category_name，service_period
生鲜商品type：product_id，product_name，product_desc，category_id，category_name，eat_period
每个type里面，都会包含一堆document
{
"product_id": "2",
"product_name": "长虹电视机",
"product_desc": "4k高清",
"category_id": "3",
"category_name": "电器",
"service_period": "1年"
}
{
"product_id": "3",
"product_name": "基围虾",
"product_desc": "纯自然，冰岛产",
"category_id": "4",
"category_name": "生鲜",
"eat_period": "7天"
}
（7）shard：单台机器没法存储大量数据，es能够将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就能够横向扩展，存储更多数据，让搜索和分析等操做分布到多台服务器上去执行，提高吞吐量和性能。每一个shard都是一个lucene index。
（8）replica：任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，所以能够为每一个shard建立多个replica副本。replica能够在shard故障时提供备用服务，保证数据不丢失，多个replica还能够提高搜索操做的吞吐量和性能。primary shard（创建索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每一个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器。
安装运行es
elasticsearch 的安装 head插件：
使用wget 安装head插件
安装后访问localhost：//9100显示未链接 停掉head服务 而后编辑es的配置文件 ElasticSearch.yml
修改后 启动es
而后开启head插件
链接状态
启动kibana
使用devtools
一、document数据格式
面向文档的搜索分析引擎
（1）应用系统的数据结构都是面向对象的，复杂的
（2）对象数据存储到数据库中，只能拆解开来，变为扁平的多张表，每次查询的时候还得还原回对象格式，至关麻烦
（3）ES是面向文档的，文档中存储的数据结构，与面向对象的数据结构是同样的，基于这种文档数据结构，es能够提供复杂的索引，全文检索，分析聚合等功能
（4）es的document用json数据格式来表达
public class Employee {
private String email;
private String firstName;
private String lastName;
private EmployeeInfo info;
private Date joinDate;
}
private class EmployeeInfo {
private String bio; // 性格
private Integer age;
private String[] interests; // 兴趣爱好
}
EmployeeInfo info = new EmployeeInfo();
info.setBio("curious and modest");
info.setAge(30);
info.setInterests(new String[]{"bike", "climb"});
Employee employee = new Employee();
employee.setEmail("zhangsan@sina.com");
employee.setFirstName("san");
employee.setLastName("zhang");
employee.setInfo(info);
employee.setJoinDate(new Date());
employee对象：里面包含了Employee类本身的属性，还有一个EmployeeInfo对象
两张表：employee表，employee_info表，将employee对象的数据从新拆开来，变成Employee数据和EmployeeInfo数据
employee表：email，first_name，last_name，join_date，4个字段
employee_info表：bio，age，interests，3个字段；此外还有一个外键字段，好比employee_id，关联着employee表
{
"email": "zhangsan@sina.com",
"first_name": "san",
"last_name": "zhang",
"info": {
"bio": "curious and modest",
"age": 30,
"interests": [ "bike", "climb" ]
},
"join_date": "2017/01/01"
}
咱们就明白了es的document数据格式和数据库的关系型数据格式的区别
案例：
二、电商网站商品管理案例背景介绍
有一个电商网站，须要为其基于ES构建一个后台系统，提供如下功能：
（1）对商品信息进行CRUD（增删改查）操做
（2）执行简单的结构化查询
（3）能够执行简单的全文检索，以及复杂的phrase（短语）检索
（4）对于全文检索的结果，能够进行高亮显示
（5）对数据进行简单的聚合分析
三、简单的集群管理
（1）快速检查集群的健康情况
es提供了一套api，叫作cat api，能够查看es中各类各样的数据
GET /_cat/health?v
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1488006741 15:12:21 elasticsearch yellow 1 1 1 1 0 0 1 0 - 50.0%
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 启动第二个es进程的状况 yellow变成green
1488007113 15:18:33 elasticsearch green 2 2 2 1 0 0 0 0 - 100.0%
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1488007216 15:20:16 elasticsearch yellow 1 1 1 1 0 0 1 0 - 50.0%
如何快速了解集群的健康情况？green、yellow、red？
green：每一个索引的primary shard和replica shard都是active状态的
yellow：每一个索引的primary shard都是active状态的，可是部分replica shard不是active状态，处于不可用的状态
red：不是全部索引的primary shard都是active状态的，部分索引有数据丢失了
为何如今会处于一个yellow状态？
咱们如今就一个笔记本电脑，就启动了一个es进程，至关于就只有一个node。如今es中有一个index，就是kibana本身内置创建的index。因为默认的配置是给每一个index分配5个primary shard和5个replica shard，并且primary shard和replica shard不能在同一台机器上（为了容错）。如今kibana本身创建的index是1个primary shard和1个replica shard。当前就一个node，因此只有1个primary shard被分配了和启动了，可是一个replica shard没有第二台机器去启动。
作一个小实验：此时只要启动第二个es进程，就会在es集群中有2个node，而后那1个replica shard就会自动分配过去，而后cluster status就会变成green状态。
（2）快速查看集群中有哪些索引
GET /_cat/indices?v
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open .kibana rUm9n9wMRQCCrRDEhqneBg 1 1 1 0 3.1kb 3.1kb
（3）简单的索引操做
建立索引：PUT /test_index?pretty
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open test_index XmS9DTAtSkSZSwWhhGEKkQ 5 1 0 0 650b 650b
yellow open .kibana rUm9n9wMRQCCrRDEhqneBg 1 1 1 0 3.1kb 3.1kb
删除索引：DELETE /test_index?pretty
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open .kibana rUm9n9wMRQCCrRDEhqneBg 1 1 1 0 3.1kb 3.1kb
四、商品的CRUD操做
（1）新增商品：新增文档，创建索引 version涉及到乐观锁的并发控制策略。
PUT /index/type/id
{
"json数据"
}
PUT /ecommerce/product/1
{
"name" : "gaolujie yagao",
"desc" : "gaoxiao meibai",
"price" : 30,
"producer" : "gaolujie producer",
"tags": [ "meibai", "fangzhu" ]
}
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}
PUT /ecommerce/product/2
{
"name" : "jiajieshi yagao",
"desc" : "youxiao fangzhu",
"price" : 25,
"producer" : "jiajieshi producer",
"tags": [ "fangzhu" ]
}
PUT /ecommerce/product/3
{
"name" : "zhonghua yagao",
"desc" : "caoben zhiwu",
"price" : 40,
"producer" : "zhonghua producer",
"tags": [ "qingxin" ]
}
es会自动创建index和type，不须要提早建立，并且es默认会对document每一个field都创建倒排索引，让其能够被搜索
（2）查询商品：检索文档
GET /index/type/id
GET /ecommerce/product/1
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"name": "gaolujie yagao",
"desc": "gaoxiao meibai",
"price": 30,
"producer": "gaolujie producer",
"tags": [
"meibai",
"fangzhu"
]
}
}
（3）修改商品：替换文档 version改变了
PUT /ecommerce/product/1
{
"name" : "jiaqiangban gaolujie yagao",
"desc" : "gaoxiao meibai",
"price" : 30,
"producer" : "gaolujie producer",
"tags": [ "meibai", "fangzhu" ]
}
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": false
}
PUT /ecommerce/product/1
{
"name" : "jiaqiangban gaolujie yagao"
}
替换方式有一个很差，即便必须带上全部的field，才能去进行信息的修改 若是只带name属性来替换 其余属性就丢失了 只有name属性了
（4）修改商品：更新文档
POST /ecommerce/product/1/_update
{
"doc": {
"name": "jiaqiangban gaolujie yagao"
}
}
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 8,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}
个人风格，其实有选择的状况下，不太喜欢念ppt，或者照着文档作，或者直接粘贴写好的代码，尽可能是纯手敲代码
（5）删除商品：删除文档
DELETE /ecommerce/product/1
{
"found": true,
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 9,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"found": false
}
多种搜索方式：
一、query string search
二、query DSL
三、query filter
四、full-text search
五、phrase search
六、highlight search
一、query string search
搜索所有商品：GET /ecommerce/product/_search
took：耗费了几毫秒
timed_out：是否超时，这里是没有
_shards：数据拆成了5个分片，因此对于搜索请求，会打到全部的primary shard（或者是它的某个replica shard也能够）
hits.total：查询结果的数量，3个document
hits.max_score：score的含义，就是document对于一个search的相关度的匹配分数，越相关，就越匹配，分数也高
hits.hits：包含了匹配搜索的document的详细数据
{
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 3,
"max_score": 1,
"hits": [
{
"_index": "ecommerce",
"_type": "product",
"_id": "2",
"_score": 1,
"_source": {
"name": "jiajieshi yagao",
"desc": "youxiao fangzhu",
"price": 25,
"producer": "jiajieshi producer",
"tags": [
"fangzhu"
]
}
},
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_score": 1,
"_source": {
"name": "gaolujie yagao",
"desc": "gaoxiao meibai",
"price": 30,
"producer": "gaolujie producer",
"tags": [
"meibai",
"fangzhu"
]
}
},
{
"_index": "ecommerce",
"_type": "product",
"_id": "3",
"_score": 1,
"_source": {
"name": "zhonghua yagao",
"desc": "caoben zhiwu",
"price": 40,
"producer": "zhonghua producer",
"tags": [
"qingxin"
]
}
}
]
}
}
query string search的由来，由于search参数都是以http请求的query string来附带的
搜索商品名称中包含yagao的商品，并且按照售价降序排序：GET /ecommerce/product/_search?q=name:yagao&sort=price:desc
适用于临时的在命令行使用一些工具，好比curl，快速的发出请求，来检索想要的信息；可是若是查询请求很复杂，是很难去构建的
在生产环境中，几乎不多使用query string search
二、query DSL
DSL：Domain Specified Language，特定领域的语言
http request body：请求体，能够用json的格式来构建查询语法，比较方便，能够构建各类复杂的语法，比query string search确定强大多了
查询全部的商品
GET /ecommerce/product/_search
{
"query": { "match_all": {} }
}
查询名称包含yagao的商品，同时按照价格降序排序
GET /ecommerce/product/_search
{
"query" : {
"match" : {
"name" : "yagao"
}
},
"sort": [
{ "price": "desc" }
]
}
分页查询商品，总共3条商品，假设每页就显示1条商品，如今显示第2页，因此就查出来第2个商品
GET /ecommerce/product/_search
{
"query": { "match_all": {} },
"from": 1,
"size": 1
}
指定要查询出来商品的名称和价格就能够
GET /ecommerce/product/_search
{
"query": { "match_all": {} },
"_source": ["name", "price"]
}
更加适合生产环境的使用，能够构建复杂的查询
三、query filter
搜索商品名称包含yagao，并且售价大于25元的商品
四、full-text search（全文检索） 计算相关度 分数 socre
producer这个字段 会被拆解 创建倒排索引
special 4
yagao 4
producer 1,2,3,4
gaolujie 1
zhognhua 3
jiajieshi 2
五、phrase search（短语搜索）
跟全文检索相对应，相反，全文检索会将输入的搜索串拆解开来，去倒排索引里面去一一匹配，只要能匹配上任意一个拆解后的单词，就能够做为结果返回
phrase search，要求输入的搜索串，必须在指定的字段文本中，彻底包含如出一辙的，才能够算匹配，才能做为结果返回
在yagao producer 之间多加几个空格也能匹配 没有空格 或者顺序颠倒都不能匹配
六、highlight search（高亮搜索结果）
嵌套聚合、下钻分析、聚合分析
一、计算每一个tag下的商品 聚合：
将文本filed的fileddata属性设置为true
PUT /ecommerce/_mapping/product
{
"properties": {
"tags": {
"type": "text",
"fielddata": true
}
}
}
第二个聚合分析的需求：对名称中包含yagao的商品，计算每一个tag下的商品数量
第三个聚合分析的需求：先分组，再算每组的平均值，计算每一个tag下的商品的平均价格
第四个数据分析需求：计算每一个tag下的商品的平均价格，而且按照平均价格降序排序
第五个数据分析需求：按照指定的价格范围区间进行分组，而后在每组内再按照tag进行分组，最后再计算每组的平均价格
一、Elasticsearch对复杂分布式机制的透明隐藏特性
二、Elasticsearch的垂直扩容与水平扩容
三、增减或减小节点时的数据rebalance
四、master节点
五、节点对等的分布式架构
一、Elasticsearch对复杂分布式机制的透明隐藏特性
Elasticsearch是一套分布式的系统，分布式是为了应对大数据量
隐藏了复杂的分布式机制
分片机制（咱们以前随随便便就将一些document插入到es集群中去了，咱们有没有care过数据怎么进行分片的，数据到哪一个shard中去）
cluster discovery（集群发现机制，咱们以前在作那个集群status从yellow转green的实验里，直接启动了第二个es进程，那个进程做为一个node自动就发现了集群，而且加入了进去，还接受了部分数据，replica shard）
shard负载均衡（举例，假设如今有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均匀分配，以保持每一个节点的均衡的读写负载请求）
shard副本，请求路由，集群扩容，shard重分配
二、Elasticsearch的垂直扩容与水平扩容
垂直扩容：采购更强大的服务器，成本很是高昂，并且会有瓶颈，假设世界上最强大的服务器容量就是10T，可是当你的总数据量达到5000T的时候，你要采购多少台最强大的服务器啊
水平扩容：业界常常采用的方案，采购愈来愈多的普通服务器，性能比较通常，可是不少普通服务器组织在一块儿，就能构成强大的计算和存储能力
普通服务器：1T，1万，100万
强大服务器：10T，50万，500万
扩容对应用程序的透明性
三、增减或减小节点时的数据rebalance
保持负载均衡
四、master节点
（1）建立或删除索引
（2）增长或删除节点
五、节点平等的分布式架构
（1）节点对等，每一个节点都能接收全部的请求
（2）自动请求路由
（3）响应收集
请求转发
接收到请求的shard 自动将请求转发到目标document的shard 而且返回给client
第十讲：
一、shard&replica机制再次梳理
二、图解单node环境下建立index是什么样子的
------------------------------------------------------------------------------------------------
一、shard&replica机制再次梳理
（1）index包含多个shard
（2）每一个shard都是一个最小工做单元，承载部分数据，lucene实例，完整的创建索引和处理请求的能力
（3）增减节点时，shard会自动在nodes中负载均衡
（4）primary shard和replica shard，每一个document确定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard
（5）replica shard是primary shard的副本，负责容错，以及承担读请求负载
（6）primary shard的数量在建立索引的时候就固定了，replica shard的数量能够随时修改
（7）primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard
（8）primary shard不能和本身的replica shard放在同一个节点上（不然节点宕机，primary shard和副本都丢失，起不到容错的做用），可是能够和其余primary shard的replica shard放在同一个节点上
------------------------------------------------------------------------------------------------
二、图解单node环境下建立index是什么样子的
（1）单node环境下，建立一个index，有3个primary shard，3个replica shard
（2）集群status是yellow
（3）这个时候，只会将3个primary shard分配到仅有的一个node上去，另外3个replica shard是没法分配的
（4）集群能够正常工做，可是一旦出现节点宕机，数据所有丢失，并且集群不可用，没法承接任何请求
PUT /test_index
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
每一个shard都是一个最小的单元 就是一个lucene实例 自动把shard均匀分布
每一个document存在于一个primary shard 和它对应的replicate shard中
primaryshard的数量最开始固定了就不能变了 replica shard 的数量能改变
-
每一个你不满意的现在，都有一个你没有努力的曾经。