ElasticSearch 是面向文档 ( document: oriented ), 这意味着它可以存储整个对象或文档( document ), 然后它不仅仅是存储, 还会索引( index )每个文档的内容使之可以被搜索, 在 ElasticSearch 中, 你可以对文档 ( 而非成行成列的数据 ) 进行索引, 搜索, 排序, 过滤.
ElasticSearch 与传统关系型数据库对比如下.
| 数据库 | 表 | 一条记录/行 | 字段/列 | |
|---|---|---|---|---|
| 传统关系型数据库 | Databases | Tables | Rows | Columns |
| ElasticSearch | Indices | Types | Documents | Fields |
1. 索引 ( index )
一个索引就是一个拥有几分相似特征的文档的集合. 比如说, 你可以有一个客户数据的索引, 另一个产品目录的索引, 还有一个订单数据的索引. 一个索引由一个名字来标识( 必须全部是小写字母的 ), 并且当我们要对对应于这个索引中的文档进行索引, 搜索, 更新和删除的时候, 都要使用到这个名字. 在一个集群中, 可以定义任意多的索引.
2. 类型( type )
在一个索引中, 你可以定义一种或多种类型. 一个类型是你的索引的一个逻辑上的分类/分区, 其语义完全由你来定. 通常, 会有具有一组共同字段的文档定义一个类型. 比如说, 我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中. 在这个索引中, 你可以为用户数据定义一个类型, 为博客数据定义另一个类型, 当然, 也可以为评论数据定义另一个类型.
3. 字段( Field )
相当于是数据表的字段, 对文档数据不同属性进行的分类标识.
4. 映射( Mapping )
mapping 是对处理数据的方式和规则方面做一些限制, 如某个字段的数据类型, 默认值, 分析器, 是否被索引等等. 这些都是映射里面可以设置的, 其他就是处理 ES 里面数据的一些使用规则设置也叫做映射, 按着最优原则处理数据对性能提高很大, 因此才需要建立映射, 并且需要思考如何建立映射才能对性能更好. 对于传统数据库来说, 可以理解 Mapping 为数据库表结构的定义.
5. 文档( Document )
一个文档是一个可被搜索的基础信息单元, 比如, 你可以拥有某一个客户的文档, 某一个产品的一个文档. 当然也可以拥有某个订单的一个文档. 文档以 JSON 格式来表示, 而 JSON 是一个到处存在的胡良文数据交互格式.
在一个 index/type 里面, 你可以存储任意多的文档, 注意, 尽管一个文档, 物理上存在于一个索引之中, 文档必须被索引/赋予一个索引的 type.
6. 接近实时 NRT
ElasticSearch 是一个接近实时的搜索平台. 这意味着, 从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟( 通常1 秒以内 )
7. 集群 Cluster
一个集群就是由一个或多个节点组织在一起, 他们共同持有整个数据, 并一起提供索引和搜索功能. 一个集群由一个唯一的名字标识, 这个名字默认是 "elasticsearch" . 这个名字是非常重要的, 因为一个节点只能通过指定某个集群的名字, 来加入这个集群.
8. 节点 node
一个节点就是集群中的一个服务器, 作为集群的一部分, 它存储数据, 参与集群的索引和搜索功能. 和集群类似, 一个节点也是由一个名字来标识的. 默认情况下, 这个名字是一个随机的漫威漫画角色的名字, 这个名字会在启动的时候赋予节点. 这个名字对于管理工作来说很重要. 因为在整个管理过程中, 你会去确定网络中的那些服务器对应于 ElasticSearch 集群中的哪些节点.
一个节点可以通过配置集群名称的方式来加入一个指定的集群, 默认情况下, 每个节点都会被安排加入到一个叫 "elasticsearch" 的集群中, 这意味着, 如果你在你的网络中启动了若干个节点, 并假定他们能够相互发现彼此, 他们将会自动加入到一个叫做 "elasticsercher" 的集群
在一个集群里, 只要你想, 可以拥有任意多个节点. 而且, 如果当前你的网络中没有运行任何的 ElasticSearch 节点, 这时候启动一个节点, 就会默认创建并加入到一个叫做 "elasticsercher" 的集群
9. 分片 shard
一个索引可以存储超出单个节点硬件限制的大量数据. 比如一个具有 10 亿文档的索引占用 1T 的磁盘空间, 而任一节点都没有这样大的磁盘空间, 或者单个节点处理搜索请求, 响应太慢.
为了解决这个问题, ElasticSearch 提供了将索引划分成多份的能力, 这些被分成的多份就叫分片. 当你创建一个索引的时候, 你可以指定你想要的分片数量. 每个分片本身也是一个功能完善并且独立的 "索引" , 这个 "索引" 可以被放置到集群中的任何节点上. 分片很重要, 主要有两方面原因
- 允许你水平分割/扩展你的内容容量
- 允许你在分片( 潜在的, 位于多个节点上 )之上进行分布式的, 并行的操作, 进而提高性能/吞吐量.
至于一个分片怎么样分布, 它的文档怎么样聚合回搜索请求, 是完全由 ElasticSearch 管理的. 对于作为用户的你来说, 这些都是透明的.
10. 复制 replica
在一个网络/云的环境里, 失败随时都可能发生, 在某个分片/节点有时会因为一些异常原因处于离线状态, 或者因为某个原因消失了, 这种情况下, 有一个故障转移机制是非常有用并且是强烈推荐的. 为了这个目的, ElasticSearch 允许你创建分片的一份或多份拷贝, 这些拷贝也叫复制分片, 或者直接叫复制.
复制也是非常重要的, 因为在分片/节点失败的情况下, 提供了高可用性. 因为这个原因, 注意到复制分片从不与原/主要 ( original/primary ) 分片置于同一节点上是非常重要的. 扩展你的搜索量/吞吐量, 因为搜索可以在所有的复制上并行运行.
总之每个索引可以被分成多个分片, 一个索引也可以被复制 0 次(意思是没有复制)或者多次, 一旦复制了, 每个索引就有了主分片( 作为复制源的原来的分片 ) 和复制分片( 主分片的拷贝 )之别.
分片和复制的数量可以在索引创建的时候指定. 在索引创建之后, 你可以在任何时候动态的改变复制的数量, 但是却无法改变分片的数量
默认情况下, ElasticSearch 中的每个索引被分片成 5 个主分片和 1 个复制, 这意味着, 如果你的集群中至少有两个节点的话, 你的索引将会有 5 个主分片和另外 5 个复制分片( 1 个完全拷贝 ), 这样的话每个索引总共就有 10 个分片.
