展开

关键词

The Way to TiDB 3.0 and Beyond (上篇)

我们在的算子上做了两点改进。  第一点是对整个框架做了优化,就是从一行一行处理的模式,变成了一批一批数据处理的模式,另外我们还在哈希算子上做了并行。 图 6 TiDB 2.1 - Parallel Hash Aggregation 为什么我们要优化算子?因为在分析场景下,有两类算子是非常重要的,是 Join 和。 Join 算子我们之前已经做了并行处理,而 TiDB 2.1 中我们进一步对算子做了并行处理。在哈希中,我们在一个算子里启用多个线程,分两个阶段进行。 这样就能够极大的提升的速度。 整个机器的 CPU 并不忙,但就是时间很长,我们做了 Profile 发现就是的时间太长了,所以在 TiDB 2.1 中,对算子做了并行,并且这个并行度可以调节。 4.

29520

TiKV源码解析系列文章(二十)Region Split源码解析

在学习了之前的几篇 raft-rs,raftstore 相关文章之后(如 Raft Propose 的 Commit 和 Apply 情景分析,Raftstore 概览等),raft-rs 以及 raftstore 其中 raft-rs 解决的是单个 Raft group(即单个 Region) 的问题,raftstore 解决的是多个 Raft group (即多个 Region)的问题。 TiKV 中的 Split 能把一个 Region 分裂成多个 Region,Merge 则能把 Range 相邻的 2 个 Region 成一个 Region。 每条 Proposal 都会在提出的时候带上 PeerFsm 的 Region epoch,在应用的时候检查该 Region epoch 的法性,如果不法就跳过。? SplitCheckerHost 只是了split_check 的结果,具体实现还是在这些 split_check 中,它们均实现了 SplitChecker trait,由上文的流程叙述也都提到了这些函数

22730
  • 广告
    关闭

    11.11智惠云集

    2核4G云服务器首年70元,还有多款热门云产品满足您的上云需求

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    TiKV 源码解析系列文章(二十)Region Split 源码解析

    在学习了之前的几篇 **raft-rs**, **raftstore** 相关文章之后(如 Raft Propose 的 Commit 和 Apply 情景分析,Raftstore 概览等),**raft-rs 其中 raft-rs 解决的是单个 Raft group(即单个 Region) 的问题,raftstore 解决的是多个 Raft group (即多个 Region)的问题。 TiKV 中的 Split 能把一个 Region 分裂成多个 Region,Merge 则能把 Range 相邻的 2 个 Region 成一个 Region。 每条 Proposal 都会在提出的时候带上 PeerFsm 的 Region epoch,在应用的时候检查该 Region epoch 的法性,如果不法就跳过。 SplitCheckerHost 只是了split_check 的结果,具体实现还是在这些 split_check 中,它们均实现了 SplitChecker trait,由上文的流程叙述也都提到了这些函数

    40411

    Nacos 1.3.0 来了,基于全新内核构建!

    经过社区讨论,从1.3.0版本开始修炼内功,焦“简单”、“性能”、“高可用”这核心的三个点进一步提升Nacos核心竞争力。 Nacos 1.3.0版本开始,对集群节点的寻址模式做了统一,将原本分散的节点寻址模式整并抽象,方便将来可以扩宽Nacos的集群发现机制,用户可以通过如下设置自己选择需要使用哪一种寻址模式作为集群节点的管理文件寻址模式 在Raft的选型上,使用了SOFA-JRaf作为CP协议的Backend,并且将其与配置管理模块进行了对接。用户可以通过调整下面的参数对Raft协议进行调整。 如果说对于配置的发布、修改操作比较频繁,可以将Raft快照的时间适当的进行调整,避免新节点加入或者节点重启时,由于Raft日志回放操作数太多导致节点可开始对外服务的时间过长。 :{raft_port},...}后续目前一致性协议层只是将CP协议具体实现了,后面会再将AP协议——Distro下沉到一致性协议层中,并且调整Distro的实现,其协议内部的通信将使用gRPC,以配Nacos

    56710

    源码阅读技巧篇:RocketMQ DLedger 多副本即主从切换专栏回顾

    raft 协议。 1、RocketMQ 多副本前置篇:初探raft协议本文主要根据 raft 官方提供的动画来学习了解 raft 协议,从本文基本得知了 raft 协议主要包含两个重要部分:选主 以及 日志复制。 在了解了 raft 协议的选主、日志复制的基本实现后,然后就可以步入到 RocketMQ DLedger 多副本即主从切换的源码研究了,以探究大神是如何实现 raft 协议的。 同时在了解到了 raft 协议的选主部分内容后,自己也可以简单的思考,如果自己去实现 raft 协议,应该要实现哪些关键点,当时我的思考如下: ? 7、RocketMQ 整 DLedger(多副本)即主从切换实现平滑升级的设计技巧前面6篇文章都焦在 raft 协议的选主与日志复制。

    34510

    TiDB 2.1 GA Release Notes

    ABSCEILFLOORIS TRUEIS FALSE 优化内建函数 IF 和 IFNULL 的常量折叠算法 优化 EXPLAIN 语句输出格式, 使用层级结构表示算子之间的上下游关系 SQL 执行引擎 重构所有函数 ,提升 Stream 和 Hash 算子的执行效率 实现并行 Hash Aggregate 算子,部分场景下有 350% 的性能提升 实现并行 Project 算子,部分场景有 74% 的性能提升 Jobs 输出结果中添加表名、库名等信息 支持使用 ddlownerresign HTTP 接口释放 DDL Owner 并开启新一轮 DDL Owner 选举 兼容性 支持更多 MySQL 语法 BIT 函数支持 PreVote,避免网络隔离后恢复时产生的重新选举 开启 raft learner 功能,降低调度时出现宕机导致数据不可用的风险 TSO 分配不再受系统时间回退影响 支持 Region merge 功能 性能 优化计算热点统计的性能问题 TiKV Coprocessor 新增支持大量内建函数 新增 Coprocessor ReadPool,提高请求处理并发度 修复时间函数解析以及时区相关问题 优化下推计算的内存使用

    36400

    TiKV 源码解析系列文章(十九)read index 和 local read 情景分析

    在上篇文章中,我们讲解了 Raft Propose 的 Commit 和 Apply 情景分析,相信大家对 TiKV 的 Raft 写流程有了大概了解。 检查 Raft 任期,确认当前 leader 的任期是否符请求中的要求;e. 检查 peer 初始化状态,确认当前 Peer 已经初始化,有完整数据;f. 检查 region epoch,确认当前 Region 的 epoch 符请求中的要求。peer.propose: 当全部检查通过后,正式进入 Raft 的 Propose 环节。 让我们焦到读请求,处理方式总共有两种:RequestPolicy::ReadLocal,也就是 local read,说明该 Peer 是 leader 且在 lease 内,可以直接读取数据。 self.read_index:以 read index 方式处理请求,询问一遍大多数节点,确保自己是法 leader,然后到达或超过线性一致性的点(read index)后读取 RocksDB。

    25231

    TIDB 学习计划 --- 什么是分布式数据库和TIDB 整体架构

    从今天开始就准备学习TIDB数据库,初期基础差,学习可能会比较困难入门后可能就会好很多 TIDB 是一个分布式,强一致的可水平扩展的关系型数据库,在TIDB 设计之初,焦了四个设计的要点 1 水平扩展 存储引擎是TIKV 数据库存储引擎,采用了分层的架构来实现 1 transaction 2 MVCC3 raft4 local kv storage 容灾与特点 高度分层,底层为ROCKSDB,通过raft 通过多副本的方式进行数据的存储,通过raft 进行强一致,多个副本中只有一个leader 其他节点为follower,其中leader 和follower值不固定的,在leader失效后,会选择follower ,则利用range分片比较理。 TIDB SERVER ,在进行SUM。

    38930

    Nacos 1.3.0 发布,一个修炼内功的版本:全新内核构建!

    1.3.0版本开始修炼内功,焦“简单”、“性能”、“高可用”这核心的三个点进一步提升Nacos核心竞争力。 协议的元数据数据配置管理模块使用新Raft协议的元数据a. 用户可以通过调整下面的参数对Raft协议进行调整。 =5000# Sets the amount of time the Raft snapshot will execute periodically, default is 30 minute# 设置Raft 协议能够进行一些简单的运维操作,Nacos 1.3.0 内核模块开放了相关一致性协议运维的 Open-API,供其对Raft进行一些运维操作,其相关的运维操作如下切换某一个Raft Group的Leader

    61020

    Elasticsearch 之 Date Histogram

    Elasticsearch的主要分成两大类:metric和bucket,2.0中新增了pipeline还没有研究。 本篇还是来介绍Bucket中的常用——date histogram.参考:官方文档 用法Date histogram的用法与histogram差不多,只不过区间上支持了日期的表达式。

    1K70

    银行交易系统 TiDB 在线缩容迁移

    接下来还是看一下迁移的过程:(一) TiKV 采用 Raft 一致性算法保证副本强一致性,迁移过程本质上是扩容的逆过程,确定下线的 TiKV 打上 label 后,将 region 搬移到最终保留下来的 (二) 接下来焦 region 1 的 Raft Group,对其副本进行搬移,实际上所有 region 的数据是一样的,只是在保留的 TiKV 内进行 region 数据的复制,新产生的副本由于数据不完整 ,作为 Raft Group 中的 learner。 (五) 这样一个新的 5 副本 Raft Group 我们就获得了。这里再说几点:1. 磁盘 IO 对迁移的效率影响还是很大的,测试环境使用普通的 SAS 盘,在更高并发的条件下,耗时长了很多。2. (二)、(三)、(四)的过程并非原子化操作,当然 learner 的数据本身也不具备一致性,但对 raft 的改造最终要保证一致性,与 PingCAP 的开发同学确认后,这些会在之后加入。3.

    39830

    分布式系统的共识(consensus)算法比较

    ,包括Paxos、Egalitarian Paxos、Hydra、Fast Paxos、Ios、VRR(Viewstamped Replication Revisited)、 Multi-Paxos、Raft .处理有限的存储容量3.有效处理只读请求4.动态成员资格和重新配置5.支持事务6.验证实施的安全 这就需要一种领导人或协调人角色来具体处理这些问题,Paxos是一种无领导人Leaderless算法,而Raft 但是强领导在保证可靠性的同时也会集单点风险,而且选举领导人的过程也是费时费力的,因此,并不是领导力越强越好。 需要根据自己的业务领域特点在Leadership和Leaderless之间选择适自己的算法。 上述算法需要结实际以及CAP理论与FLP综判断选择。

    56820

    区块链BaaS云服务(15)复杂美chain33

    应用层 EVM虚拟机, WASM虚拟机,GO语言原生约以及JVM虚拟机(研发完成,测试中)共识层 支持POS,DPOS以及POS33的公链共识、Tendermint及pbft联盟链共识、Raft私链共识 应用层EVM虚拟机, WASM虚拟机,GO语言原生约以及JVM虚拟机(研发完成,测试中)共识层支持POS,DPOS以及POS33的公链共识、Tendermint及pbft联盟链共识、Raft私链共识、 关键特性3.1 性能提升为提升系统整体性能,chain33从以下几方面来进行了优化共识流程的优化(联盟链)chain33联盟链引入了签名的技术来降低共识过程中的消息通信,通过leader去收集签名, 于后发送给其他节点,通过签名就可以验证是否 23的节点已经签名,这样就能保证在区块链节点增加的情况下,交易数不会大量增加,提升共识的效率。 共识机制可插拔Chain33兼容多种共识机制,包括 RAFT、PBFT、POS、DPOS 等主流共识,也包括 SPOS、POS33 等自主研发共识机制,插拔不同的共识算法,可快速搭建私链、联盟链、公链、

    11810

    Elasticsearch 之 Range区间

    Elasticsearch提供了多种方式,能帮助用户快速的进行信息统计与分类,本篇主要讲解下如何使用Range区间。 更多资料参考:Elasticsearch文档翻译 例子按照前言中的例子,可以执行下面的命令:{ aggs:{ grade_ranges:{ range:{ field:grade, ranges: } } } }}当然也可以指定区间的名字:{ aggs:{ price_ranges:{ range:{ field:price, keyed:true, ranges: } } }}使用脚本与其他的类似 ,Range支持脚本的使用:{ aggs:{ price_ranges:{ range:{ script:doc.value, ranges: } } }}文件脚本或者脚本值的操作都与其他的差不多, 嵌套通常在区间中,都会嵌套子,比如我们在每个区间中做统计stats:{ aggs:{ price_ranges:{ range:{ field:price, ranges:}, aggs

    89060

    如何设计一款“高可用高性能”的发号器?(文末送书)

    本文焦高可用,高性能高可用:不会因为系统故障导致服务不可用或发号重复高性能:发号器通常是一个非常高并发的系统,性能足够的同时也可以水平扩容在基本的要求下,常见的解决方案有哪些? 综来看,snowflake方案符基本要求,性能非常高,但其存在时钟回拨问题,因而是高性能但不是高可用的方案。 综来看,基于数据库的方案如果不开启全同步复制,就不是高可用方案,如果开启全同步复制,则性能一定会有问题(就算不开启全同步复制也会有性能问题)。 基于一致性协议的方案上面数据库的高可用问题主要来源于主从数据不一致,如果使用一致性协议来保证数据的一致性,就可以解决高可用问题,目前最常使用的raft算法,可以保证数据复制到半数以上机器。 甚至可以基于开源的raft库来自己实现一个发号器,如果要自己来实现一个靠谱的raft协议,还是比较困难的,开源的raft库可选用蚂蚁开源的SOFAJRaft。

    25020

    TiDB + TiFlash : 朝着真 HTAP 平台演进

    列式存储天然可以做列过滤,并且压缩率很高,适大数据的 Scan 场景。另外列式存储更适做向量化加速,适下推的类算子也更多。 而行式存储显然更适 TP 场景,因为它很适点查,只读少量数据,IO 次数、粒度都更小。在绝大多数走索引的查询中,可以实现高 QPS 和低延迟。 我们采用的方案也很自然:既然 TiKV 节点内部使用 Raft 协议同步,那自然 TiKV 到 TiFlash 也是可以用 Raft 协议同步数据的。 比较不一样的是,TiFlash 只会作为 Raft Learner,并不会成为 Raft Leader Follower。 图 5 Raft Learner Replication大家知道,Raft 协议为了提高数据复制效率,Raft Log 从 Leader 到 Follower Learner 的复制通常会优化成异步复制

    1.9K70

    TiDB 1.1 Beta Release

    相比 1.0 版本,在 TPC-H 以及 TPC-DS 等测试中有显著提升 PD 增加 drop region 调试接口 支持设置 PD leader 优先级 支持配置特定 label 的节点不调度 raft PD health 状态的接口 添加更多 metrics PD leader 尽量与 etcd leader 保持同步 提高 TiKV 宕机时数据恢复优先级和恢复速度 完善 data-dir 配置项的法性较验 RocksDB compaction listener 更新 Region Size,让 PD 更精确的进行调度 使用 DeleteFilesInRanges 批量删除过期数据,提高 TiKV 启动速度 设置 Raft snapshot max size,防止遗留文件占用太多空间 tikv-ctl 支持更多修复操作 优化有序流式操作 完善 metrics,修复 bug 源码地址:https:github.compingcaptidb

    44260

    Elasticsearch 之 Histogram 直方图

    Elasticsearch支持最直方图,它在数字字段自动创建桶,并会扫描全部文档,把文档放入相应的桶中。这个数字字段既可以是文档中的某个字段,也可以通过脚本创建得出的。 min_doc_count过滤的dsl如下:{ aggs : { prices : { histogram : { field : price, interval : 50 } } }}得到的数据为 { aggregations: { prices : { buckets: } }}extend_bounds,指定最小值和最大值边界默认情况下,ES中的histogram起始都是自动的,比如price aggs : { prices : { histogram : { field : price, interval : 50, order : { _count : asc } } } }}或者指定排序的

    742100

    Raft一致性算法整理【原理笔记】

    成员变化(Membership Change):Raft使用了一种联一致性的方法,使得集群中的机器发生变更的时候,整个集群也可以正常的工作。联一致性配置是两个不同配置的大多数机器的重叠。 7.选主Raft使用心跳机制来触发选主的过程。当servers启动的时候,都是作为参与者。如果一个参与者收到来自leader或者候选者的法请求,它将保持在参与者的状态。 如果请求中的leader的任期大于候选者本地存储的任期,那么当前候选者认为这个leader 是法的并转变为参与者状态。 这些不一致可能多个leader和参与者的崩溃。一个参与者可能缺失了leader有的日志记录,它也可能多出了leader没有的日志,或者上面的两种情况同时发生。缺失或多余的日志可能存在在多个任期。 Raft集群第一阶段会过渡到迁移配置(我们称之为联一致性配置joint consensus);一旦联一致性被提交,系统将切换到新配置。joint consensus配置组了老配置和新配置。

    31720

    Elasticsearch6

    类似于 COUNT() 、 SUM() 、 MAX() 等统计方法 每个都是一个或者多个桶和零个或者多个指标的组。 这些是 Elasticsearch2时的内容, Elasticsearch6新提出了Matrix(矩阵)、Pipeline(管道)。 Matrix(矩阵)在多个字段(fields )上运行,并根据从请求的文档字段中提取的值生成矩阵结果的。 与Metrics和Buckets不同,此模式尚不支持脚本。 Pipeline(管道) 这一类的数据源是其他的输出,然后进行相关指标的计算。的真正强大所在:可以嵌套。操作数据的双重表示。 } * }参考资料AggregationsElasticSearch6(五) restful风格 查询-管道elasticsearch系列六:分析(分析简介、指标、桶

    16220

    相关产品

    • 金融资源聚合平台

      金融资源聚合平台

      金融资源聚合平台(FRAP)是以 SaaS 服务的形式为银行提供一站式接入的运营管控平台,实现运营策划、方案配置、权益采购、获客转化、实时监控、效果分析等互联网运营环节的无缝打通,打造高效、敏捷、智能、安全的运营管控模式,满足银行互联网业务急速发展的需求......

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      扫码关注云+社区

      领取腾讯云代金券