江苏龙网

  1. 首页 > 资讯 > 资讯 > >

观点评论|伴鱼数据库选型的思考，为什么我们 all in TiDB( 三 )


初创公司在技术沉淀和积累上是远远不及一些成熟公司的 ， 这些沉淀和积累就是成熟公司在技术上的先发优势 ， 当技术没有出现变革的时候我们没有选择 ， 但是当技术正出现重大变革的时候 ， 如果我们还做同样的技术选型 ， 那么也需要花同样的时间和成本才能达到成熟公司的水平 ， 然后等大家都开始迁移到新的技术上的时候 ， 这些技术沉淀和积累就可能会变成技术债务 。
所以初创公司应该去预判技术趋势 ， 选择面向未来的技术 ， 在技术上弯道超车 ， 避免自己的技术债务 ， 这个是伴鱼技术团队对技术后发优势的理解 。
成本与效率的衡权
成本和效率是技术选型绕不过的关键点 ， 对于数据库来说更是如此 ， 因为数据库需要的机器等资源成本会占总资源成本的很大一部分 ， 所以伴鱼技术团队在 TiDB 和 MySQL 做选择的时候 ， 对成本与效率进行了深度的评估 。
Unix 哲学是经过时间和实践的锤炼设计原则 ， 很多时候也是伴鱼技术团队的实践原则 ， 比如 Rule of Economy ：「宁花机器一分 ， 不花程序员一秒」 。 在技术选型上 ， 我们是总是期望基础软件做更多的事情 ， 业务研发做更少的事情 ， 如果业务研发需要在业务层去做原本基础软件应该做好的事情 ， 那其实就是基础软件的抽象泄漏了 。 如果基础软件抽象泄漏 ， 必然会导致业务层重复去解决这个问题 ， 这个其实是非常大的隐性成本 。
MySQL 相比较 TiDB 而言 ， 集群的高可用和大表需要分库分表其实就是 MySQL 在对面当前需求的抽象泄漏 ， MySQL 的集群高可用需要 DBA 和基础架构团队花成本去解决 ， MySQL 的大表分库分表方案需要 DBA、基础架构团队和业务研发团队花成本去解决 ， 只不过这些都是隐性成本 ， 不像在搭建数据库集群的时候 ， TiDB 比 MySQL 可能需要更多的机器来的简单直接 ， 所以很容易被忽略了 。
所以 ， 对于成本与效率的衡权 ， 伴鱼技术团队更关注工程师的效率 ， 更关注工程师的心情（在业务上层重复解决一些底层软件抽象泄漏的问题是很影响心情的） ， 更关注隐性成本 ， 而不仅仅是账面明显可以比较的资源数字 ， 特别是在机器越来越便宜 ， 人才越来越值钱的趋势下 。
技术生态与红利的思考
选择一个技术 ， 其实也是选择了这个技术的生态 ， 如果技术生态完善 ， 做事情往往会事半功倍 ， 极大地提高研发效率 。 TiDB 在这个方面做的非常好 ， 全面兼容 MySQL 协议 ， 让 TiDB 的用户享受到 NewSQL 的能力的同时也享受到 MySQL 的生态 ， 这个是非常正确的决定 ， MySQL 生态是几十年的积累 ， 不是一朝一夕可以做到的 。
另一方面 ， 在选择面向未来、优雅高效的解决方案 ， 还是选择成熟的但不够优雅和高效的解决方案 ， 如果选择成熟的解决方案 ， 对技术的掌控会比较高 ， 但是会在效率方面持续的进行付出；如果选择面向未来的解决方案 ， 需要花时间和精力来掌握新技术 ， 但是新技术会优雅和高效的解决问题 ， 我们认为这个就是技术的红利 。 比如对于大表的解决方案 ， MySQL 提供的解决方案是分库分表 ， 业务研发和 DBA 一起配合非常低效地解决这个问题 ， 但是对于 NewSQL 的 TiDB ， 单表几乎可以理解为无限大的（业界已经存在 100 亿以上的表） ， 从根本上解决了这个问题 。 现在伴鱼的大表都从 MongoDB 迁移到 TiDB 上面 ， 业务研发和 DBA 不再为数据的增加而不停地进行分库分表 ， 这个就是巨大的技术红利 。
所以 ， 基于上面的一些讨论与思考 ， 伴鱼决定 All in TiDB ， MongoDB 不再增加新的库和表 ， 正在使用 MongoDB 的业务继续使用 ， 并且对 MongoDB 上的大表进行有计划的迁移 ， 避免进行分库分表操作 。
踩过的坑 在完全掌握一项新技术前 ， 享受新技术的红利是有代价的 ， 特别是伴鱼在 TiDB 比较早期的时候就决定 All in ， 这很考验技术团队的学习和进化能力、新技术的社区和官方提供的技术支持的能力 。 在 TiDB 这件事情上 ， 伴鱼技术团队和 TiDB 的技术支持团队都做的非常优秀了 ， 但是我们从 TiDB 1.x 到目前的 3.x 的过程中依然还是踩了一些坑 。
优化器选择索引问题
单表数据 30W+ ， 查询请求并发约 10+ ， 某次业务上线 ， 新增一个索引后 ， 导致原有的查询索引选择错误 ， TiKV 实例所在机器 cpu 迅速被打满 ， 引发故障 。
线上某张大表 ， 请求量比较大 ， 偶尔出现个别条件走不到索引 ， 导致全表扫描 ， 从而引发接口响应时间的抖动 ， 影响业务 。
线上某张 14 亿的大表 ， 查询条件区分度很高 ， 某天出现特定条件突然走不到索引 ， 导致全表扫描 ， 引发故障 。 后面经过 TiDB 同学排查 ， 系 bug 导致 。
优化器选择索引问题 ， TiDB 从 1.x 到 3.x 的过程中 ， 优化器表现越来越好 ， 同时伴鱼 DBA 团队通过性能监控和慢日志监控提前快速地发现问题 ， 并且对大表采用强制索引的方式避免隐患 ， 目前这个问题已经比较彻底的解决了 。
大数据同步问题
为了进行数据分析 ， 我们把上游各 TiDB 集群的数据通过 Pump / Drainer 汇聚到一个 TiDB 集群供大数据分析使用 ， 在使用过程中 ， 遇到数据不一致、数据同步慢和编码不一致导致同步失败等问题 。


推荐阅读


上一篇：|7月国内共有8个品牌发起召回 累计召回汽车356861辆

下一篇：消息资讯|吴晓波：小米有品是新国货孵化器