如何通过beisensearchv3索引存储
常见概念
BeisenSearchV3是由beisen平台组封装的一套调用elasticsearch服务的客户端代码类库。
关键知识
Routing
Elasticsearch的路由机制与其分片机制有着直接的关系。Elasticsearch的路由机制即是通过哈希算法,将具有相同哈希值的文档放置到同一个主分片中。这个和通过哈希算法来进行负载均衡几乎是一样的。 而Elasticsearch也有一个默认的路由算法:它会将文档的ID值作为依据将其哈希到相应的主分片上,这种算法基本上会保持所有数据在所有分片上的一个平均分布,而不会产生数据热点。
从SearchV3的的创建索引接口中我们有看到Routing参数。Beisen技术体系下,该值务必是当前使用该业务的租户ID。
Transport
Transport 代表 elasticsearch 内部的节点或者集群与客户端之间的交互方式。
默认的内部是使用 tcp 协议来进行交互的,同时它支持 http 协议(json格式)、thrift、servlet、memcached、zeroMQ等多种的传输协议(通过插件方式集成)。
技术内幕
Thrift
BeisenSearchV3封装的和elasticsearch通信的协议使用的是thrift。
Thrift与其他传输方式的比较
- xml与JSON相比体积太大,但是xml传统,也不算复杂。
- json 体积较小,新颖,但不够完善。
thrift 体积超小,使用起来比较麻烦,不如前两者轻便,但是对于:
1.高并发 2.数据传输量大 3.多语言环境
满足其中2点使用 thrift还是值得的。
我们的elasticsearch客户端基本都满足了以上三点。索引的存储和更新每天都是千万级的操作,搜索数据的存储数据传输量大,elasticsearch本身是java写的,而我们的生产环境又是c# 多语言也满足。所以thrift脱颖而出,我们的elasticsearch客户端最早采用的是http协议,后面经过苛刻的性能测试和评估现在才切换到了thrift。
经验技巧
由于分布式服务的特点,集群式,多节点,不同节点数据同步问题,将数据进行存储的瞬间去读取数据是有一定可能无法读取出来的。因为你写入的节点可能还没来的及和你读取数据的节点进行数据同步,导致你无法获取到你刚刚存储进去的数据。
正常业务场景下也并没有马上存马上就要读取的需要,如果真的有可能就需要在获取不到数据后进行相应的重试机制了。
注意事项
出于对基础服务稳定性的考量,为了避免不同的业务线在使用基础服务时不因为一些错误的代码引起基础服务的瘫痪导致所有产品线受到影响,平台对基础服务的使用增加了一些额外的限制,针对BeisenSearchV3中的数据存储接口:
- 调用批量创建索引Bulk接口的时候,不能超过100个索引对象。
实例
//创建一个最基本默认的索引
public void CreateIndex()
{
var applicantProfile = new ApplicantProfile("user1", "message1", "1234",1,2);
var index = ElasticCommands.Index("ApplicantProfile", Guid.NewGuid())
.Routing("100100")
.Document(applicantProfile);
}
//批量创建最基本默认的索引
public void CreateIndex()
{
var bulk = ElasticCommands.Bulk("ApplicantProfile")
.Routing("100100")
.Item(BulkItem.Create("bid1").Document(ApplicantProfile1))
.Item(BulkItem.Create("bid2").Document(ApplicantProfile2))
.Item(BulkItem.Index("bid3").Document(ApplicantProfile3))
.Item(BulkItem.Index("bid4").Document(ApplicantProfile4))
var result = ElasticSearchClient.Bulk(Helper.Application, Helper.Tenant, bulk);
}