search（1）- elasticsearch结构概念

   上篇提到选择了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的技术门槛。