Elasticsearch学习上手（二）

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

面向文档

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

集群（cluster）

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

节点（node）

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

ps:固然你能够经过修改配置文件中node.name自行定义节点名称

分片和复制（shards & replicas）

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

为了解决这个问题，Elasticsearch提供了将索引划分红多份的能力，这些份就叫作分片。当你建立一个索引的时候，你能够指定你想要的分片的数量。每一个分片自己也是一个功能完善而且独立的“索引”，这个“索引”能够被放置到集群中的任何节点上。
分片之因此重要，主要有两方面的缘由：

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

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

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

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

  复制之因此重要，有两个主要缘由：

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

• 扩展你的搜索量/吞吐量，由于搜索能够在全部的复制上并行运行

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

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

索引（_index）

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

类型（_type）

类型是索引内部的逻辑分区(category/partition)，然而其意义彻底取决于用户需求。通常来讲，类型就是为那些拥有相同的域的文档作的预约义。对比关系型数据库，对应的是“表”。

_id

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...