ElasticSearch的学习之路

大概在8年前，我使用compass作为搜索引擎，并深入了下lucene的源码，简单的写了一个分词器。后来工作中接触到ElasticSearch的时候，刚开始还不知道它就是compass的升级版。现在是时候好好来学习下这个ES的魔力了，据说现在的各大互联网公司都在使用它，相信我们也能从中受益。

ElasticSearch的官网上有一个比较好的学习文档《Elasticsearch权益指南》，在此我将一些要点记录下，以防忘记。

一、集群原理

一个运行中的 Elasticsearch 实例称为一个 节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为 主 节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到 集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

Elasticsearch 尽可能地屏蔽了分布式系统的复杂性。这里列举了一些在后台自动执行的操作：

• 分配文档到不同的容器 或 分片 中，文档可以储存在一个或多个节点中
• 按集群节点来均衡分配这些分片，从而对索引和搜索过程进行负载均衡
• 复制每个分片以支持数据冗余，从而防止硬件故障导致的数据丢失
• 将集群中任一节点的请求路由到存有相关数据的节点
• 集群扩容时无缝整合新节点，重新分配分片以便从离群节点恢复

二、乐观并发控制

Elasticsearch 是分布式的。当文档创建、更新或删除时， 新版本的文档必须复制到集群中的其他节点。Elasticsearch 也是异步和并发的，这意味着这些复制请求被并行发送，并且到达目的地时也许 顺序是乱的。 Elasticsearch 需要一种方法确保文档的旧版本不会覆盖新的版本。

当我们之前讨论 index ， GET 和 delete 请求时，我们指出每个文档都有一个 _version （版本）号，当文档被修改时版本号递增。 Elasticsearch 使用这个 _version 号来确保变更以正确顺序得到执行。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。

我们可以利用 _version 号来确保 应用中相互冲突的变更不会导致数据丢失。我们通过指定想要修改文档的 version 号来达到这个目的。 如果该版本不是当前版本号，我们的请求将会失败。

三、数据建模

和专用的关系型数据存储有所不同，Elasticsearch 并没有对处理实体之间的关系给出直接的方法。 一个关系数据库的黄金法则是 --规范化你的数据（范式）-- 但这不适用于 Elasticsearch。 在 关联关系处理 、 嵌套对象 和 父-子关系文档 我们讨论了这些提供的方法的优点和缺点。

然后在 扩容设计 我们谈论 Elasticsearch 提供的快速、灵活的扩容能力。 当然扩容并没有一个放之四海而皆准的方案。你需要考虑这些通过系统产生的数据流的具体特点， 据此设计你的模型。例如日志事件或者社交网络流这些时间序列数据类型，和静态文档集合在处理模型上有着很大的不同。

来日方长，要学习的内容还很多，将会在未来一一分享。