(翻译:jasonlee 970858106@qq.com)
分布式策略:
ES致力于分布式系统实现细节对于用户的透明性。在ES使用过程中,集群自动执行一下步骤:
1 分配文档到相同节点或不同节点的不同分片上。
2 通过集群中的多节点来平衡分配数据,用以减轻索引和查询的压力。
3 复制各分片,提供复制分片来防止硬件故障引起的数据丢失。
4 路由集群中每个节点的请求到该包含请求所需数据的所有节点。
5 当集群扩展或者从故障节点中恢复重新分配分片时可以无缝的重新分配节点。
扩展策略:
ES是高可用的,易扩展的。扩展方式分为水平扩展和容量扩展。容量扩展总有极限,最常用的是水平扩展。
ES集群健康查询:
GET /_cluster/health
健康状态:
绿色:所有的主分片和复制分片正常
黄色:所有的主分片正常,复制分片存在异常。
红色:主分片存在异常。
<文档 —-----存储于——>分片———分布在———>节点———存在于——>集群>
基本术语:
Index:索引
Index是一个逻辑命名空间,可以指向一个或多个物理分片,用来存储结构相近的数据。每个索引可以理解为一个数据库
创建索引:
PUT /blogs {
"settings" : { "number_of_shards" : 3, "number_of_replicas" : 1
}
}
shard :分片
shard分片是用来存储索引对应数据中部分数据的工作单元,可以说是lucene(全文搜索引擎)一个实例,本身也是一个完整的搜 索引擎。
新增复制分片
PUT /blogs/_settings {
"number_of_replicas" : 2 }
(主分片的数量决定了索引可以存储数据的总量;
主分片容量没有理论上的上限,有物理上的上限。主要取决于业务场景:硬件设备,文档的大小和复杂度,索引和查询的方式以 及对响应时间的要求度;
索引对应主分片的数量取决于创建索引时的配置,而复制分片的数量是动态变化的。)
Document:文档
Document不只包含数据,还包含元数据信息。主要包括
index(该文档存储于哪个索引):每个索引可以理解为一个数据库
type(文档存储的数据是哪个对象),id用于区别文档的唯一标识符。
document自定义ID:
PUT /{index}/{type}/{id} {"field": "value",}
如不自定义Id,ES会用UUID自动生成id
每个文档有自己的version,每次改动,包括删除,version+1
查看文档
curl -i -XGET http://localhost:9200/website/blog/124?pretty
get请求会返回整个文档,若只要获取某些field,使用_sourcer字段 GET /website/blog/123?_source = title,textcurl -i -XHEAD http://localhost:9200/website/blog/123
使用head请求查看文档是否存在
删除文档DELETE /website/blog/123成功200 失败404 删除命令同样先是逻辑删除。
修改文档
Document不能修改。若要修改,使用put命令,ES将逻辑删除已存在的文档,并新建一个文档。同时,version+1,created字段为false,表示已经存在过该文档。 逻辑删除后,数据虽然不能被查询到,但是不会立即物理删除。ES将会在过后继续查询的过程中后台自动清除。
局部修改document:(新旧文档合并) eg:添加两个字段POST /website/blog/1/_update {"doc" : {"tags" : [ "testing" ], "views": 0}}
使用脚本做局部更新(默认为Groovy脚本)
POST /website/blog/1/_update {
"script" : "ctx._source.views+=1"
}
批处理:
mget 批量查询
GET /
_mget
{
"docs"
: [
{
"_index"
:
"website"
,
"_type"
:
"blog"
,
"_id"
:
2
},
{
"_index"
:
"website"
,
"_type"
:
"pageviews"
,
"_id"
:
1
,
"_source"
:
"views"
}
]}
批处理create index update delete
每行结束有\n.每个操作,第一行为命令 第二行为body。delete没有body
eg:
POST /_bulk { "delete": { "_index": "website", "_type": "blog", "_id": "123" }}
{ "create": { "_index": "website", "_type": "blog", "_id": "123" }} { "title": "My first blog post" } { "index": { "_index": "website", "_type": "blog" }} { "title": "My second blog post" } { "update": { "_index": "website", "_type": "blog", "_id": "123", "_retry_on_conflict" : 3} } { "doc" : {"title" : "My updated blog post"}
}
读写的处理逻辑
写操作的请求,发送到节点1,该节点根据document判断出该请求属于分片0,继而转发请求至p0所在的节点3.节点3在p0主分片上执行该请
求,成功后转发该请求到两个复制分片R0.两个复制分片执行成功后,返回success到主分片p0.主分片返回请求结果状态为success。
此时,复制模式为同步复制。建议使用同步复制,异步复制可能导致请求过载。
读操作的请求,可以使用主分片和所有复制分片。使用轮询的方式转发请求来负载均衡。
当请求到来时,会存在一种情况,此时主分片已经有被请求文档,返回true,但是复制分片尚未更新到此文档,返回false。只有当主复制分
片都返回success时,该请求才会success。