【稿件】Elasticsearch 基于 Lucene,隐藏其复杂性,并提供简单易用的 Restful API接口、Java API 接口。所以理解 ES 的关键在于理解 Lucene 的基本原理。
Lucene 简介
Lucene 是一种高性能、可伸缩的信息搜索(IR)库,在 2000 年开源,最初由鼎鼎大名的 Doug Cutting 开发,是基于 Java 实现的高性能的开源项目。
Lucene 采用了基于倒排表的设计原理,可以非常高效地实现文本查找,在底层采用了分段的存储模式,使它在读写时几乎完全避免了锁的出现,大大提升了读写性能。
核心模块
Lucene 的写流程和读流程如下图所示:
图 1:Lucene 的写流程和读流程
其中,虚线箭头(a、b、c、d)表示写索引的主要过程,实线箭头(1-9)表示查询的主要过程。
Lucene 中的主要模块及模块说明如下:
核心术语
下面介绍 Lucene 中的核心术语:
比如:排序数组通过二分查找来检索数据:HashMap(哈希表)比排序数组的检索速度更快,但是会浪费存储空间。
FST(finite-state transducer)有更高的数据压缩率和查询效率,因为词典是常驻内存的,而 FST 有很好的压缩率,所以 FST 在 Lucene 当前版本中有非常多的使用场景,也是默认的词典数据结构。
Lucene 的底层存储格式如下图所示,由词典和倒排序两部分组成,其中的词典就是 Term 的集合:
图 2:Lucene 的底层存储格式
词典中的 Term 指向的文档链表的集合,叫做倒排表。词典和倒排表是 Lucene 中很重要的两种数据结构,是实现快速检索的重要基石。
词典和倒排表是分两部分存储的,在倒排序中不但存储了文档编号,还存储了词频等信息。
在上图所示的词典部分包含三个词条(Term):Elasticsearch、Lucene 和 Solr。词典数据是查询的入口,所以这部分数据是以 FST 的形式存储在内存中的。
在倒排表中,“Lucene”指向有序链表 3,7,15,30,35,67,表示字符串“Lucene”在文档编号为3、7、15、30、35、67的文章中出现过,Elasticsearch 和 Solr 同理。
检索方式
在 Lucene 的查询过程中的主要检索方式有以下四种:
①单个词查询
指对一个 Term 进行查询。比如,若要查找包含字符串“Lucene”的文档,则只需在词典中找到 Term“Lucene”,再获得在倒排表中对应的文档链表即可。
②AND
指对多个集合求交集。比如,若要查找既包含字符串“Lucene”又包含字符串“Solr”的文档,则查找步骤如下:
③OR
指多个集合求并集。比如,若要查找包含字符串“Luence”或者包含字符串“Solr”的文档,则查找步骤如下:
④NOT
指对多个集合求差集。比如,若要查找包含字符串“Solr”但不包含字符串“Lucene”的文档,则查找步骤如下:
通过上述四种查询方式,我们不难发现,由于 Lucene 是以倒排表的形式存储的。
所以在 Lucene 的查找过程中只需在词典中找到这些 Term,根据 Term 获得文档链表,然后根据具体的查询条件对链表进行交、并、差等操作,就可以准确地查到我们想要的结果。
相对于在关系型数据库中的“Like”查找要做全表扫描来说,这种思路是非常高效的。
虽然在索引创建时要做很多工作,但这种一次生成、多次使用的思路也是非常高明的。
分段存储
在早期的全文检索中为整个文档集合建立了一个很大的倒排索引,并将其写入磁盘中,如果索引有更新,就需要重新全量创建一个索引来替换原来的索引。
这种方式在数据量很大时效率很低,并且由于创建一次索引的成本很高,所以对数据的更新不能过于频繁,也就不能保证实效性。
现在,在搜索中引入了段的概念(将一个索引文件拆分为多个子文件,则每个子文件叫做段),每个段都是一个独立的可被搜索的数据集,并且段具有不变性,一旦索引的数据被写入硬盘,就不可修改。
在分段的思想下,对数据写操作的过程如下:
当查询时,被删除的数据还是可以被查到的,只是在进行文档链表合并时,才把已经删除的数据过滤掉。被删除的数据在进行段合并时才会被真正被移除。
段不可变性的优点如下:
段不可变性的缺点如下:
为了提升写的性能,Lucene 并没有每新增一条数据就增加一个段,而是采用延迟写的策略,每当有新增的数据时,就将其先写入内存中,然后批量写入磁盘中。
若有一个段被写到硬盘,就会生成一个提交点,提交点就是一个用来记录所有提交后的段信息的文件。
一个段一旦拥有了提交点,就说明这个段只有读的权限,失去了写的权限;相反,当段在内存中时,就只有写数据的权限,而不具备读数据的权限,所以也就不能被检索了。
从严格意义上来说,Lucene 或者 Elasticsearch 并不能被称为实时的搜索引擎,只能被称为准实时的搜索引擎。
写索引的流程如下:
当然,默认的时间和数据量的大小是可以通过参数控制的。通过延时写的策略,可以减少数据往磁盘上写的次数,从而提升整体的写入性能,如图 3。
图 3:Elasticsearch 写索引
从上述流程可以看出,数据先被暂时缓存在内存中,在达到一定的条件再被一次性写入硬盘中,这种做法可以大大提升数据写入的书单。
但是数据先被暂时存放在内存中,并没有真正持久化到磁盘中,所以如果这时出现断电等不可控的情况,就会丢失数据,为此,Elasticsearch 添加了事务日志,来保证数据的安全。
段合并策略
虽然分段比每次都全量创建索引有更高的效率,但是由于在每次新增数据时都会新增一个段,所以经过长时间的的积累,会导致在索引中存在大量的段。
当索引中段的数量太多时,不仅会严重消耗服务器的资源,还会影响检索的性能。
因为索引检索的过程是:查询所有段中满足查询条件的数据,然后对每个段里查询的结果集进行合并,所以为了控制索引里段的数量,我们必须定期进行段合并操作。
但是如果每次合并全部的段,则会造成很大的资源浪费,特别是“大段”的合并。
所以 Lucene 现在的段合并思路是:根据段的大小将段进行分组,再将属于同一组的段进行合并。
但是由于对于超级大的段的合并需要消耗更多的资源,所以 Lucene 会在段的大小达到一定规模,或者段里面的数据量达到一定条数时,不会再进行合并。
所以 Lucene 的段合并主要集中在对中小段的合并上,这样既可以避免对大段进行合并时消耗过多的服务器资源,也可以很好地控制索引中段的数量。
段合并的主要参数如下:
段合并相关的动作主要有以下两个:
在段合并前对段的大小进行了标准化处理,通过 logMergeFactorSegmentSize 计算得出。
其中 MergeFactor 表示一次合并的段的数量,Lucene 默认该数量为 10;SegmentSize 表示段的实际大小。通过上面的公式计算后,段的大小更加紧凑,对后续的分组更加友好。
段分组的步骤如下:
①根据段生成的时间对段进行排序,然后根据上述标准化公式计算每个段的大小并且存放到段信息中,后面用到的描述段大小的值都是标准化后的值,如图 4 所示:
图 4:Lucene 段排序
②在数组中找到段,然后生成一个由段的标准化值作为上限,减去 LEVEL_LOG_SPAN(默认值为 0.75)后的值作为下限的区间,小于等于上限并且大于下限的段,都被认为是属于同一组的段,可以合并。
③在确定一个分组的上下限值后,就需要查找属于这个分组的段了,具体过程是:创建两个指针(在这里使用指针的概念是为了更好地理解)start 和 end。
start 指向数组的第 1 个段,end 指向第 start+MergeFactor 个段,然后从 end 逐个向前查找落在区间的段。
当找到第 1 个满足条件的段时,则停止,并把当前段到 start 之间的段统一分到一个组,无论段的大小是否满足当前分组的条件。
如图 5 所示,第 2 个段明显小于该分组的下限,但还是被分到了这一组。
图 5:Lucene 段分组
这样做的好处如下:
④在分组找到后,需要排除不参加合并的“超大”段,然后判断剩余的段是否满足合并的条件。
如图 5 所示,mergeFactor=5,而找到的满足合并条件的段的个数为 4,所以不满足合并的条件,暂时不进行合并,继续找寻下一个组的上下限。
⑤由于在第 4 步并没有找到满足段合并的段的数量,所以这一分组的段不满足合并的条件,继续进行下一分组段的查找。
具体过程是:将 start 指向 end,在剩下的段中寻找大的段,在找到大的值后再减去 LEVEL_LOG_SPAN 的值,再生成一下分组的区间值。
然后把 end 指向数组的第 start+MergeFactor 个段,逐个向前查找第 1 个满足条件的段:重复第 3 步和第 4 步。
⑥如果一直没有找到满足合并条件的段,则一直重复第 5 步,直到遍历完整个数组,如图 6 所示:
图 6:Lucene 段分组二
⑦在找到满足条件的 mergeFactor 个段时,就需要开始合并了。但是在满足合并条件的段大于 mergeFactor 时,就需要进行多次合并。
也就是说每次依然选择 mergeFactor 个段进行合并,直到该分组的所有段合并完成,再进行下一分组的查找合并操作。
⑧通过上述几步,如果找到了满足合并要求的段,则将会进行段的合并操作。
因为索引里面包含了正向信息和反向信息,所以段合并的操作分为两部分:
在段合并时,除了需要对索引数据进行合并,还需要移除段中已经删除的数据。
Lucene 相似度打分
我们在前面了解到,Lucene 的查询过程是:首先在词典中查找每个 Term,根据 Term 获得每个 Term 所在的文档链表;然后根据查询条件对链表做交、并、差等操作,链表合并后的结果集就是我们要查找的数据。
这样做可以完全避免对关系型数据库进行全表扫描,可以大大提升查询效率。
但是,当我们一次查询出很多数据时,这些数据和我们的查询条件又有多大关系呢?其文本相似度是多少?
本节会回答这个问题,并介绍 Lucene 最经典的两个文本相似度算法:基于向量空间模型的算法和基于概率的算法(BM25)。
如果对此算法不太感兴趣,那么只需了解对文本相似度有影响的因子有哪些,哪些是正向的,哪些是逆向的即可,不需要理解每个算法的推理过程。但是这两个文本相似度算法有很好的借鉴意义。
Elasticsearch 简介
Elasticsearch 是使用 Java 编写的一种开源搜索引擎,它在内部使用 Luence 做索引与搜索,通过对 Lucene 的封装,提供了一套简单一致的 RESTful API。
Elasticsearch 也是一种分布式的搜索引擎架构,可以很简单地扩展到上百个服务节点,并支持 PB 级别的数据查询,使系统具备高可用和高并发性。
核心概念
在一个多分片的索引中写入数据时,通过路由来确定具体写入那一个分片中,所以在创建索引时需要指定分片的数量,并且分片的数量一旦确定就不能更改。
分片后的索引带来了规模上(数据水平切分)和性能上(并行执行)的提升。每个分片都是 Luence 中的一个索引文件,每个分片必须有一个主分片和零到多个副本分片。
当主分片不可用时,会在备份的分片中选举出一个作为主分片,所以备份不仅可以提升系统的高可用性能,还可以提升搜索时的并发性能。但是若副本太多的话,在写操作时会增加数据同步的负担。
如果没有特殊需求,则不需要手动创建 Mapping,因为 Elasticsearch 会自动根据数据格式识别它的类型,但是当需要对某些字段添加特殊属性(比如:定义使用其他分词器、是否分词、是否存储等)时,就需要手动设置 Mapping 了。一个索引的 Mapping 一旦创建,若已经存储了数据,就不可修改了。
比如默认的标准 Analyzer 包含一个标准的 Tokenizer 和三个 Filter:Standard Token Filter、Lower Case Token Filter、Stop Token Filter。
Elasticsearch 的节点的分类如下:
①主节点(Master Node):也叫作主节点,主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch 中的主节点的工作量相对较轻。
用户的请求可以发往任何一个节点,并由该节点负责分发请求、收集结果等操作,而并不需要经过主节点转发。
通过在配置文件中设置 node.master=true 来设置该节点成为候选主节点(但该节点不一定是主节点,主节点是集群在候选节点中选举出来的),在 Elasticsearch 集群中只有候选节点才有选举权和被选举权。其他节点是不参与选举工作的。
②数据节点(Data Node):数据节点,负责数据的存储和相关具体操作,比如索引数据的创建、修改、删除、搜索、聚合。
所以,数据节点对机器配置要求比较高,首先需要有足够的磁盘空间来存储数据,其次数据操作对系统 CPU、Memory 和 I/O 的性能消耗都很大。
通常随着集群的扩大,需要增加更多的数据节点来提高可用性。通过在配置文件中设置 node.data=true 来设置该节点成为数据节点。
③客户端节点(Client Node):就是既不做候选主节点也不做数据节点的节点,只负责请求的分发、汇总等,也就是下面要说到的协调节点的角色。
其实任何一个节点都可以完成这样的工作,单独增加这样的节点更多地是为了提高并发性。
可在配置文件中设置该节点成为数据节点:
- node.master=false
- node.data=false
④部落节点(Tribe Node):部落节点可以跨越多个集群,它可以接收每个集群的状态,然后合并成一个全局集群的状态。
它可以读写所有集群节点上的数据,在配置文件中通过如下设置使节点成为部落节点:
- tribe:
- one:
- cluster.name: cluster_one
- two:
- cluster.name: cluster_two
因为 Tribe Node 要在 Elasticsearch 7.0 以后移除,所以不建议使用。
⑤协调节点(Coordinating Node):协调节点,是一种角色,而不是真实的 Elasticsearch 的节点,我们没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点都可以充当协调节点的角色。
当一个节点 A 收到用户的查询请求后,会把查询语句分发到其他的节点,然后合并各个节点返回的查询结果,返回一个完整的数据集给用户。
在这个过程中,节点 A 扮演的就是协调节点的角色。由此可见,协调节点会对 CPU、Memory 和 I/O 要求比较高。
集群的状态有 Green、Yellow 和 Red 三种,如下所述:
这时虽然集群的查询操作还可以进行,但是也只能返回部分数据(其他正常分片的数据可以返回),而分配到这个分片上的写入请求将会报错,最终会导致数据的丢失。
3C 和脑裂
①共识性(Consensus)
共识性是分布式系统中最基础也最主要的一个组件,在分布式系统中的所有节点必须对给定的数据或者节点的状态达成共识。
虽然现在有很成熟的共识算法如 Raft、Paxos 等,也有比较成熟的开源软件如 Zookeeper。
但是 Elasticsearch 并没有使用它们,而是自己实现共识系统 zen discovery。
Elasticsearch 之父 Shay Banon 解释了其中主要的原因:“zen discovery是 Elasticsearch 的一个核心的基础组件,zen discovery 不仅能够实现共识系统的选择工作,还能够很方便地监控集群的读写状态是否健康。当然,我们也不保证其后期会使用 Zookeeper 代替现在的 zen discovery”。
zen discovery 模块以“八卦传播”(Gossip)的形式实现了单播(Unicat):单播不同于多播(Multicast)和广播(Broadcast)。节点间的通信方式是一对一的。
②并发(Concurrency)
Elasticsearch 是一个分布式系统。写请求在发送到主分片时,同时会以并行的形式发送到备份分片,但是这些请求的送达时间可能是无序的。
在这种情况下,Elasticsearch 用乐观并发控制(Optimistic Concurrency Control)来保证新版本的数据不会被旧版本的数据覆盖。
乐观并发控制是一种乐观锁,另一种常用的乐观锁即多版本并发控制(Multi-Version Concurrency Control)。
它们的主要区别如下:
这样在读操作不用阻塞操作且写操作不用阻塞读操作的同时,避免了脏读和不可重复读。
③一致性(Consistency)
Elasticsearch 集群保证写一致性的方式是在写入前先检查有多少个分片可供写入,如果达到写入条件,则进行写操作,否则,Elasticsearch 会等待更多的分片出现,默认为一分钟。
有如下三种设置来判断是否允许写操作:
Elasticsearch 集群保证读写一致性的方式是,为了保证搜索请求的返回结果是当前版本的文档,备份可以被设置为 Sync(默认值),写操作在主分片和备份分片同时完成后才会返回写请求的结果。
这样,无论搜索请求至哪个分片都会返回文档。但是如果我们的应用对写要求很高,就可以通过设置 replication=async 来提升写的效率,如果设置 replication=async,则只要主分片的写完成,就会返回写成功。
④脑裂
在 Elasticsearch 集群中主节点通过 Ping 命令来检查集群中的其他节点是否处于可用状态,同时非主节点也会通过 Ping 来检查主节点是否处于可用状态。
当集群网络不稳定时,有可能会发生一个节点 Ping 不通 Master 节点,则会认为 Master 节点发生了故障,然后重新选出一个 Master 节点,这就会导致在一个集群内出现多个 Master 节点。
当在一个集群中有多个 Master 节点时,就有可能会导致数据丢失。我们称这种现象为脑裂。
事务日志
我们在上面了解到,Lucene 为了加快写索引的速度,采用了延迟写入的策略。
虽然这种策略提高了写入的效率,但其弊端是,如果数据在内存中还没有持久化到磁盘上时发生了类似断电等不可控情况,就可能丢失数据。
为了避免丢失数据,Elasticsearch 添加了事务日志(Translog),事务日志记录了所有还没有被持久化磁盘的数据。
Elasticsearch 写索引的具体过程如下:首先,当有数据写入时,为了提升写入的速度,并没有数据直接写在磁盘上,而是先写入到内存中,但是为了防止数据的丢失,会追加一份数据到事务日志里。
因为内存中的数据还会继续写入,所以内存中的数据并不是以段的形式存储的,是检索不到的。
总之,Elasticsearch 是一个准实时的搜索引擎,而不是一个实时的搜索引擎。
此时的状态如图 7 所示:
图 7:Elasticsearch 写数据的过程
然后,当达到默认的时间(1 秒钟)或者内存的数据达到一定量时,会触发一次刷新(Refresh)。
刷新的主要步骤如下:
内存使用的是 JVM 的内存,而文件缓存系统使用的是操作系统的内存;内存的数据不是以段的形式存储的,并且可以继续向内存里写数据。文件缓存系统中的数据是以段的形式存储的,所以只能读,不能写;内存中的数据是搜索不到,文件缓存系统中的数据是可以搜索的。
此时的状态如图 8 所示:
图 8:Elasticsearch 写数据的过程
刷新(Flush)。当日志数据的大小超过 512MB 或者时间超过 30 分钟时,需要触发一次刷新。
刷新的主要步骤如下:
此时的状态如图 9 所示:
图 9:Elasticsearch 写数据的过程
由上面索引创建的过程可知,内存里面的数据并没有直接被刷新(Flush)到硬盘中,而是被刷新(Refresh)到了文件缓存系统中,这主要是因为持久化数据十分耗费资源,频繁地调用会使写入的性能急剧下降。
所以 Elasticsearch,为了提高写入的效率,利用了文件缓存系统和内存来加速写入时的性能,并使用日志来防止数据的丢失。
在需要重启时,Elasticsearch 不仅要根据提交点去加载已经持久化过的段,还需要根据 Translog 里的记录,把未持久化的数据重新持久化到磁盘上。
根据上面对 Elasticsearch,写操作流程的介绍,我们可以整理出一个索引数据所要经历的几个阶段,以及每个阶段的数据的存储方式和作用,如图 10 所示:
图 10:Elasticsearch 写操作流程
在集群中写索引
假设我们有如图 11 所示(图片来自官网)的一个集群,该集群由三个节点组成(Node 1、Node 2 和 Node 3),包含一个由两个主分片和每个主分片由两个副本分片组成的索引。
图 11:写索引
其中,标星号的 Node 1 是 Master 节点,负责管理整个集群的状态;p1 和 p2 是主分片;r0 和 r1 是副本分片。为了达到高可用,Master 节点避免将主分片和副本放在同一个节点。
将数据分片是为了提高可处理数据的容量和易于进行水平扩展,为分片做副本是为了提高集群的稳定性和提高并发量。
在主分片挂掉后,会从副本分片中选举出一个升级为主分片,当副本升级为主分片后,由于少了一个副本分片,所以集群状态会从 Green 改变为 Yellow,但是此时集群仍然可用。
在一个集群中有一个分片的主分片和副本分片都挂掉后,集群状态会由 Yellow 改变为 Red,集群状态为 Red 时集群不可正常使用。
由上面的步骤可知,副本分片越多,集群的可用性就越高,但是由于每个分片都相当于一个 Lucene 的索引文件,会占用一定的文件句柄、内存及 CPU,并且分片间的数据同步也会占用一定的网络带宽,所以,索引的分片数和副本数并不是越多越好。
写索引时只能写在主分片上,然后同步到副本上,那么,一个数据应该被写在哪个分片上呢?
如图 10 所示,如何知道一个数据应该被写在 p0 还是 p1 上呢答案就是路由(routing),路由公式如下:
- shard = hash(routing)%number_of_primary_shards
其中,Routing 是一个可选择的值,默认是文档的 _id(文档的主键,文档在创建时,如果文档的 _id 已经存在,则进行更新,如果不存在则创建)。
后面会介绍如何通过自定义 Routing 参数使查询落在一个分片中,而不用查询所有的分片,从而提升查询的性能。
Routing 通过 Hash 函数生成一个数字,将这个数字除以 number_of_primary_shards(分片的数量)后得到余数。
这个分布在 0 到 number_of_primary_shards - 1 之间的余数,就是我们所寻求的文档所在分片的位置。
这也就说明了一旦分片数定下来就不能再改变的原因,因为分片数改变之后,所有之前的路由值都会变得无效,前期创建的文档也就找不到了。
由于在 Elasticsearch 集群中每个节点都知道集群中的文档的存放位置(通过路由公式定位),所以每个节点都有处理读写请求的能力。
在一个写请求被发送到集群中的一个节点后,此时,该节点被称为协调点(Coordinating Node),协调点会根据路由公式计算出需要写到哪个分片上,再将请求转发到该分片的主分片节点上。
图 12:写索引
写操作的流程如下(参考图 11,图片来自官网):
一旦所有的副本分片都报告成功(默认),则 Node 3 将向协调节点报告成功,协调节点向客户端报告成功。
集群中的查询流程
根据 Routing 字段进行的单个文档的查询,在 Elasticsearch 集群中可以在主分片或者副本分片上进行。
图 13
查询字段刚好是 Routing 的分片字段如“_id”的查询流程如下(见图 12,图片来自官网):
在这种情况下,协调节点可以把请求转发到任意节点,本例将请求转发到 Node 2 上。
当一个搜索请求被发送到某个节点时,这个节点就变成了协调节点(Node 1)。
协调节点的任务是广播查询请求到所有分片(主分片或者副本分片),并将它们的响应结果整合成全局排序后的结果集合。
由上面步骤 3 所示,默认返回给协调节点并不是所有的数据,而是只有文档的 id 和得分 score,因为我们只返回给用户 size 条数据,所以这样做的好处是可以节省很多带宽,特别是 from 很大时。
协调节点对收集回来的数据进行排序后,找到要返回的 size 条数据的 id,再根据 id 查询要返回的数据,比如 title、content 等。
图 14
取回数据等流程如下(见图 13,图片来自官网):
协调节点收集各个分片查询出来的数据,再进行二次排序,然后选择需要被取回的文档。
例如,如果我们的查询指定了{"from": 20, "size": 10},那么我们需要在每个分片中查询出来得分较高的 20+10 条数据,协调节点在收集到 30×n(n 为分片数)条数据后再进行排序。
排序位置在 0-20 的结果会被丢弃,只有从第 21 个开始的 10 个结果需要被取回。这些文档可能来自多个甚至全部分片。
由上面的搜索策略可以知道,在查询时深翻(Deep Pagination)并不是一种好方法。
因为深翻时,from 会很大,这时的排序过程可能会变得非常沉重,会占用大量的 CPU、内存和带宽。因为这个原因,所以强烈建议慎重使用深翻。
分片可以减少每个片上的数据量,加快查询的速度,但是在查询时,协调节点要在收集数(from+size)×n 条数据后再做一次全局排序。
若这个数据量很大,则也会占用大量的 CPU、内存、带宽等,并且分片查询的速度取决于最慢的分片查询的速度,所以分片数并不是越多越好。
作者:钱丁君
简介:就职于永辉云创,担任基础架构开发,有多年基础架构经验,主要从事电商新零售、互联网金融行业。技术发烧友,涉猎广泛。熟悉 Java 微服务架构搭建、推进、衍化;多种中间件搭建、封装和优化;自动化测试开发、代码规约插件开发、代码规范推进;容器化技术 Docker、容器化编排技术 Kubernetes,有较为丰富的运维经验。
【原创稿件,合作站点转载请注明原文作者和出处为.com】
本文标题:掌握它才说明你真正懂Elasticsearch
链接分享:http://www.shufengxianlan.com/qtweb/news14/436114.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联