老年门户网站建设的意义,二手车网站系统,桂林学校网站制作,东莞网站建设信科1.elasticsearch核心概念1.1 索引(index)一个索引就是一个拥有几分相似特征的文档的集合。比如说#xff0c;你可以有一个客户数据的索引#xff0c;另一个产品目录的索引#xff0c;还有一个订单数据的索引。一个索引由一个名字来标识#xff08;必须全部是小写字母#…1.elasticsearch核心概念1.1 索引(index)一个索引就是一个拥有几分相似特征的文档的集合。比如说你可以有一个客户数据的索引另一个产品目录的索引还有一个订单数据的索引。一个索引由一个名字来标识必须全部是小写字母并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候都要使用到这个名字。在一个集群中可以定义任意多的索引。能搜索的数据必须索引这样的好处是可以提高查询速度比如新华字典前面的目录就是索引的意思目录可以提高查询速度。注意我们平时使用索引这个词在不同环境具有不同语义名词一个elasticsearch集群中可以创建很多个不同的索引倒排索引或者关系型数据库中的b树索引动词保存一个文档doc到elasticsearch中的过程也叫索引(indexing)项目推荐基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企业级系统架构底层框架封装解决业务开发时常见的非功能性需求防止重复造轮子方便业务快速开发和企业技术栈框架统一管理。引入组件化的思想实现高内聚低耦合并且高度可配置化做到可插拔。严格控制包依赖和统一版本管理做到最少化依赖。注重代码规范和注释非常适合个人学习和企业使用Github地址https://github.com/plasticene/plasticene-boot-starter-parentGitee地址https://gitee.com/plasticene3/plasticene-boot-starter-parent1.2 类型(type)elasticsearch在一个索引中你可以定义一种或多种类型但是后来elasticsearch升级版本中不断弱化type这个概念直到elasticsearch7.0以后type正式在es中废除7.0以后默认不再支持自定义索引类型新建索引时会默认添加一个类型_doc所以在之前elasticsearch基础篇说到的elasticsearch和关系型数据库的类别就不太准确之前说索引对应mysql的数据库这里我觉得索引对应mysql的表更合适。1.3 文档(Document)一个文档是一个可被索引的基础信息单元也就是一条数据比如你可以拥有某一个客户的文档某一个产品的一个文档当然也可以拥有某个订单的一个文档。文档以JSONJavascript Object Notation格式来表示而JSON是一个到处存在的互联网数据交互格式。在一个index中你可以存储任意多的文档1.4 字段(Field)相当于是数据表的字段对文档数据根据不同属性进行的分类标识1.5 映射(mapping)mapping是处理数据的方式和规则方面做一些限制如某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的其它就是处理ES里面数据的一些使用规则设置也叫做映射按照最优规则处理数据对性能提高很大因此才需要建立映射并且需要思考如何建立映射才能对性能更好。我们在创建索引时候添加mapping定义如下所示添加一个student索引并设置mappingPUT student{ settings: { number_of_shards: 3, number_of_replicas: 2 }, mappings: { properties: { name:{ type:text }, sex:{ type:keyword }, age:{ type:long }, rank:{ type:integer, index:false } } }}当我们创建索引没有设置mapping时然后直接往索引里面写入文档elasticsearch会根据我们写入的文档自动生成对应的mapping但是有时候mapping的有些字段设置不是我们想要的需要修改。个人建议我们在创建自己索引之前可以先随便创建一个测试索引然后写入我们的文档然后查看测试索引生成的mapping这时候我们在创建自己真正索引设置mapping时就可以在前面得到的mapping上修改不需要从无到有开始写mapping极大提高效率。1.6 分片Shards一个索引可以存储超出单个节点硬件限制的大量数据。比如一个具有10亿文档数据的索引占据1TB的磁盘空间而任一节点都可能没有这样大的磁盘空间。或者单个节点处理搜索请求响应太慢。为了解决这个问题Elasticsearch提供了将索引划分成多份的能力每一份就称之为分片。当你创建一个索引的时候你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”这个“索引”可以被放置到集群中的任何节点上。分片很重要主要有两方面的原因1允许你水平分割 / 扩展你的内容容量。2允许你在分片之上进行分布式的、并行的操作进而提高性能/吞吐量。至于一个分片怎样分布它的文档怎样聚合和搜索请求是完全由Elasticsearch管理的对于作为用户的你来说这些都是透明的无需过分关心。被混淆的概念是一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。一个 Elasticsearch 索引 是分片的集合。当 Elasticsearch 在索引中搜索的时候 他发送查询到每一个属于索引的分片(Lucene 索引)然后合并每个分片的结果到一个全局的结果集。1.7 副本Replicas在一个节点环境里失败随时都可能发生在某个分片/节点不知怎么的就处于离线状态或者由于任何原因消失了这种情况下有一个故障转移机制是非常有用并且是强烈推荐的。为此目的Elasticsearch允许你创建分片的一份或多份拷贝这些拷贝叫做复制分片(副本)。复制分片之所以重要有两个主要原因1在分片/节点失败的情况下提供了高可用性。因为这个原因注意到复制分片从不与原/主要original/primary分片置于同一节点上是非常重要的。2扩展你的搜索量/吞吐量因为搜索可以在所有的副本上并行运行总之每个索引可以被分成多个分片。一个索引也可以被复制0次意思是没有复制或多次。一旦复制了每个索引就有了主分片作为复制源的原来的分片和复制分片主分片的拷贝之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后你可以在任何时候动态地改变复制的数量但是你事后不能改变分片的数量。分片数量不能改变的原因下文会阐述。默认情况下Elasticsearch中的每个索引被分片1个主分片和1个复制这意味着如果你的集群中至少有两个节点注意集群如果只有两个节点可能产生脑裂问题。对于脑裂问题后面会讲述。你的索引将会有1个主分片和另外1个复制分片1个完全拷贝这样的话每个索引总共就有2个分片我们需要根据索引需要确定分片个数。1.8 分配Allocation将分片分配给某个节点的过程包括分配主分片或者副本。如果是副本还包含从主分片复制数据的过程。这个过程是由master节点完成的。2.elasticsearch系统架构与集群2.1 系统架构一个运行中的Elasticsearch 实例称为一个节点而集群是由一个或者多个拥有相同cluster.name 配置的节点组成它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时集群将会重新平均分布所有的数据。系统架构如下图所示当一个节点被选举成为主节点时它将负责管理集群范围内的所有变更例如增加、删除索引或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作所以当集群只拥有一个主节点的情况下即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。作为用户我们可以将请求发送到集群中的任何节点包括主节点。每个节点都知道任意文档所处的位置并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点它都能负责从各个包含我们所需文档的节点收集回数据并将最终结果返回给客户端。Elasticsearch 对这一切的管理都是透明的。2.2 单节点集群部署我们创建一个users指定分片数为3副本数是1PUT users{ settings: { number_of_shards: 3 , number_of_replicas: 1 }}这时候我们通过elasticsearch-head插件查看集群情况2.3 故障转移当集群中只有一个节点在运行时意味着会有一个单点故障问题——没有冗余。幸运的是我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时只要它和第一个节点有同样的cluster.name 配置它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候为了加入到同一集群你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。如果启动了第二个节点我们的集群将会拥有两个节点的集群: 所有主分片和副本分片都已被分配2.4 水平扩容怎样为我们的正在增长中的应用程序按需扩容呢当启动了第三个节点我们的集群将会拥有三个节点的集群: 为了分散负载而对分片进行重新分配主分片的数目在索引创建时就已经确定了下来。实际上这个数目定义了这个索引能够存储的最大数据量。实际大小取决于你的数据、硬件和使用场景。但是读操作——搜索和返回数据——可以同时被主分片或副本分片所处理所以当你拥有越多的副本分片时也将拥有越高的吞吐量。在运行中的集群上是可以动态调整副本分片数目的我们可以按需伸缩集群。当然**如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能因为每个分片从节点上获得的资源会变少。你需要增加更多的硬件资源来提升吞吐量。**但是更多的副本分片数提高了数据冗余量按照上面的节点配置我们可以在失去2个节点的情况下不丢失任何数据。这时候我们集群有3个节点假如此时我们master主节点node-1发生故障不可用es集群是怎样个状况呢我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作所以发生的第一件事情就是选举一个新的主节点Node 2 。在我们关闭Node 1 的同时也失去了主分片1 和2 并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况我们看到的状态将会为red 不是所有主分片都在正常工作。幸运的是在其它节点上存在着这两个主分片的完整副本所以新的主节点立即将这些分片在Node 2 和Node 3 上对应的副本分片提升为主分片。这个提升主分片的过程是瞬间发生的如同按下一个开关一般。2.5 路由计算当索引一个文档的时候文档会被存储到一个主分片中。Elasticsearch 如何知道一个文档应该存放到哪个分片中呢当我们创建文档时它如何决定这个文档应当被存储在分片1 还是分片2 中呢首先这肯定不会是随机的否则将来要获取文档的时候我们就不知道从何处寻找了。实际上这个过程是根据下面这个公式决定的routing 是一个可变值默认是文档的_id 也可以设置成一个自定义的值。routing 通过hash 函数生成一个数字然后这个数字再除以number_of_primary_shards 主分片的数量后得到余数。这个分布在0 到number_of_primary_shards-1 之间的余数就是我们所寻求的文档所在分片的位置。这也是为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量的原因因为如果数量变化了那么所有之前路由的值都会无效文档也再也找不到了。所有的文档APIget 、index 、delete 、bulk 、update 以及mget 都接受一个叫做routing 的路由参数通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。2.6 es节点特性我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置所以可以直接将请求转发到需要的节点上每个节点都能扮演协调节点(coordinating node) 角色。当发送请求的时候为了扩展负载更好的做法是轮询集群中所有的节点。3.elasticsearch增删改查操作流程3.1 写流程我们向三个节点组成集群中一个有2个分片每个分片2个副本的索引中写文档数据流程如下图所示具体流程执行步骤1客户端向Node 1 发送新建、索引或者删除请求。此时 node 1就是我们的协调节点2节点使用文档的_id 确定文档属于分片0 。请求会被转发到Node 3因为分片0 的主分片目前被分配在Node 3 上。3Node 3 在主分片上面执行请求。如果成功了它将请求并行转发到Node 1 和Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功协调节点向客户端报告成功。3.2 读文档我们可以从主分片或者从其它任意副本分片检索文档具体步骤如下1客户端向Node 1 发送获取请求。2 节点使用文档的_id 来确定文档属于分片0 。分片0 的副本分片存在于所有的三个节点上。在这种情况下协调节点通过轮训方式访问分片节点这里假设它将请求转发到Node 2 。3 Node 2 将文档返回给Node 1 然后将文档返回给客户端。在处理读取请求时协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。在文档被检索时已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。在这种情况下副本分片可能会报告文档不存在但是主分片可能成功返回文档。一旦索引请求成功返回给用户文档在主分片和副本分片都是可用的。3.3 更新文档es的更新文档其实就是结合读流程和写流程如下所示部分更新一个文档的步骤如下1客户端向Node 1 发送更新请求。2 它将请求转发到主分片所在的Node 3 。3Node 3 从主分片检索文档修改_source 字段中的JSON 并且尝试重新索引主分片的文档。如果文档已经被另一个进程修改它会重试步骤3 超过retry_on_conflict 次后放弃。4如果Node 3 成功地更新文档它将新版本的文档并行转发到Node 1 和Node 2 上的副本分片重新建立索引。一旦所有副本分片都返回成功Node 3 向协调节点也返回成功协调节点向客户端返回成功。当主分片把更改转发到副本分片时它不会转发更新请求。相反它转发完整文档的新版本。请记住这些更改将会异步转发到副本分片并且不能保证它们以发送它们相同的顺序到达。如果Elasticsearch仅转发更改请求则可能以错误的顺序应用更改导致得到损坏的文档。4.倒排索引和文档存储4.1 倒排索引传统的数据库每个字段存储单个值但这对全文检索并不够。文本字段中的每个单词需要被搜索对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值需求的数据结构是倒排索引。Elasticsearch 使用一种称为倒排索引的结构它适用于快速的全文搜索。见其名知其意有倒排索引肯定会对应有正向索引。正向索引forward index反向索引inverted index更熟悉的名字是倒排索引。所谓的正向索引就是搜索引擎会将待搜索的文件都对应一个文件ID搜索时将这个ID和搜索关键字进行对应形成K-V对然后对关键字进行统计计数。但是互联网上收录在搜索引擎中的文档的数目是个天文数字这样的正向索引结构根本无法满足实时返回排名结果的要求。所以搜索引擎会将正向索引重新构建为倒排索引即把文件ID对应到关键词的映射转换为关键词到文件ID的映射每个关键词都对应着一系列的文件这些文件中都出现这个关键词。一个倒排索引由文档中所有不重复词的列表构成对于其中每个词有一个包含它的文档列表。例如假设我们有两个文档每个文档的content 域包含如下内容The quick brown fox jumped over the lazy dogQuick brown foxes leap over lazy dogs in summer为了创建倒排索引我们首先将每个文档的content 域拆分成单独的词我们称它为词条或tokens 创建一个包含所有不重复词条的排序列表然后列出每个词条出现在哪个文档。4.2 倒排索引不变性早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。一旦新的索引就绪旧的就会被其替换这样最近的变化便可以被检索到。倒排索引被写入磁盘后是不可改变的:它永远不会修改。不变性有重要的价值不需要锁。如果你从来不更新索引你就不需要担心多进程同时修改数据的问题。一旦索引被读入内核的文件系统缓存便会留在那里由于其不变性。只要文件系统缓存中还有足够的空间那么大部分读请求会直接请求内存而不会命中磁盘。这提供了很大的性能提升。其它缓存(像filter缓存)在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建因为数据不会变化。写入单个大的倒排索引允许数据被压缩减少磁盘I/O 和需要被缓存到内存的索引的使用量。当然一个不变的索引也有不好的地方。主要事实是它是不可变的你不能修改它。如果你需要让一个新的文档可被搜索你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制要么对索引可被更新的频率造成了很大的限制。4.3 动态更新索引如何在保留不变性的前提下实现倒排索引的更新答案是: 用更多的索引。通过增加新的补充索引来反映新近的修改而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到从最早的开始查询完后再对结果进行合并。Elasticsearch 基于Lucene, 这个java库引入了按段搜索的概念。每一段本身都是一个倒排索引但索引在Lucene 中除表示所有段的集合外还增加了提交点的概念提交点就是一个列出了所有已知段的文件。按段搜索会以如下流程执行1新文档被收集到内存索引缓存如下所示一个在内存缓存中包含新文档的 Lucene 索引2不时地缓存会被提交一个新的段一个追加的倒排索引被写入磁盘。一个新的包含新段名字的提交点被写入磁盘。磁盘进行 同步 所有在文件系统缓存中等待的写入都刷新到磁盘以确保它们被写入物理文件。3新的段被开启让它包含的文档可见以被搜索。4内存缓存被清空等待接收新的文档。当一个查询被触发所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合以保证每个词和每个文档的关联都被准确计算。这种方式可以用相对较低的成本将新文档添加到索引。4.4 文档删除和更新段是不可改变的所以既不能把文档从旧的段中移除也不能修改旧的段来进行反映文档的更新。取而代之的是每个提交点会包含一个 .del 文件文件中会列出这些被删除文档的段信息。当一个文档被 “删除” 时它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到 但它会在最终结果被返回前从结果集中移除。文档更新也是类似的操作方式当一个文档被更新时旧版本文档被标记删除文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到但被删除的那个旧版本文档在结果集返回前就已经被移除。4.5 elasticsearch近实时搜索随着按段per-segment搜索的发展一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索但这样还是不够快。磁盘在这里成为了瓶颈。提交Commiting一个新的段到磁盘需要一个fsync(同步内存中所有已修改的文件数据到储存设备) 来确保段被物理性地写入磁盘这样在断电的时候就不会丢失数据。但是fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。我们需要的是一个更轻量的方式来使一个文档可被搜索这意味着fsync 要从整个过程中被移除。在Elasticsearch和磁盘之间是文件系统缓存。像之前描述的一样在内存索引缓冲区中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存—这一步代价会比较低稍后再被刷新到磁盘—这一步代价比较高。不过只要文件已经在缓存中就可以像其它文件一样被打开和读取了。Lucene 允许新段被写入和打开从而使其包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次完整提交代价要小得多并且在不影响性能的前提下可以被频繁地执行。如下所示缓冲区的内容已经被写入一个可被搜索的段中但还没有进行提交在Elasticsearch 中写入和打开一个新段的轻量的过程叫做refresh 。默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说Elasticsearch 是近实时搜索: 文档的变化并不是立即对搜索可见但会在一秒之内变为可见。并不是所有的情况都需要每秒刷新。可能你正在使用Elasticsearch 索引大量的日志文件你可能想优化索引速度而不是近实时搜索可以通过设置refresh_interval 降低每个索引的刷新频率PUT /my_logs{ settings: { refresh_interval: 30s }}refresh_interval 可以在既存索引上进行动态更新。在生产环境中当你正在建立一个大的新索引时可以先关闭自动刷新待开始使用该索引时再把它们调回来:PUT /my_logs/_settings{ refresh_interval: -1 } PUT /my_logs/_settings{ refresh_interval: 1s } 4.6 持久化如果没有用 fsync 把数据从文件系统缓存刷flush到硬盘我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性需要确保数据变化被持久化到磁盘。在前面我们说过一次完整的提交会将段刷到磁盘并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。即使通过每秒刷新refresh实现了近实时搜索我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办我们也不希望丢失掉这些数据。Elasticsearch 增加了一个 translog 或者叫事务日志在每一次对 Elasticsearch 进行操作时均进行了日志记录。通过 translog 整个流程看起来是下面这样1一个文档被索引之后就会被添加到内存缓冲区并且追加到了translog2刷新refresh分片每秒被刷新refresh一次这些在内存缓冲区的文档被写入到一个新的段中且没有进行fsync 操作。这个段被打开使其可被搜索内存缓冲区被清空3这个进程继续工作更多的文档被添加到内存缓冲区和追加到事务日志事务日志不断积累文档4每隔一段时间—例如translog 变得越来越大—索引被刷新flush一个新的translog 被创建并且一个全量提交被执行所有在内存缓冲区的文档都被写入一个新的段。缓冲区被清空。一个提交点被写入硬盘。文件系统缓存通过fsync 被刷新flush。老的translog 被删除。translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当Elasticsearch 启动的时候它会从磁盘中使用最后一个提交点去恢复已知的段并且会重放translog 中所有在最后一次提交后发生的变更操作。translog 也被用来提供实时CRUD 。当你试着通过ID查询、更新、删除一个文档它会在尝试从相应的段中检索之前首先检查translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。执行一个提交并且截断translog 的行为在Elasticsearch 被称作一次flush。分片每30分钟被自动刷新flush或者在translog 太大的时候也会刷新.translog 的目的是保证操作不会丢失。这引出了这个问题Translog 有多安全在文件被 fsync 到磁盘前被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终 基本上这意味着在整个请求被 fsync 到主分片和复制分片的translog之前你的客户端不会得到一个 200 OK 响应。在每次请求后都执行一个 fsync 会带来一些性能损失尽管实践表明这种损失相对较小特别是bulk导入它在一次请求中平摊了大量文档的开销。但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群使用异步的 fsync 还是比较有益的。比如写入的数据被缓存到内存中再每5秒执行一次 fsync 。这个行为可以通过设置 durability 参数为 async 来启用:PUT /my_index/_settings{ index.translog.durability: async, index.translog.sync_interval: 5s}这个选项可以针对索引单独设置并且可以动态进行修改。如果你决定使用异步 translog 的话你需要 保证 在发生crash时丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。如果你不确定这个行为的后果最好是使用默认的参数 index.translog.durability: request 来避免数据丢失。4.7 段合并由于自动刷新流程每秒会创建一个新的段这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是每个搜索请求都必须轮流检查每个段所以段越多搜索也就越慢。Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档或被更新文档的旧版本不会被拷贝到新的大段中。启动段合并不需要你做任何事。进行索引和搜索时会自动进行。1当索引的时候刷新refresh操作会创建新的段并将段打开以供搜索使用。2合并进程选择一小部分大小相似的段并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。3一旦合并结束老的段被删除新的段被刷新flush到了磁盘。写入一个包含新段且排除旧的和较小的段的新提交点。新的段被打开用来搜索。老的段被删除。合并大的段需要消耗大量的I/O和CPU资源如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制所以搜索仍然有足够的资源很好地执行。4.8 文档分析我们前面讲到写入一个新文档首先要对文档内容进行词条分析然后再创建倒排索引。分析包含下面的过程1将一块文本分成适合于倒排索引的独立的词条2将这些词条统一化为标准格式以提高它们的“可搜索性”或者recall分析器执行上面的工作。分析器实际上是将三个功能封装到了一个包里字符过滤器首先字符串按顺序通过每个字符过滤器。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML或者将 转化成and等等。分词器其次字符串被分词器分为单个的词条。一个简单的分词器遇到空格和标点的时候可能会将文本拆分成词条。Token过滤器最后词条按顺序通过每个token 过滤器。这个过程可能会改变词条例如小写化Quick 删除词条例如像aandthe 等无用词或者增加词条例如像jump 和leap 这种同义词。5.elasticsearch优化建议5.1 硬件选择Elasticsearch的基础是Lucene所有的索引和文档数据是存储在本地的磁盘中具体的路径可在ES 的配置文件../config/elasticsearch.yml中配置如下# ----------------------------------- Paths ------------------------------------## Path to directory where to store the data (separate multiple locations by comma):##path.data: /path/to/data## Path to log files:##path.logs: /path/to/logs#磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘你的磁盘能处理的吞吐量越大你的节点就越稳定。这里有一些优化磁盘I/O 的技巧1使用SSD。就像其他地方提过的他们比机械磁盘优秀多了。2使用RAID 0。条带化RAID 会提高磁盘I/O代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验RAID 因为副本已经提供了这个功能。3另外使用多块硬盘并允许Elasticsearch 通过多个path.data 目录配置把数据条带化分配到它们上面。4不要使用远程挂载的存储比如NFS 或者SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰5.2 分片策略5.2.1 设置合理分片数分片和副本的设计为ES 提供了支持分布式和故障转移的特性但并不意味着分片和副本是可以无限分配的。而且索引的分片完成分配后由于索引的路由机制我们是不能重新修改分片数的。可能有人会说我不知道这个索引将来会变得多大并且过后我也不能更改索引的大小所以为了保险起见还是给它设为1000 个分片吧。但是需要知道的是一个分片并不是没有代价的。需要了解1一个分片的底层即为一个Lucene 索引会消耗一定文件句柄、内存、以及CPU 。2每一个搜索请求都需要命中索引中的每一个分片如果每一个分片都处于不同的节点还好但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。3用于计算相关度的词项统计信息是基于分片的。如果有许多分片每一个都只有很少的数据会导致很低的相关度。一个业务索引具体需要分配多少分片可能需要架构师和技术人员对业务的增长有个预先的判断横向扩展应当分阶段进行。为下一阶段准备好足够的资源。只有当你进入到下一个阶段你才有时间思考需要作出哪些改变来达到这个阶段。一般来说我们遵循一些原则1控制每个分片占用的硬盘容量不超过ES的最大JVM的堆空间设置一般设置不超过32G参考下文的JVM设置原则因此如果索引的总容量在500G左右那分片大小在16个左右即可当然最好同时考虑原则2。2考虑一下node数量一般一个节点有时候就是一台物理机如果分片数过多大大超过了节点数很可能会导致一个节点上存在多个分片一旦该节点故障即使保持了1个以上的副本同样有可能会导致数据丢失集群无法恢复。所以一般都设置分片数不超过节点数的3倍。3主分片副本和节点最大数之间数量我们分配的时候可以参考以下关系节点数主分片数*副本数15.2.2 推迟分片分配对于节点瞬时中断的问题默认情况集群会等待一分钟来查看节点是否会重新加入如果这个节点在此期间重新加入重新加入的节点会保持其现有的分片数据不会触发新的分片分配。这样就可以减少ES 在自动再平衡可用分片时所带来的极大开销。通过修改参数delayed_timeout 可以延长再均衡的时间可以全局设置也可以在索引级别进行修改:PUT /_all/_settings{settings: { index.unassig ned.node_left.delayed_timeout: 5m }}5.3 路由选择当我们查询文档的时候Elasticsearch 如何知道一个文档应该存放到哪个分片中呢它其实是通过下面这个公式来计算出来:shard hash(routing) % number_of_primary_shardsrouting 默认值是文档的id也可以采用自定义值比如用户id不带routing 查询在查询的时候因为不知道要查询的数据具体在哪个分片上所以整个过程分为2 个步骤1分发请求到达协调节点后协调节点将查询请求分发到每个分片上。2聚合: 协调节点搜集到每个分片上查询结果在将查询的结果进行排序之后给用户返回结果。带routing 查询查询的时候可以直接根据routing 信息定位到某个分配查询不需要查询所有的分配经过协调节点排序。向上面自定义的用户查询如果routing 设置为userid 的话就可以直接查询出数据来效率提升很多。5.4 文档写入速度优化ES的默认配置是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时我们需要根据公司要求进行偏向性的优化。针对于搜索性能要求不高但是对写入要求较高的场景我们需要尽可能的选择恰当写优化策略。综合来说可以考虑以下几个方面来提升写索引的性能1加大Translog Flush 目的是降低Iops、Writeblock。2增加Index Refresh 间隔目的是减少Segment Merge 的次数。3调整Bulk 线程池和队列。4优化节点间的任务分布。5优化Lucene 层的索引建立目的是降低CPU 及IO。Lucene 以段的形式存储数据。当有新的数据写入索引时Lucene 就会自动创建一个新的段。随着数据量的变化段的数量会越来越多消耗的多文件句柄数及CPU 就越多查询效率就会下降。由于Lucene 段合并的计算量庞大会消耗大量的I/O所以ES 默认采用较保守的策略让后台定期进行段合并。Lucene 在新增数据时采用了延迟写入的策略默认情况下索引的refresh_interval 为1 秒。Lucene 将待写入的数据先写到内存中超过1 秒默认时就会触发一次Refresh然后Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。如果我们对搜索的实效性要求不高可以将Refresh 周期延长例如30 秒。这样还可以有效地减少段刷新次数但这同时意味着需要消耗更多的Heap内存。Flush 的主要目的是把文件缓存系统中的段持久化到硬盘当Translog 的数据量达到512MB 或者30 分钟时会触发一次Flush。index.translog.flush_threshold_size 参数的默认值是512MB我们进行修改。增加参数值意味着文件缓存系统中可能需要存储更多的数据所以我们需要为操作系统的文件缓存系统留下足够的空间。ES 为了保证集群的可用性提供了Replicas副本支持然而每个副本也会执行分析、索引及可能的合并过程所以Replicas 的数量会严重影响写索引的效率。当写索引时需要把写入的数据都同步到副本节点副本节点越多写索引的效率就越慢。如果我们需要大批量进行写入操作可以先禁止Replica 复制设置index.number_of_replicas: 0 关闭副本。在写入完成后Replica 修改回正常的状态。5.5 内存配置ES 默认安装后设置的内存是1GB对于任何一个现实业务来说这个设置都太小了。如果是通过解压安装的ES则在ES 安装文件中包含一个jvm.option 文件添加如下命令来设置ES 的堆大小Xms 表示堆的初始大小Xmx 表示可分配的最大内存都是1GB。确保Xmx 和Xms 的大小是相同的其目的是为了能够在Java 垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源可以减轻伸缩堆大小带来的压力。假设你有一个64G 内存的机器按照正常思维思考你可能会认为把64G 内存都给ES 比较好但现实是这样吗越大越好虽然内存对ES 来说是非常重要的但是答案是否定的因为ES 堆内存的分配需要满足以下两个原则1不要超过物理内存的50%Lucene 的设计目的是把底层OS 里的数据缓存到内存中。Lucene 的段是分别存储到单个文件中的这些文件都是不会变化的所以很利于缓存同时操作系统也会把这些段文件缓存起来以便更快的访问。如果我们设置的堆内存过大Lucene 可用的内存将会减少就会严重影响降低Lucene 的全文本查询性能。2堆内存的大小最好不要超过32GB在Java 中所有对象都分配在堆上然后有一个Klass Pointer 指针指向它的类元数据。这个指针在64 位的操作系统上为64 位64 位的操作系统可以使用更多的内存2^64。在32 位的系统上为32 位32 位的操作系统的最大寻址空间为4GB2^32。但是64 位的指针意味着更大的浪费因为你的指针本身大了。浪费内存不算更糟糕的是更大的指针在主内存和缓存器例如LLC, L1等之间移动数据的时候会占用更多的带宽。最终我们都会采用31 G 设置-Xms 31g-Xmx 31g假设你有个机器有128 GB 的内存你可以创建两个节点每个节点内存分配不超过32 GB。也就是说不超过64 GB 内存给ES 的堆内存剩下的超过64 GB 的内存给Lucene
