TiKV

这是一个 RA 组招聘文章，但是这里所说的都将是非常坦诚的。RA 是 Real-time Analytics 的缩写。是的，我们负责 TiDB 的实时分析场景，与传统的数仓方案不同，TiDB 的分析能力更偏向于实时场景。 **TiDB 一直的定位是 HTAP ，即拥有 Hydrid Transactional / Analytical Processing 能力的数据库。**不过，不管怎么说，它都是一个源于 TP 场景的产品，而 AP 部分则是处在不断探索和完善的过程中。从最初没有独立的项目，到借助明星项目人气的 TiSpark，到现在整体分析场景架构初步成型。随着公司的不断壮大，我们逐步理清了实时分析方面的产品方向。之前在 DTCC 2019 的讲稿 《TiDB 的 HTAP 之路》算是原原本本说了这一路我们的困扰和努力，有兴趣了解 TiDB 分析场景的同学可以看看。 随着 TiDB 4.0 列存引擎 TiFlash 发布 ，我们从来没有如此确信，这条路虽然还很漫长，但却是正确的。 TiFlash 和 TiSpark TiSpark 是我们很早就推出的 Spark 连接器，通过深度对接 Spark Extension，我们能从 Spark 的 Parsing，Meta Resolution 一直到 Plan 插入算子，全程修改 Spark 的行为逻辑。它不但是 TiDB 体系下

1、大概情况 在asktom的论坛里面，看到有人提问：一个tikv节点磁盘坏了，现在是down状态，tikv.log里面不停写入太多关于这个节点访问不了的日志信息，占据大量磁盘，她的处理方式如下： a、根据ip地址，找到这个节点的store id b、用store delete，来让这个节点处于offline状态，之后快速变成Tombstone状态，他就可以下掉这个节点了。 c、intenvry.ini文件里面，去掉这个节点的ip配置信息。 d、找厂商修复这个节点磁盘，厂商修复后，发现磁盘文件彻底损坏，换了个新的盘给她。 这样的处理后，他发现这个tikv节点，还是加入不了tidb集群，一直处于offline状态，tikv.log日志不停写入，这个的情况该怎么处理呢？根据各位网友的回复和解决过程，整理如下： 2、解决思路 这个节点上的数据已经丢失了，但是集群的数据还在，因为是三副本，所以只要在集群里面下掉这个tikv节点，然后按照添加新节点的方式，加入这个tikv节点，让tidb集群自动补数据进来就可以了。 3、解决方案 a、强行设置tikv节点为tombstone状态 登录pd的server节点，在业务低峰期执行下 tombstone 命令，curl -X POST 'http://{pd_ip}:{pd_port}/pd/api/v1/store/{store_id}/state

今日，云原生计算基金会 ( CNCF ) 宣布 TiKV 正式从 CNCF 毕业。TiKV 是继 Harbor 之后在 CNCF 毕业的第二个中国原创开源项目。从孵化项目晋升为毕业项目，标志着 TiKV 在产品成熟度、项目采用率以及社区持续性等方面取得一系列进展，可应用到各类行业、各种规模的生产环境。 TiKV 是一个开源的分布式事务 Key-Value 数据库，专注为下一代数据库提供可靠、高质量、实用的存储架构。最初由 PingCAP 团队在 2016 年 1 月作为 TiDB 的底层存储引擎设计并开发，第一版于 2016 年 4 月开源。2018 年 8 月被 CNCF 宣布接纳为沙箱云原生项目，在 2019 年 5 月从沙箱晋级至孵化项目。目前，TiKV 已经在知乎、一点资讯、Shopee、美团、京东云、转转等多行业头部企业得到上线应用。 TiKV 通过 Raft 一致性算法来实现数据多副本之间的一致性，本地采用了 RocksDB 存储引擎存储数据，同时 TiKV 支持数据自动切分和迁移。TiKV 的跨行事务最初参考 Google Percolator 事务模型，并进行了一些优化，提供快照隔离与带锁快照隔离，支持分布式事务。TiKV 的核心特性如下： 跨区复制：采用 Raft 协议和 Placement Driver 支持跨区复制。 可扩展性：通过 Raft 复制数据以及

优化器在数据库中一直位于至关重要的位置，性能调优也常常需要围绕优化器来进行。作为数据库厂商，我们希望在各类复杂的业务场景中，TiDB 都能够给出比较理想的执行计划，因此在优化器和执行器上做了非常多的工作和努力，但是选错执行计划或者索引的情况仍然是日常中最为常见的一个问题。 优化器有关的问题可以简单归结为两种： 统计信息准确的情况下给出了错误的执行计划。 另一类则是在统计信息过期的情况下给错了执行计划。 选错索引是其中比较常见的一种情况，用户希望添加索引来加速查询速度，某些情况下，优化器可能会走到全表扫的物理执行计划或者选错索引使得实际执行效果退化成全表扫的情况。 针对上述情况，我们需要从更微观的层面来度量优化器的执行计划和索引选择的性能，评估在优化器上做的改进工作能否切实起到期望的效果。 为什么我们要开发 Horoscope? 为了测量优化器和执行器，从去年开始我们构建了daily benchmark 平台 perf.pingcap.com，覆盖常见的几种复杂查询的测试场景，包含 TPC-H、TPC-DS、Star Schema Benchmark 等，跟踪每天开发分支上这些查询的执行速度情况。 通过 daily benchmark，我们观测和定位到了若干次性能提升以及性能回退的情况。有些提升或者回退是优化器组件上的优化导致的，有些则是 TiDB 其他组件，或者存储层引发的。 虽然

8 月 31 日 - 9 月 4 日，第 46 届 VLDB 会议以线上直播的方式举行（原定于日本东京召开），PingCAP 团队的论文《TiDB: A Raft-based HTAP Database 》入选 VLDB 2020 ，成为业界第一篇 Real-time HTAP 分布式数据库工业实现的论文。PingCAP 联合创始人、CTO 黄东旭获邀在会上进行演讲，分享关于论文的深度解读及在线答疑。 VLDB（International Conference on Very Large Databases）是数据库领域顶尖的三大学术会议之一，于 1975 年在美国成立，由非盈利性机构 VLDB 基金会赞助和运营，以在全球普及数据库技术研究和交流作为使命。 在本篇论文中，PingCAP 重点介绍了其研发的 TiDB 作为一款定位于在线事务处理和在线实时分析（HTAP）混合负载融合型分布式数据库产品的系统架构和核心特性。 TiDB 受 Google 发布的 Spanner / F1 论文 ，以及 2014 年 Stanford 工业级分布式一致性协议算法 Raft 论文的启发。经过 5 年多的产品研发、生产环境上线验证，取得了一系列成果，此次被 VLDB 2020 收录也是对学术界的反哺。 HTAP（Hybrid Transactional / Analytical

TiDB简介 TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。 PS:OLTP与OLAP 数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。 OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作 OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 则强调数据分析，强调SQL执行市场，强调磁盘I/O

近日，云原生计算基金会 (CNCF) 宣布云原生的混沌工程 Chaos Mesh 正式进入 CNCF 沙箱托管项目，这是 CNCF 接纳的第二个由 PingCAP 团队设计并研发的项目。 Chaos Mesh 是一个云原生的混沌工程（Chaos Engineering）平台，可在 Kubernetes 环境中进行混沌测试，在各种复杂的环境下可使用混沌工程来保证系统能正常稳定运行。现阶段，组成部分包括： Chaos Operator：混沌编排的核心组件 —— 完全开源； Chaos Dashboard：用于管理、设计、监控混沌实验的 Web UI —— 开发中。 相比其他混沌平台，Chaos Mesh 具有以下优势： 专注于 Kubernetes 平台 。Chaos Mesh 致力于打造完全云原生的混沌测试平台，只要你系统可以跑在 Kubernetes 上面，那么就可以无缝的集成 Chaos Mesh。 可拓展性 。基于目前 Chaos Mesh 灵活的设计，一方面易于拓展新的故障注入类型，另一方面可以非常方便的集成到其他的测试框架中。 丰富的故障注入手段 。Chaos Mesh 能全方位的帮你对网络，磁盘，文件系统，操作系统等进行故障注入。我们后面也会提供对 Kubernetes，或者云服务自身进行 chaos 的能力。 易于使用 。你无需关注 Chaos Mesh 的底层实现细节

tidb 集群部署详细步骤 一、准备工作 1. 四台服务器（开通外网） 117.50.96.236 centos 7.3 64位 117.50.96.235 centos 7.3 64位 117.50.96.234 centos 7.3 64位 117.50.96.233 centos 7.3 64位 2、修改个机器主机名（永久修改） hostnamectl set-hostname centos701 3. 选取主控机, 并做些简单的配置 我选了 117.50.96.236 作为主控机器 ssh 到主控机 ssh root@117.50.96.236 添加用户 useradd -m -d /home/tidb tidb 赋予权限，并免密 visudo // 在文件尾部添加如下一行 tidb all=(all) nopasswd: all 切换到 tidb 用户 su - tidb 创建 ssh 密钥 ssh-keygen -t rsa 安装 tidb 依赖工具 安装 git sudo yum install git -y 安装 ansible sudo yum install ansible -y 克隆 tidb-ansible git clone -b v3.0.0 https://github.com/pingcap/tidb-ansible.git tidb-ansible

我先说几个最让你兴奋和开心的点吧： 在 TiDB 里，你完全不用担心磁盘容量的问题。 在 TiDB 里，原生支持 Online DDL，你完全不用担心第三方改表工具改表出现各种 Bug 的问题，相信用开源工具改过上 T 级别表的同学都遇到过或多或少的各类 error。 在 TiDB 里，加列、主键扩容字段都是秒级的，比如我刚刚就刚对一张 19 亿的表加完了字段，1 秒完事，这在 MySQL 里要 8.0 才可以，而且还要求列在最后才行。 在 TiDB 里，你会发现 count(*) 惊人的快，一张近 20 亿的表 coun(*) 大概在 1 分钟完事儿，当然，这取决于你的 KV 数量和磁盘性能。 在 TiDB 里，从 MySQL 迁移将变得简单，图形化一键迁移，爽不爽？ 在 TiDB 里，绝大多数情况你会发现比单机 MySQL 有更好的性能，当然也不排除一些例外，例如 enum 这样奇葩的字段类型。 在 TiDB 里......您且往下看，我慢慢和您说。 使用背景 60 云平台对 360 集团各大业务线均有提供服务支持，涉及的数据库支持方案有：MySQL、Redis、MongoDB、ES、GP、PiKA。 其中 MySQL 至今已有过万的实例，目前，对于一些写入量大的业务，已经出现瓶颈。 例如磁盘空间，虽然我们可以通过分库分表的方式，拆分出来，但这对业务和 DBA

作者介绍：许超，VIPKID 资深 DBA 工程师。 本文主要分享 TiDB 4.0 版本在 VIPKID 的一个应用实践。主要涉及两个部分，第一部分是现在 TiDB 在 VIPKID 的一些应用场景，第二部分是介绍一下 TiDB 4.0 给我们带来哪些惊喜和收益。 TiDB 在 VIPKID 的应用场景 首先简单介绍一下 VIPKID，VIPKID 是一家在线少儿英语教育公司，专注于服务 4-15 岁的青少儿和他们家长们，主要提供北美外教一对一授课服务，目前已经有超过 70 万的付费用户。 场景一：大数据量及高并发写入 回归主题， TiDB 在 VIPKID 的第一个应用场景是一些大数据量和高并发写入的场景，如下图所示： 举其中一个例子，我们现在有一套教室排障的系统，这套系统会实时收集教室内的一些事件信息，比如进出教室还有教室内服务初始化的信息，这些信息是通过家长端还有教师端统一上报的，业务同学可以根据这些信息快速定位到教室内的故障，并且做一些排障手段，比如说切换线路之类的来保证一些上课质量。 这套系统目前 TPS 峰值在 1 万左右，每天的新增数据量大概有 1800 万，这张表只保留最近两个月的数据，目前单表有 12 亿左右，数据量其实相对来说已经比较大了，这种数据量如果现在放在 MySQL 里维护成本比较高，所以我们把这套系统的数据整个迁移到 TiDB。