Elasticsearch的乐观并发控制和分片管理(更新中)

1. 乐观并发控制

  首先,需要明确Elasticsearch的三个特性:

  • 分布式的:当文档创建,删除或更新的时候,新版本的文档必须被复制到集群中的其他节点;
  • 并发的:这些复制请求将被并行发送;
  • 异步的:这些复制请求到达目的地的顺序是乱的.

  因此,Elasticsearch需要保证文档的旧版本不会覆盖新版本.Elasticserch通过_version字段来确保并更以正确的顺序得到执行.如果旧版本的文档在新版本之后到达,它可以被简单的忽略。

2. 分片管理

2.1 动态索引

采用Luence的per-segment search机制,...

2.2 近实时搜索

通过refresh操作,默认每秒自动刷新,文件系统缓存,...

2.3 持久化变更

flush,translog...

2.4 段合并

optimize...

时间: 2024-11-09 01:14:22

Elasticsearch的乐观并发控制和分片管理(更新中)的相关文章

也谈乐观并发控制(转)

add by zhj: 本文主要谈的是乐观并发控制,虽然乐观并发控制不太适用于并发写冲突很频繁的场景下,因为这样会导致事务回滚,需要用户重试retry, 但是如果不用乐观并发控制的话,貌似也没有其它什么好的办法了,悲观锁并不能解决更新丢失的问题,比如本文中的例子,我们也可以想想Git 遇到这种情况时是怎么处理的,其实Git也会像本文一样处理.为什么说悲观锁也不能完全解决更新丢失的问题呢?我们看下面的例子,两个用户 张三,李四,他们两人可以更新同一条数据库记录,假设记录为(sex,age) = (

Entity Framework 乐观并发控制

一.背景 我们知道,为了防止并发而出现脏读脏写的情况,可以使用Lock语句关键字,这属于悲观并发控制的一种技术,,但在分布式站点下,锁的作用几乎不存在,因为虽然锁住了A服务器的实例对象,但B服务器上的锁是不知道的A服务器上锁的情况的,所以,面对分布式站点.单一数据库这种架构,我们可以使用EntityFramework的乐观并发控制来解决这个问题,EF对并发控制有不管控和乐观并发控制两种,默认情况是不管控,但EF不支持悲观并发. lock 确保当一个线程位于代码的临界区时,另一个线程不进入临界区.

MongoDB 分片管理

在MongoDB(版本 3.2.9)中,分片集群(sharded cluster)是一种水平扩展数据库系统性能的方法,能够将数据集分布式存储在不同的分片(shard)上,每个分片只保存数据集的一部分,MongoDB保证各个分片之间不会有重复的数据,所有分片保存的数据之和就是完整的数据集.分片集群将数据集分布式存储,能够将负载分摊到多个分片上,每个分片只负责读写一部分数据,充分利用了各个shard的系统资源,提高数据库系统的吞吐量. 数据集被拆分成数据块(chunk),每个数据块包含多个doc,数

使用ElasticSearch+LogStash+Kibana+Redis搭建日志管理服务

1.使用ElasticSearch+LogStash+Kibana+Redis搭建日志管理服务 http://www.tuicool.com/articles/BFzye2 2.ElasticSearch+LogStash+Kibana+Redis日志服务的高可用方案 http://www.tuicool.com/articles/EVzEZzn 3.示例 开源实时日志分析ELK平台部署 http://baidu.blog.51cto.com/71938/1676798?utm_source=t

OpenStack身份管理与访问控制(更新中)

OpenStack身份术语说明 Identity 身份 User 用户 Tenant 租户(工程) Service 服务 Endpoint 终端 X-Auth-Token HTTP请求头字段,应填充操作请求者拥有的由keystone颁发的token X-Subject-Token OpenStack身份管理与访问控制(更新中)

MVC应用程序中管理(更新)上传的文件

实现上传文件功能,有时上传也会操作出错,能让用户有改正有机会,开发上传文件能有更新的功能. 文件上传时,如果是存储于应用程序某一目录的话,在更新时需要了解一些流程,先是删除旧文件,更新数据表相关信息,存储新文件. 本篇让你了解到MVC与jQuery的交互处理. 在数据库中,新建一个更新的存储过程: 找到并打开FileLibraryEntity.cs,添加一个vlid更新方法: 在ExerciseController.cs控制器中,创建一个更新Action: A标记,删除旧文件. B标记,获取新上

mongo 3.4分片集群系列之八:分片管理

这个系列大致想跟大家分享以下篇章: 1.mongo 3.4分片集群系列之一:浅谈分片集群 2.mongo 3.4分片集群系列之二:搭建分片集群--哈希分片 3.mongo 3.4分片集群系列之三:搭建分片集群--哈希分片 + 安全 4.mongo 3.4分片集群系列之四:搭建分片集群--哈希分片 + 安全 + 区域 5.mongo 3.4分片集群系列之五:详解平衡器 6.mongo 3.4分片集群系列之六:详解配置数据库 7.mongo 3.4分片集群系列之七:配置数据库管理 8.mongo 3

部署MongoDB分片群集及分片管理

MongoDB分片 在Mongodb里面存在另一种集群,就是分片技术,可以满足MongoDB数据量大量增长的需求. 当MongoDB存储海量的数据时,一台机器可能不足以存储数据,也可能不足以提供可接受的读写吞吐量.这时,我们就可以通过在多台机器上分割数据,使得数据库系统能存储和处理更多的数据. 分片的优势 分片为应对高吞吐量与大数据量提供了方法. 使用分片减少了每个分片需要处理的请求数,因此,通过水平扩展,集群可以提高自己的存储容量和吞吐量.举例来说,当插入一条数据时,应用只需要访问存储这条数据

#19# SCCM管理 - 更新部署

软件更新 - 更新部署 本篇文章主要讨论ConfigMgr软件更新部署的相关内容 状态扫描 客户端基于SUP提供的更新元数据进行对自身的更新状态进行评估,并对每一个更新元数据生成一个状态(已安装.未安装.不适用等) 扫描类型 强制扫描:此类扫描表示客户端实际会进行一次扫描 非强制扫描:如果上一次同步"更新元数据"未超过24小时,那么在这24小时内触发的扫描动作实际并不会进行,如果超过24小时,则进行一次状态扫描 在线扫描:表示客户端会检查SUP上的更新元数据版本,并同步至本地进行缓存,