TiKV

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用： 这么牛X的名单，你不想了解下LSM Tree吗？装X之前，我们先来了解一些基本概念。 设计数据存储系统可能需要考虑的一些问题有：ACID，RUM（Read,Write,Memory）。 ACID ACID 相信小伙伴都被面试官问过，我想简单讨论的一点是：如何 持久化数据 才能保证数据写入的 事务性 和 读写性能？ 事务性可简单理解为：1.数据必须持久化。2.一次数据的写入返回给用户 写入成功就一定成功，失败就一定失败。 读写性能可简单理解为：一次读 或 一次写 需要的IO次数，因为访问速率：CPU>>内存>>SSD/磁盘。 对于单机存储，最简单的方式当然是：写一条就持久化一条，读一条就遍历一遍所有数据，然后返回。当然没人这么干，在内存中我们都还知道用个HashMap呢。 拿Mysql InnoDB举例子：读性能体现在数据的索引在磁盘上主要用B+树来保证。写性能体现在运用 WAL机制 来避免每次写都去更新B+树上的全量索引和数据内容，而是通过redo log记录下来每次写的增量内容，顺序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，然后在一定条件下触发脏页的刷盘。 redo

在刚刚过去的618大促中，京东视频抛弃了私有存储， 将京东智联云对象存储作为京东视频的唯一存储。 在整个618过程中，京东智联云对象存储提供了稳定的服务，助力618完美落幕。 618大促作为京东集团最重要的活动，对所有服务的可用性有极高的要求，京东视频作为京东的一级系统，对存储的故障更是零容忍，那么如何保障系统的高可用呢？下面我们就一起来探讨下京东智联云对象存储在高可用架构设计上的一些思考。 作为一个有状态的服务，影响服务可用性的因素有很多，一般来说会有以下几大类： 硬件/网络故障， 该故障会导致部分数据无法读取或者写入，如果是中心节点故障甚至会导致整个服务无法使用； 误操作， 人工的误操作可能会导致服务不可用甚至数据丢失/损坏，如果是对中心类的节点误操作可能导致整个服务无法使用； 程序Bug， 存储系统也在不断更新迭代的过程中，每次更新迭代都可能会引入Bug，导致系统不可服务甚至数据丢失/损坏。 对象存储是一个复杂的系统，在设计和实现的过程中，我们遵循了以下原则，来保证对象存储的高可用： 所有数据都是三副本存储，数据跨越三个AZ，保证任何级别的硬件故障都不会导致服务不可用； 数据只读化，一个数据存储之后就不会再被修改，这也意味着只要数据在磁盘上，就不会影响到读，保证读的高可用； 使用多个集群共同组成一个服务，在多个集群上做写的高可用，确保写入不会中断； 蓝绿部署，灰度发布

数据库存储了公司的数据，是公司的最重要资产之一。正确性和稳定性是数据库最重要的特性。测试团队之于 TiDB 是一个“破坏之王”的角色，团队的使命是炼成更高、更快、更强的 “无敌风火轮” 技能。在这篇文章里，我们介绍 PingCAP 测试团队（QA Team）是怎么工作的。 我们在做什么？ 我们测试团队是 TiDB 的“破坏者”，用各种手段尽早发现系统的 bug 是我们的工作。TiDB 有丰富的产品线，在这些产品线中，我们面对着不同的挑战。 首先，TiDB 内核稳定是整个系统稳定的基础和重中之重。TiDB 新版本的内核仍然处于高速发展的阶段。因此，测试要尽早发现新特性的正确性和稳定性问题，包括但不限于： 对 TiFlash 列存引擎，测试要构造破坏一致性保证的情况； 在 3.0 中，TiDB 增加了悲观事务，并支持了 RC 隔离级别。在 4.0 中，TiDB 支持了大事务，优化了 GC 的性能。这些特性的重要性不言而喻，必须进行严苛的、长时间的性能测试和稳定性测试； 挑战不断优化的 SQL 优化器和执行引擎，确保功能增强后的系统正确性和性能。例如 Index Merge、SQL Hint 和 SQL Plan Management 等特性； 验证调度稳定性的特性，例如 4.0 中的新热点调度器，构建不同的接近真实场景的负载，找出在这些负载下的系统不稳定的情况； TiKV

作者：李坤 热点问题概述 一直以来，TiDB 的数据访问热点问题，是用户比较关注的问题。为什么这个问题如此突出呢？这其实是“分布式”带来的结构效应。单机数据库由于只有一个节点，是不存在热点问题的(因为性能的上限就是单机的处理能力)，而分布式数据库集群存在多个节点，在达到存储扩展、读写能力扩展的目的上，我们希望大量的读写压力能够平摊在每个节点上，TiDB 也一直在朝着这个目标靠近。 数据库也存在二八原则，80% 的读写在 20% 的最新数据上，以使用最广泛的 MySQL 为例，很多从 MySQL 迁移到 TiDB 的业务，迁移前会使用自增主键，将随机写转为顺序写提高性能。而这种方式，在写入 QPS 较大的 TiDB 集群上，会造成写入热点，原因是 TiDB 使用 range 的方式来进行数据分片，导致新写入的数据集中在一个 range 范围所在的节点，对于这部分写入就会退化成单机的写入性能，未能利用分布式读写扩展的优势。 直面问题 为了解决这些问题，TiDB 在很早之前的 2.0 版本就开始设法改进，这就是新增的表属性 SHARD_ROW_ID_BITS，它的原理是将自动生成的主键在二进制的高几位进行一个位翻转从而将单调递增的 ID 转化为一定范围内的随机 ID，来达到自动将写入数据的压力分摊到不同节点，由于多数业务对于主键通常只需要不重复而不是单调递增

前言 在对数据库进行优化前，我们先要思考一下数据库系统可能存在的瓶颈所在之外。数据库服务是运行在不同的硬件设备上的，优化即通过参数配置（不考虑应用客户端程序的情况下），而实现硬件资源的最大利用化。那么硬件资源有哪些呢，那就无外乎CPU，内存，磁盘，网络这些资源。 作为常用单机数据库（如MySQL，PostgreSQL），最常见的性能瓶颈在哪呢？ 根据我的经验，绝大部分出现在磁盘性能。那我们如何来对它进行优化呢，那就是把磁盘的读写转化为内存的读写（增大数据缓存），或是采用数据压缩，转化为CPU的资源消耗。 对于TIDB，它是网络数据库，可能情况略有不同。我们也需要把网络因素加以考虑。 TIDB原理 要优化一个数据库，首先要对于它进行了解，特别是内部原理。这样我们才能在问题出现时，如何对它进行定位和优化。 TIDB相对传统数据库有很大的不同。 TIDB的整体架构： 官网上关于TIDB的核心见如下文章 三篇文章了解 TiDB 技术内幕： 说存储 说计算 谈调度 TIDB可能的性能瓶颈 通过TIDB的实现原理分析，个人认为瓶颈可能存在于如下方面 1）PD的授时开销，以及GC的抖动 2）raft模块性能问题 3）Region的热点问题 4）TiKV的性能问题 如SST compation，读放大，压缩，Block cache命中率等 TIDB优化之Grafana查看指标

作者介绍：冀浩东，转转公司数据库负责人，负责转转公司整体的数据库运营。 初引入 TiDB 解决了哪些问题？ 转转使用 TiDB 主要解决了两个问题，一个是分库分表问题，另一个是运维复杂度。 分库分表是一个非常普遍的问题，会增加我们业务逻辑的复杂性，并且多维度的 mapping 可能导致我们整体性能的下降。有了 TiDB 我们可以不用再考虑分库分表，不再需要写那么多的复杂逻辑。 对于运维复杂度来说，TiDB 可以做到快速的水平扩展，无需 DBA 进行复杂的数据搬迁，也无需业务进行流量迁移，并且大表的 Online DDL，基本上对于业务感知力度不大。 产生的新问题 引入 TiDB 后，随之也带来了一些新的问题。 部署慢、管理难 。TiDB Ansible 在管理多个 TiDB 集群的时候，会有各种各样不同的异常，这会极大的增加我们的运维复杂度。 热点无法快速定位 。对于电商场景，数据热点是一个比较常见的问题。因为 TiDB 节点众多，无法快速定位热点 KEY，需要查询各个节点的日志， 逐步排查， 排查成本较高。 无法快速查看集群状态 。监控项太多，并且日志都比较分散，某一时间我们要确认集群状态，只能是一步一步来，慢慢的分析，无法迅速对集群异常进行定位。 数据抽取会增加线上响应延时 。这是一个非常常见的问题，因为数据抽取也影响我们 TiKV 的性能。 超大集群无法做到有效的备份

一篇文章带你玩转TiDB灾难恢复 一、背景 高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。 TiDB TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。 PD PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。 TiKV TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点

作者：邹建伟，北京开科唯识技术有限公司 技术专家。 一、互联网理财的兴起 在经济和科技飞速发展的趋势下，相比于以前传统的线下理财模式，互联网理财的模式，因其入围门槛相对较低，选择范围广，加上随时随地用电脑或者手机就能够进行理财，导致便捷性和灵活性的提升，从而让越来越的人们开始接受理财、乐于理财，理财的意识和投入的形态也越来越多。但随着监管制度的管控、用户规模、渠道规模、业务形态、高并发业务请求的不断增长和变化，传统的理财 IT 基础设施建设已经无法满足用户的使用体验，基于分布式系统建设新的业务系统必将破浪前行。 这次我们在中国某大型股份制银行—— G 行的互联网理财系统建设中，也是采用了分布式的数据库系统来取代传统 Oracle 数据库系统，在使用分布式数据库 TiDB 时，遇到了新技术适配的一些问题，通过迁移、开发改造和联调优化，积累了互联网理财场景中的一些分布式数据库 TiDB 的经验。本篇文章分享下在建设中遇到的问题和最终的解决方案，希望对所有准备建设和正在建设互联网理财系统的的用户有所帮助。 二、互联网理财业务简介 互联网理财最早于 2003 年就已经开展业务，主要承载基金代销、理财销售等线上业务，2018 年 4 月随着“资管新规”的发布，银行理财产品起售点由 5 万下调至 1 万，大大促进了银行资管理财业务的发展，更加激发了客户购买理财产品的热情，部分明星热销产品

【合集】TiDB 源码阅读系列文章 （一）序 （二）初识 TiDB 源码 （三）SQL 的一生 （四）INSERT 语句概览 （五）TiDB SQL Parser 的实现 （六）Select 语句概览 （七）基于规则的优化 （八）基于代价的优化 （九）Hash Join （十）Chunk 和执行框架简介 （十一）Index Lookup Join （十二）统计信息（上） （十三）索引范围计算简介 （十四）统计信息（下） （十五） Sort Merge Join （十六）INSERT 语句详解 （十七）DDL 源码解析 （十八） tikv-client（上） （十九）tikv-client（下） （二十）Table Partition * 未完待续 * 由于微信推送的修改限制，以上文章内容以官网博客为准：https://pingcap.com/blog-cn/ TiDB 源码地址：https://github.com/pingcap/ 技术文档（中文）：https://pingcap.com/docs-cn/ 技术咨询可以发送邮件到 info@pingcap.com ，或扫描下方二维码，添加 TiDB Robot 为好友，有任何问题都可以问 ta 哦～ 来源： oschina 链接： https://my.oschina.net/u/4285580/blog/3689566

作者：屈鹏 本篇 TiKV 源码解析将为大家介绍 TiKV 的另一周边组件—— grpc-rs 。grpc-rs 是 PingCAP 实现的一个 gRPC 的 Rust 绑定，其 Server/Client 端的代码框架都基于 Future ，事件驱动的 EventLoop 被隐藏在了库的内部，所以非常易于使用。本文将以一个简单的 gRPC 服务作为例子，展示 grpc-rs 会生成的服务端代码框架和需要服务的实现者填写的内容，然后会深入介绍服务器在启动时如何将后台的事件循环与这个框架挂钩，并在后台线程中运行实现者的代码。 基本的代码生成及服务端 API gRPC 使用 protobuf 定义一个服务，之后调用相关的代码生成工具就可以生成服务端、客户端的代码框架了，这个过程可以参考我们的 官方文档 。客户端可以直接调用这些生成的代码，向服务端发送请求并接收响应，而服务端则需要服务的实现者自己来定制对请求的处理逻辑，生成响应并发回给客户端。举一个例子： #[derive(Clone)] struct MyHelloService {} impl Hello for MyHelloService { // trait 中的函数签名由 grpc-rs 生成，内部实现需要用户自己填写 fn hello(&mut self, ctx: RpcContext, req: