江苏龙网

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

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


随着伴鱼的 DBA 团队深度研究 TiDB 并且和 TiDB 的同学进行持续的深入沟通 ， 目前对 TiDB 的掌控力越来越强 ， 大数据同步问题目前已经得到解决 。
现在的情况 现在伴鱼有 10 套 TiDB 数据库 ， 110+ 数据库实例 ， 6 个 TPS 过万核心集群 ， 999 线基本维持在 16ms 左右 ， 响应时间和稳定性都达到预期 。 从目前的情况来看 ， 伴鱼选择 TiDB 是一次非常正确的选择 ， 我们在数据库技术方面弯道超车 ， 避免了对 MySQL 技术的重复建设与积累 ， 享受了 NewSQL 数据库 TiDB 在高可用和水平扩展等方面的技术红利 ， 大大提高了业务研发和 DBA 的工作效率 。当然 ， 这是伴鱼技术团队（特别是 DBA）和 TiDB 技术团队共同努力的结果 。
这里还要特别提一点 ， TiDB 每一次版本升级都会带来惊喜 ， 这是一个可以持续享受的技术红利 。
写在后面的话 目前 ， 在摩尔定律失效、业务的高可用要求和成本优化等综合的大环境下 ， 分布式架构是技术潮流的大势所趋 ， 流量路由策略加多副本部署（微服务是其中的一种架构形式）解决了无状态服务的分布式架构问题 ， Redis Cluster 和 Codis 等方案解决了缓存的分布式架构问题 ， Kubernetes 完成了操作系统的分布式进化 ， 数据库领域自然也不会例外 ， 它的分布式架构趋势一定是不可阻挡的 。 要特别说明一下 ， 这里所说的解决问题是指系统性的解决问题 ， MySQL 业务侵入式的分库分表确实是一个可以解决问题的分布式架构方案 ， 但是需要业务研发配合一个业务场景一个业务场景的去解决 ， 这就不能称之为系统性的解决方案 ， 因为在解决这个问题方式上 ， 业务侵入式的分库分表方案将本应由数据库处理好的大表抽象泄漏给业务层了 ， 在这个问题上 ， 我们认为 NewSQL 是一个系统性的解决方案 ， 而 TiDB 就是当下非常不错的一个选择 。
另外还需要说明一点的是 ， 这是一篇数据库选型的文章 ， 所以只记录了与之相关的内容 ， 比如详细描述了伴鱼技术团队在将数据库迁移到 TiDB 后踩的坑 ， 因为这是我们数据库选型 TiDB 付出的代价 ， 所以一定要详细记录；没有记录在使用其他数据库踩的坑 ， 这并不代表我们没有踩到 ， 比如在使用 MongoDB 的过程中也踩过一些坑 ， 但是因为这并不是我们决定重新做数据库选型的原因（决定重新选型的原因见文章「为什么放弃 MongoDB」部分） ， 所以就没有在文章中记录 。

本文转载自 InfoQ 微信公众号 ， 点击查看原版文章《我们为什么放弃 MongoDB 和 MySQL ， 选择 TiDB》 。


推荐阅读


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

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