TiDB

代码洁癖狂们！看到一个类中有几十个if-else是不是很抓狂？ 设计模式学了用不上吗？面试的时候问你，你只能回答最简单的单例模式，问你有没有用过反射之类的高级特性，回答也是否吗？ 这次就让设计模式(模板方法模式+工厂模式)和反射助你消灭if-else！ 真的是开发中超超超超超超有用的干货啊！ 那个坑货 某日，码农胖滚猪接到上级一个需求，这个需求牛逼了，一站式智能报表查询平台，支持mysql、pgxl、tidb、hive、presto、mongo等众多数据源，想要啥数据都能通通给你查出来展示，对于业务人员数据分析有重大意义！ 虽然各个数据源的参数校验、查询引擎和查询逻辑都不一样，但是胖滚猪对这些框架都很熟悉，这个难不倒她，她只花了一天时间就都写完了。 领导胖滚熊也对胖滚猪的效率表示了肯定。可是好景不长，第三天，领导闲着没事，准备做一下code review，可把胖滚熊惊呆了，一个类里面有近30个if-else代码，我滴个妈呀，这可让代码洁癖狂崩溃了。 // 检验入参合法性 Boolean check = false; if(DataSourceEnum.hive.equals(dataSource)){ check = checkHiveParams(params); } else if(DataSourceEnum.tidb.equals(dataSource)){ check =

从概念开始 我们先从事务的定义开始。事务即一系列读存动作被当作一个执行单元，这些动作要么全成功，要么全失败，执行动作的过程中保证数据的隔离性和一致性。 我们抛离数据库这个特定场景，先假设一个数据存储设备，我们定义两个标准操作，一个读一个写。当写操作依赖于读到的数据时，执行的顺序决定了得到的结果。 当单线程时，任意读或写操作在这个数据容器上，他必然是符合上述所有的要求的。 当多线程的时候，任意读写，实际上就是导致标准的 race condition，大部分情况下我们是不知道执行结果的。对于单核cpu来说，多线程实际上是cpu模拟，可以理解成所有的操作是合并到一起顺序执行的。在我们不加以控制的前提下，合并的操作队列必然是相对之间无序的。要想多线程情况下，达到单线程一样的事务性。最简单粗暴的办法，就是保证所有请求串行。 保证所有请求串行执行的最简单粗暴的办法就是锁。任意线程操作的适合，上锁，只有这个线程的所有动作做完之后，才能开始下一线程提供的动作。这样一来不管多少事务并行过来，保证了组内的动作一定是串行的。多线程下的动作组的事务性也就保证了。实际上工程后来的进化也是这样的，把执行顺序会影响结果的操作锁住，强制线性执行。 对于数据库来说也是一样，要完成事务的特性，本质还是锁。数据库实际上把读锁和写锁是分开的，颗粒度更细。mvcc的本质也是锁，可以理解成利用 copy-on-write

前几天逛知乎的时候看到一个话题： MySQL没前途了吗？ 最近几年，似乎总有一种声音在说，MySQL可能不太行了，原因无非是这么几条，MySQL功能不如PG强大，原生没有分库分表不如TIDB，OLAP性能差。 可事实真的如此吗？ 首先，MySQL的官网是这么介绍自己的： MySQL是世界上最受欢迎的数据库！ 其次，我们直接看下数据库引擎对数据库管理系统的排名按其受欢迎程度排列，看看MySQL到底行不行！（网址：https://db-engines.com/en/ranking_trend/relational+dbms） 从上图可以明显的看出，MySQL紧随它“老爹”Oracle排名第二，而且MySQL 8.0无论在功能还是性能（整体上），都是目前最好的MySQL版本。 特别是在性能优化相关以及管理、复制、安全方面的功能提升，直呼真香！ MySQL作为一款免费的关系型数据库（开源），对于企业成本来说，无疑是 真香！真香！真香！ 其他的先不多说了，直接上干货吧，跟着腾讯T3大牛来深度的学习一下MySQL。 目录 由于文档内容过多，共计有500页，因此为了避免影响到大家的阅读体验，在此只以截图展示部分内容，详细完整版的可以按照图片中获取到 部分内容展示 深入浅出索引（上） 索引的常见模型 InnoDB 的索引模型 索引维护 小结 深入浅出索引（下） 覆盖索引 最左前缀原则 索引下推

这是一个 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 复制数据以及

最近与同行科技交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。 本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。 NewSQL数据库先进在哪儿？ 首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是"伪"分布式数据库？从架构先进性来看，这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。 NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：

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

作者 | 马超 责编 | 伍杏玲 出品 | CSDN（ID:CSDNnews） 鹰击长空，鱼翔浅底，万类霜天竞自由。——《沁园春 · 长沙》 去年底，一国外程序员写的《中国的开源项目正在破坏 GitHub 的排行榜》博客引起国内开发者热议，他在博客对中国项目占领 GitHub 趋势榜进行了无奈的吐槽。 这样火爆的场面是我国开源事业蓬勃发展的一个侧影。如今越来越多中国年轻程序员投身到开源社区，目前在 GitHub 全球 4000 万注册用户中，中国开发者从数量和贡献度上均位列第二，越来越多的国内企业在国际合作的开源项目中扮演着重要角色。我国的活跃开源项目贡献者，有40%以上是在2019年里加入的，他们大多是 90 后，是年轻程序员的代表。 纵观开源在我国发展的二十多年历程里，开源软件从无到有，从小到大，目前已成为IT软件的基石：我们使用的安卓手机中运行着开源的操作系统，日常访问的网站中由众多开源软件来支撑。 中国开源事业始于互联网，发力于互联网，崛起于移动互联网，并在即将到来的万物互联时代迎来爆发。 那么什么是开源软件，中国开源软件的历史上又有哪些故事和传奇？ 为了讲清楚开源的那些事，笔者找到了中国开源史上的五位代表性人物，他们是 LVS创始人章文嵩、MiniGui创始人魏永明、RT-Thread创始人熊谱翔、TDengine创始人陶建辉、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