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/cn/index.html
http://blog.csdn.net/cnweike/article/details/33736429
http://www.cnblogs.com/ajianbeyourself/p/5529575.html

你可能感兴趣的:(Elasticsearch学习上手(二))