Elasticsearch学习上手（二）

摘要：序列化被大多数编程语言所支持，并且已经成为领域的标准格式。通过索引对文档的进行创建查询修改和删除等操作。请求的结构调整为不再使用请求使用这个存储这个文档，而是使用请求存储文档在这个命名空间下。

在安装elasticsearch之后，我们就要开始进行操作实践，那么在实践之前，我们首先了解下elasticsearch的几个概念

相对关系型数据库，是采用行和列的形式进行存储数据，elasticsearch是面向文档的，意味着它存储整个对象或文档。Elasticsearch 不仅存储文档，而且 索引 每个文档的内容使之可以被检索。在 Elasticsearch 中，你对文档进行索引、检索、排序和过滤--而不是对行列数据。这是一种完全不同的思考数据的方式，也是 Elasticsearch 能支持复杂全文检索的原因。
Elasticsearch 使用 JavaScript Object Notation 或者 JSON 作为文档的序列化格式。JSON 序列化被大多数编程语言所支持，并且已经成为 NoSQL 领域的标准格式。 它简单、简洁、易于阅读。

一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是“elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。在产品环境中显式地设定这个名字是一个好习惯，但是使用默认值来进行测试/开发也是不错的。

一个节点是你集群中的一个服务器，作为集群的一部分，它存储你的数据，参与集群的索引和搜索功能。和集群类似，一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机的漫威漫画角色的名字，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在这个管理过程中，你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。
一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。

ps:当然你可以通过修改配置文件中node.name自行定义节点名称

一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。
分片之所以重要，主要有两方面的原因：

允许你水平分割/扩展你的内容容量

允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量

至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户的你来说，这些都是透明的。

在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片，或者直接叫复制。

复制之所以重要，有两个主要原因：

在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。

扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行

总之，每个索引可以被分成多个分片。一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。

默认情况下，Elasticsearch中的每个索引被分片5个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个复制分片（1个完全拷贝），这样的话每个索引总共就有10个分片。

一个 索引应该是因共同的特性被分组到一起的文档集合。一般来说，对比关系型数据库，相当于SQL的数据库或者schema。通过索引对文档的进行创建、查询、修改和删除等操作。需要注意的是，索引的名称必须全为小写字符。

类型是索引内部的逻辑分区(category/partition)，然而其意义完全取决于用户需求。一般来说，类型就是为那些拥有相同的域的文档做的预定义。对比关系型数据库，对应的是“表”。

ID 是一个字符串，当它和 _index以及 _type组合就可以唯一确定Elasticsearch 中的一个文档。 当你创建一个新的文档，要么提供自己的 _id，要么让 Elasticsearch 帮你生成。

如果你的文档有一个自然的标识符 （例如，一个 user_account
 字段或其他标识文档的值），你应该使用如下方式的 index API 并提供你自己 _id

PUT /{index}/{type}/{id}
{ "field": "value", ...}

如果你的数据没有自然的 ID， Elasticsearch 可以帮我们自动生成 ID 。请求的结构调整为： 不再使用PUT请求(“使用这个 URL 存储这个文档”)， 而是使用 POST请求(“存储文档在这个 URL 命名空间下”)。
现在该 URL 只需包含 _index 和 _type

POST /{index}/{type}
{ "field": "value", ...}

 
参考：
https://www.elastic.co/guide/...
http://blog.csdn.net/cnweike/...
http://www.cnblogs.com/ajianb...