TiDB

想必看到此篇的同学对于newSQL已经不是很陌生了，那么直接进入今天的主题： mysql的问题在哪？ 一、不能通过mysql的server把InnoDB变成一个分布式数据库。 因为mysql生成的执行计划是个单机的 二、一个分布式的plan执行起来很复杂且低效。 比如使用分布式方案Proxy，因为它不支持分布式的transaction，也不支持跨节点的join 三、异步或半同步复制 因为有时候数据出问题你不知道是否应该切换节点，因为异步的方式会导致一部分数据“还在路上”。尤其是对于多数据中心的复制和数据中心的容灾。 而NewSQL真正发展起来是在2014年末到2015年初的时候，Raft论文发表之后，真正的NewSQL理论基础就基本确立了。 那么从技术实现的角度分析，为什么这样的技术会诞生呢？它又能解决哪些过去的产品解决不了或者不是最优方案的场景呢？ 首先，举一个范围查询的例子，如果要查找一个班级里成绩在80-90之间的学生，那么通过KV的API的要很麻烦的，但是SQL的优化器就很容易解决此类问题，写一句SQL就可以搞定。 其次是高可用，未来的系统肯定是要设计成Auto-Failover的，即自动恢复，需要人工去干预的容灾系统不是好厨子。 然后针对业务还要说几点： 比如按照ID去分库分表，比如使用一致性哈希去指导节点均衡。如果问题上升到了一定的复杂度

今天在知乎上看到一个问题的告赞回答，觉得说的挺好的，转发一下。 作者：大宽宽 链接：https://www.zhihu.com/question/31955622/answer/1625152059 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 mysql和postgres的早期完全是两个极端。mysql更像是个“基本上满足关系数据库语法的大号KV”，对关系型数据库的高级功能支持的很不好。我入行时接触的MySQL 5.1和MyISAM存储引擎，不支持ACID，但有如下几点在当时的互联网公司看来是非常合适： 互联网公司为了扩展，长期的经验是，仅仅把数据库当作是一个“存储”，而非存储+核心数据逻辑的计算节点。大量的计算都在业务服务器上进行，而业务服务器可以无限水平扩展，而无需担心有状态的数据迁移问题； 因为没有提供很多高级功能和数据一致性的保障，mysql对于简单的sql支持的反而更加直接，在速度上有很大的优势； 对于OLTP，完全不需要复杂的数据处理功能。简单的select ... from ... where id = xxx; insert into xxx；update xxx set xxx=xxx where id = xxxx是OLTP的主流功能。基于这些功能的ORM的出现大大的提高了生产效率；对于OLAP

先问一下，你们公司的主存储技术是什么？估计很多人答案都是 MySQL。 但，SQL 还够用吗？ 那你再想一下，你当下的业务用 MySQL 做主存储还能支撑多久，如果业务量暴增，你能怎么做，愿意花多大价钱进行扩容？ 如果遇到容量和性能问题就升级服务器，开发也太好做了。你要是只能想到这个答案，那今天要聊的这个话题——分布式数据库，对你来说跨度还挺大。 1分钟快速认识分布式数据库 分布式数据库其实就是多个节点的数据库共同形成一个全局数据库来提供服务，优点基本都在 以上对比里了， 访问速度更快，更强的可扩展性，支持更高的并发访问量。 各大互联网公司，甚至金融行业都开始使用分布式数据库，阿里巴巴有 OceanBase 风光无两，TiDB 在银行大受欢迎，各种云厂商相继发布重量级产品。 （2021 年数据大会上，阿里云发布了分布式数据库使用率统计图） 分布式数据库，是必然趋势 这个图展示了数据库技术这些年的技术探索，其实就是个逐渐“分布式”的过程。从 SQL 到 NewSQL 的技术探索，让分布式数据库能够满足两大核心要求： 完整的 ACID 支持，分布式事务和数据一致性保证； SQL 语法的完全兼容，对 SQL 业务的完整支持。 技术的完善性，加上学术与商业氛围浓厚， 分布式数据库已经是大势所趋。 有人会说，现在公司的数据库技术就挺成熟，有必要跟风追新吗？ 公司做技术选型和架构设计

前言 前面三章基本把 TiDB 的环境弄好了，也做了一下简单测试，有兴趣的同学可以看一下： TiDB 入门（一）：TiDB 简介 TiDB 入门（二）：虚拟机搭建 TiDB-Ansible 部署方案 TiDB 入门（三）：简单测试 本来还有一些用 jmeter 压力测试的，后来测试的结果非常不好，就不想写出来了，因为自己毕竟是用虚拟机模拟的和 TiDB 官网推荐的配置差很多，如果自己写出来是有失偏颇的。 为何“跑路” 穷 我们可以看到，TiDB 对性能要求特别高，简单看一下配置。参考： 软硬件要求 开发测试环境: 组件 CPU 内存 本地存储 网络 实例数量(最低要求) TiDB 8 核 16 GB+ 无特殊要求 千兆网卡 1（可与 PD 同机器 PD 4 核+ 8 GB+ SAS, 200 GB+ 千兆网卡 1（可与 TiDB 同机器 TiKV 8 核 32 GB+ SSD, 200 GB+ 千兆网卡 3 生产环境： 组件 CPU 内存 硬盘类型 网络 实例数量(最低要求) TiDB 16 核+ 32 GB+ SAS 万兆网卡（2 块最佳） 2 PD 4 核+ 8 GB+ SSD 万兆网卡（2 块最佳） 3 TiKV 16 核+ 32 GB+ SSD 万兆网卡（2 块最佳） 3 监控 8 核+ 16 GB+ SAS 千兆网卡 1 开发环境大概就需要两台 DELL 服务器才能满足

TiDB Hackathon 是由 TiDB 社区主办，专属于全球开发者与技术爱好者的顶级挑战赛事，通过开发与应用实战，鼓励开发者基于 TiDB 及上下游生态项目实现技术与商业创新。 自 2017 年创办以来，TiDB Hackathon 在过去的三年连获好评，吸引了全球 800+ 技术爱好者参与，先后诞生了 Unified Thread Pool、TiDB-wasm、TiDB 跨数据中心解决方案等一些列高质量项目，已经成为全球数据库技术领域的知名赛事。 本届大赛主题为「∞」，参赛项目可围绕 TiDB 组件或结合 TiDB 生态周边（包括：TiKV、ChaosMesh®、Backup & Restore（BR）、TiDB Data Migration（DM）、Dashboard、Flink、Elasticsearch 等上下游社区、用户&企业业务场景等）进行创作，用最硬核的技术和最炸裂的创意去创造无限可能。 赛事亮点 🌟 奖金加码： 除了金额丰厚的一二三等奖，本次大赛还将联合赞助商推出特别奖，以及增设最佳人气奖，欢迎小伙伴们围观 Demo 现场投出你心中最佳的项目。 🌟 全球联动： 去年北上广三地联动 Demo 的场景还历历在目，今年 TiDB 将更进一步，联动全球开发者共享代码狂欢。 🌟 项目落地： 通过 TOC（Technical Oversight Committee）

攻击性不大，侮辱性极强 1、SQL语句执行流程 MySQL大体上可分为 Server层 和 存储引擎层 两部分。 Server层： 连接器 ：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。 查询缓存 ：查询后的结果存储位置，MySQL8.0版本以后已经取消，因为查询缓存失效太频繁，得不偿失。 分析器 ：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。 优化器 ：多种执行策略可实现目标，系统自动选择最优进行执行。 执行器 ：判断是否有权限，将最终任务提交到存储引擎。 存储引擎层 负责数据的存储和提取。其架构模式是 插件式 的，支持 InnoDB 、 MyISAM 、 Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB ，它从MySQL 5.5.5版本开始成为了默认存储引擎(经常用的也是这个)。 SQL执行顺序 2、BinLog、RedoLog、UndoLog BinLog BinLog 是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。 STATEMENT 模式 内容 ：binlog 只会记录可能引起数据变更的

Python实战社群 Java实战社群 长按识别下方二维码， 按需求添加 扫码关注添加客服 进Python社群▲ 扫码关注添加客服 进Java社群 ▲ 作者丨sowhat1412 来源丨sowhat1412（ID：sowhat9094） 攻击性不大，侮辱性极强 1、SQL语句执行流程 MySQL大体上可分为 Server层 和 存储引擎层 两部分。 Server层： 连接器 ：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。 查询缓存 ：查询后的结果存储位置，MySQL8.0版本以后已经取消，因为查询缓存失效太频繁，得不偿失。 分析器 ：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。 优化器 ：多种执行策略可实现目标，系统自动选择最优进行执行。 执行器 ：判断是否有权限，将最终任务提交到存储引擎。 存储引擎层 负责数据的存储和提取。其架构模式是 插件式 的，支持 InnoDB 、 MyISAM 、 Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB ，它从MySQL 5.5.5版本开始成为了默认存储引擎(经常用的也是这个)。 SQL执行顺序 2、BinLog、RedoLog、UndoLog BinLog BinLog 是记录所有数据库表结构变更（例如create

由《金融电子化》杂志社主办的“2020 中国金融科技年会暨第十一届金融科技及服务优秀创新奖颁奖典礼”于 12 月 18 日线上播出。 大会以“奋进新时代 迈向新征程”为主题，作为企业级开源分布式数据库的领导厂商，平凯星辰 (PingCAP) 创始人、CEO 刘奇受邀参与高峰对 话。大会现场表彰了 2020 年度在金融科技领域实践、探索和应用中具有重大突破的优秀解决方案， TiDB 开源海量分布式数据库在保险核心交易业务的应用解决方案斩获“2020 年度金融科技产品创新突出贡献奖”，充分肯定了 PingCAP 在金融科技领域的创新成果与能力。 会上，中国工商银行首席技术官吕仲涛、中国银行首席信息官刘秋万、中国建设银行信息总监金磐石、中国金融电子化公司副总经理潘润红等主要领导与平凯星辰（PingCAP) CEO 刘奇先生一起进行了高峰对话及金融科技领域的洞察分享与探讨。 刘奇表示，“平凯星辰作为一家专注在分布式数据库基础软件领域开拓的科技企业，在中国经济迈入“十四五”时期和金融科技加速布局建设的今天，我们深感责任重大。在过去几年里，我们投入整个公司和团队的资源， 全力打磨核心产品 TiDB 分布式数据库，在帮助金融企业打通数据融合通道，协助建立云数据处理能力，支持与保障更加安全稳定可控的数据库服务方向 上全力以赴的进行产研与落地工作，取得了一定的成绩

TiDB也使用了一段时间，持续记录一些日常，防止大家也踩到同样的坑~ 🥕 raft sync-log 目前,公司使用的Tidb分别部署在生产环境和测试环境，生产环境的是在阿里云，而测试环境是在公司的机房。周末的时候，机房不知道为啥断过电，什么都不知道的我，周一来到公司发现测试环境的Tidb挂了（这是肯定的，因为停过电嘛~），然后就是怎么都启动不了，相当崩溃。一查日志发现： 下面是raft的介绍: 经过分析，得出原因应该是raft在做副本的时候出了问题。测试环境是3个kv示例，那每条数据将会有2个node去持有。node1已经将raft-log写入磁盘，而node2在写入时，发生了断电，导致node1，node2的服务和磁盘都挂掉，造成了raft日志出错。 避免这样的问题，可以设置参数（类似mysql的 innodb_flush_log_at_trx_commit ），保证每个数据的提交都能落地。不过这样就会降低性能。 联系了Tidb的开发人员，处理该情况的工具还没有完善（该问题已有 issues ），没办法删掉出错的数据，因为测试环境的数据量比较大，迁移出来太费时，还好数据不是很重要，清理了数据就可以启动了。当时Tidb的版本如下： 所以小伙伴们在部署Tidb的时候要考量是否可能出现同时挂掉的可能（虽然概率不大），尤其是对于一些关键的业务，需要更多的考虑，比如更多的副本

TiDB Hackathon 是由 TiDB 社区主办，专属于全球开发者与技术爱好者的顶级挑战赛事，通过开发与应用实战，鼓励开发者基于 TiDB 及上下游生态项目实现技术与商业创新。 自 2017 年创办以来，TiDB Hackathon 在过去的三年连获好评，吸引了全球 800+ 技术爱好者参与，先后诞生了 Unified Threat Pool、TiDB-wasm、TiDB 跨数据中心解决方案等一些列高质量项目，已经成为全球数据库技术领域的知名赛事。 本届大赛主题为「∞」，参赛项目可围绕 TiDB 组件或结合 TiDB 生态周边（包括：TiKV、ChaosMesh®、Backup & Restore（BR）、TiDB Data Migration（DM）、Dashboard、Flink、ES 等上下游社区、用户&企业业务场景等）进行创作，用最硬核的技术和最炸裂的创意去创造无限可能。 赛事亮点 奖金加码： 除了金额丰厚的一二三等奖，本次大赛还将联合赞助商推出特别奖，以及增设最佳人气奖，欢迎小伙伴们围观 Demo 现场投出你心中最佳的项目。 全球联动： 去年北上广三地联动 Demo 的场景还历历在目，今年 TiDB 将更进一步，联动全球开发者共享代码狂欢。 项目落地： 通过 TOC（Technical Oversight Committee） 投票表决的优秀项目将在大赛结束后进入