经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » Java相关 » Scala » 查看文章
search(1)- elasticsearch结构概念
来源:cnblogs  作者:雪川大虫  时间:2020/3/17 8:52:06  对本文有异议

   上篇提到选择了elasticsearch ES作为专业化搜索引擎的核心,这篇讨论一下ES的基本结构和应用概念。首先,从硬结构方面来讲:ES是在一个集群(cluster)环境里运行的,所以ES应该具备高可用和高扩展特性,因为系统可以分布在机器内无数个节点(node)服务器上运行。ES的索引(index)分布在集群中各node上。ES的index又可以向下分成多个shard分片。因为ES是基于lucent的,ES的shard就是一个完整的lucent index。所以,ES index是一个shard集合,也就是lucent index集合。在定义ES index时必须指定该index的shard(primary)数量,之后不得修改。这就意味着每个ES index需要占用一个以上shard,而shard是ES index操作的最小单元,也就是说一个shard只能存放一种ES index索引文件(document)。

在ES7之前的版本表面上每个index里又分不同的document type,可以分辨不同类型的document。但因为ES index是shard集合,或者lucent index集合,而lucent index并没有document type的概念,基本上是一种nosql (schemaless)存储结构,所以ES7之后就取消了_type这层,其结果就变成每个ES index只能容许一种document操作。

很多人认为ES也是数据库系统,ES7之前普遍认识是:index -> database, type -> table, document -> row。ES7之后在某种意义上index就是table了。所以:把ES作为应用系统的数据库来使用是大大不妥的。因为应用系统由众多数据表组成关系数据库,在ES上就意味着必须构建众多的index,会出现大量的细小shard(table)分布在集群节点上,严重影响效率。

ES7是个集群体系:cluster->nodes->index->shards。shard又分primary shard和replica shard  (pshard,rshard)。一般来说pshard和rshard相互应分布在不同的node上。所有写操作由pshard负责,或者说先在pshard上执行后再把结果分发到隶属各rshard。读取操作采取就近读取策略以实现快速响应。

ES的底层操作是由lucent实现的。在lucent操作时shard又被细分一层到segment:luccent shard是由多个segment组成的,lucent的写操作先写入一块缓存(write-buffer),然后以一种提交形式再以一个segment为单元存写入shard。

ES是某种nosql数据库,但在存写数据时又对数据,特别是字符text类型的数据进行了分拆处理,所以ES存写即是更新索引indexing。从另一个角度说明:ES是一个索引容器(index container),是一个完整封闭的容器。index的构建、维护、使用等都是通过ES提供的一些工具软件以及一套HTTP-api来实现的。数据输入可以用工具(如logstash)进行批次型的indexing,实时indexing是通过HTTP-api实现的。

ES自带一套REST-api可以对index进行更新、搜索、统计、提取。

ES-REST-api的功能可以说是相当全面,但复杂、不易掌握、使用要求门槛高,且不易作为系统整合工具。为了实现ES在行业IT系统的普遍应用,应该绕过复杂的ES-REST-api,在ES之上设计一套连接ES-HTTP通道的REST-api作为ES和前端(web,mobile)的桥梁,把前端搜索条件翻译成ES JSON格式的搜索指令发送至ES,然后对搜索结果进行简化、筛选处理,以某种简洁通用的格式呈现给前端。最终目的其实是为了降低前端开发人员引用ES的技术门槛。

原文链接:http://www.cnblogs.com/tiger-xc/p/12506162.html

 友情链接: NPS  问卷模板