首页
学习
活动
专区
工具
TVP
发布

PingCAP的专栏

专栏成员
537
文章
530972
阅读量
95
订阅数
​网易游戏实时 HTAP 计费风控平台建设
本文整理自网易互娱资深工程师, Flink Contributor, CDC Contributor 林佳,在 FFA 实时风控专场的分享。本篇内容主要分为五个部分:
PingCAP
2023-02-13
1.1K0
TiDB 在安信证券资产中心与极速交易场景的实践
今天分享的议题主要是 TiDB,所以就给大家介绍一下 TiDB 这个产品,TiDB 是原生分布式数据库架构设计,是由 PD 以及 TiDB 和 TiKV 组件组成。PD 层主要是作为数据调度、事务调度以及 TiKV 的元数据的存储。TiDB 层是无状态的 SQL 计算引擎,因为它是无状态的,所以对于后期的扩展需求有良好的支持。第三层的 TiKV 负责具体的数据落地存储,TiKV 节点之间通过 Raft 协议进行数据同步,所以 TiDB 整体架构是以 TiDB 作为 SQL 计算引擎,TiKV 作为落地存储的存算分离架构。
PingCAP
2023-02-08
6500
TiCDC 源码阅读(一)TiCDC 架构概览
这一次 TiCDC 阅读系列文章将会从源码层面来讲解 TiCDC 的基本原理,希望能够帮助读者深入地了解 TiCDC 。本篇文章是这一系列文章的第一期,主要叙述了 TiCDC 的目的、架构和数据同步链路,旨在让读者能够初步了解 TiCDC,为阅读其他源码阅读文章起到一个引子的作用。
PingCAP
2023-01-04
6410
TiKV 源码阅读三部曲(一)重要模块
作者简介:谭新宇,清华大学软件学院研三在读,Apache IoTDB committer,Talent Plan Community mentor。
PingCAP
2022-10-18
8260
TiFlash 源码阅读(九)TiFlash 中常用算子的设计与实现
本文主要介绍了数据库系统中常用的算子 Join 和 Aggregation 在 TiFlash 中的执行情况,包括查询计划生成、编译阶段与执行阶段,以期望读者对 TiFlash 的算子有初步的了解。
PingCAP
2022-09-20
5690
深入解析 TiFlash丨多并发下线程创建、释放的阻塞问题
TiFlash 初期存在一个棘手的问题:对于复杂的小查询,无论增加多少并发,TiFlash 的整机 CPU 使用率都远远不能打满。如下图:
PingCAP
2022-05-30
4510
TiDB 查询优化及调优系列(四)查询执行计划的调整及优化原理
本章节会介绍在优化器产生的查询执行计划和预期不符时,如何通过 TiDB 提供的调优手段来调整及稳定查询计划。本篇文章为查询执行计划的调整及优化原理解析,主要会介绍如何通过使用 HINT 来调整查询的执行计划,以及如何利用 TiDB SPM 来绑定查询语句的查询执行计划;最后将介绍一些规划中的功能。
PingCAP
2022-05-24
6240
TiDB 6.0 新特性解读丨 Collation 规则
对数据库而言,合适的字符集和规则能够大大提升使用者运维和分析的效率。TiDB 从 v4.0 开始支持新 collation 规则,并于 TiDB 6.0 版本进行了更新。本文将深入解读 Collation 规则在 TiDB 6.0 中的变更和应用。
PingCAP
2022-05-11
4530
带着问题读 TiDB 源码:Hive 元数据使用 TiDB 启动报错
在 TiDB 社区活跃较久的伙伴们应该知道,过去我们有被称为 24 章经的《TiDB 源码阅读系列文章》,也有面向 TiKV 的《TiKV 源码解析系列文章》以及 《Deep Dive TiKV 系列文章》。这些系列文章的内容非常深入,能够帮助大家从非常细节的原理入手了解 TiDB 以及 TiKV 的实现方式和基础原理。
PingCAP
2021-11-26
4300
内存泄漏的定位与排查:Heap Profiling 原理解析
系统长时间运行之后,可用内存越来越少,甚至导致了某些服务失败,这就是典型的内存泄漏问题。这类问题通常难以预测,也很难通过静态代码梳理的方式定位。Heap Profiling 就是帮助我们解决此类问题的。
PingCAP
2021-11-18
1.6K0
构建实时数仓 - 当 TiDB 偶遇 Pravega
数据仓库是公司数据发展到一定规模后必然需要提供的一种基础服务,也是“数据智能”建设的基础环节。早期数仓多为离线模式,主要处理的是 T+1 的数据,随着互联网时代的到来,实时数据处理的场景日益增多,离线数仓已无法满足业务发展的实时性需求。为更好的解决业务场景的实时化需求,实时数仓建设已成必然趋势,这也是 HTAP 数据库的重要能力之一。
PingCAP
2021-06-09
8400
TiDB 5.0 跨中心部署能力初探 | Joint Consensus 助力 TiDB 5.0 无畏调度
TiDB 5.0 已于上周正式发布,在这个大版本更新中提升 TiDB 集群的跨中心部署能力是一个重要的着力点,在共识算法这一层,最激动人心莫过于 Joint Consensus 支持了。这个特性帮助 TiDB 5.0 在跨 AZ 的调度中完全容忍少数派数目的 AZ 不可用。本文会先谈成员变更在 TiDB 历史,然后介绍新特性的设计,最后说下我们在实现过程中遇到的问题和解决方案。
PingCAP
2021-05-10
5350
Behind TiDB 5.0 - 聊聊 PingCAP 的工程体系(1)
最近,TiDB 终于发布了一个里程碑的版本 - TiDB 5.0。这里,我并不打算过多的聊 TiDB 5.0 架构实现、技术细节,这个大家可以参考 What's New in TiDB 5.0 以及后续的技术文章,我想聊聊其他的东西,也就是我们是通过什么样的方式来打造 TiDB 5.0 的。
PingCAP
2021-04-20
5930
神器 TiDE 在手,一键快速上车 TiDB | TiDB Hackathon 2020 优秀项目分享
近日,由 TiDB 社区主办,专属于全球开发者与技术爱好者的顶级挑战赛事——TiDB Hackathon 2020 比赛圆满落幕。今年是 TiDB Hackathon 第四次举办,参赛队伍规模创历届之最,共有 45 支来自全球各地的队伍报名,首次实现全球联动。经过 2 天时间的极限挑战, 大赛涌现出不少令人激动的项目。为了让更多朋友了解这些参赛团队背后的故事, 我们将开启 TiDB Hackathon 2020 优秀项目分享系列,本篇文章将介绍 B.A.D 团队赛前幕后的精彩故事。
PingCAP
2021-02-02
6970
当 TiDB 遇到图数据库 | TiDB Hackathon 2020 优秀项目分享
近日,由 TiDB 社区主办,专属于全球开发者与技术爱好者的顶级挑战赛事——TiDB Hackathon 2020 比赛圆满落幕。今年是 TiDB Hackathon 第四次举办,参赛队伍规模创历届之最,共有 45 支来自全球各地的队伍报名,首次实现全球联动。经过 2 天时间的极限挑战, 大赛涌现出不少令人激动的项目。为了让更多朋友了解这些参赛团队背后的故事, 我们将开启 TiDB Hackathon 2020 优秀项目分享系列,本篇文章将介绍 TiGraph 团队赛前幕后的精彩故事。
PingCAP
2021-01-29
6370
使用 go-randgen 测试 join 查询
在数据库的查询中,join 是最常用的查询之一,由于 join 算法实现的复杂性,出现问题的概率较大,我们对 TiDB 中出现过的 join 问题进行分析,将易发生问题的场景归为如下几类 :
PingCAP
2020-12-25
8860
感受开源的魅力,TiDB Committer 白珅的数据库探索之路
Execution SIG 近日又喜提 Committer 一枚,他就是 b41sh 白珅🎉。 白珅同学毕业于上海交通大学电子与通信工程专业,曾就职于新浪、百度、爱奇艺等公司做视频系统和广告系统,现在在一家创业公司做多方安全计算,他的工作是开发存储引擎。在谈到是如何从业务开发转化为数据库开发,他说数据库一直是他想研究的方向,成为 TiDB Contributor 之后他对数据库和存储有了更多了解,正好面试官也了解 TiDB,从此便开启了数据库的探索之路。今天我们就来看看 TiDB Committer 白珅的
PingCAP
2020-11-26
4430
轻松应对海量数据,TiDB 在车好多的实践
车好多集团关注 TiDB 始于 2018 年初,像大多数公司一样,公司发展初期为了快速适配业务开发,大部分数据都存储在 MySQL 中。但随着业务快速发展,存量数据越来越多,我们在 MySQL 面临着如下痛点:
PingCAP
2020-11-20
3520
Rust 编译模型之殇
我的意思并非是此乃 Rust 语言的设计目标。正如语言设计者们相互争论时经常说的那样,编程语言的设计总是充满了各种权衡。其中最主要的权衡就是:运行时性能和编译时性能。而 Rust 团队几乎总是选择运行时而非编译时。
PingCAP
2020-03-02
1.1K0
讨论帖:如果只有两个数据中心,使用 Raft 协议还有意义吗?
对 Raft 有所了解的同学都知道,Raft 一般会使用奇数个节点,比如 3、5、7 等等。这是因为 Raft 是 一种基于多节点投票选举机制的共识算法,通俗地说,只有超过半数节点在线才能提供服务。这里超过半数的意思是 N/2+1(而不是N/2)。举例来说,3 节点集群需要 2 个以上节点在线,5 节点集群需要 3 个以上节点在线,等等。对于偶数节点的集群,2 节点集群需要 2 节点同时在线,4 节点集群需要 3 节点在线,以此类推。实际上不只是 Raft,所有基于 Quorum 的共识算法大体上都是这么个情况,例如 Paxos,ZooKeeper 什么的,本文仅以 Raft 为例讨论。
PingCAP
2020-02-04
2.5K0
点击加载更多
社区活动
【纪录片】中国数据库前世今生
穿越半个世纪,探寻中国数据库50年的发展历程
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档