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