博客 - 黄东旭

关注 TiDB 的同学，最近可能注意到 TiKV 这边合并了一个不大不小的 PR，支持了一个特性叫做 Follower Read，看到这个功能被合并进主干我确实有点百感交集，还发了条朋友圈庆祝，因为我实在很喜欢这个特性。

在 TiDB DevCon 2019 上，我司联合创始人兼 CTO 黄东旭分享了对数据库行业大趋势以及未来数据库技术的看法。

2018 年对于 TiDB 和 PingCAP 来说是一个由少年向成年的转换的一年，如果用一个关键字来概括就是「蜕变」。

这篇文章是关于 TiDB 代表性“为什么”的 TOP 10，希望大家在了解了我们这些背后的选择之后，能更加纯熟的使用 TiDB，让它在适合的环境里更好的发挥价值。

平时技术说得多，今天说点走心的。

4 月 19 日，我司 CTO 黄东旭同学在全球云计算开源大会上，发表了《Cloud-Native 的分布式数据库架构与实践》主题演讲，以下为演讲实录。

最近这几个月，特别是 TiDB RC1 发布后，越来越多的用户已经开始测试起来，也有很多朋友已经在生产环境中使用，我们这边也陆续的收到了很多用户的测试和使用反馈。非常感谢各位小伙伴和早期用户的厚爱，而且看了这么多场景后，也总结出了一些 TiDB 的使用实践 (其实 Spanner 的最佳实践大部分在 TiDB 中也是适用的，MySQL 最佳实践也是），也是借着 Google Cloud Spanner 发布的东风，看了一下 Spanner 官方的一些最佳实践文档，写篇文章讲讲 TiDB 以及分布式关系型数据库的一些正确的使用姿势，当然，时代也在一直发展，TiDB 也在不停的进化，这篇文章基本上只代表近期的一些观察。

本文先概括的讲一下 Google Percolator 的大致流程。Percolator 是 Google 的上一代分布式事务解决方案，构建在 BigTable 之上，在 Google 内部用于网页索引更新的业务。TiDB 的事务模型沿用了 Percolator 的事务模型。

由于 TiDB 本身兼容绝大多数的 MySQL 语法，所以对于绝大多数业务来说，最安全的切换数据库方式就是将 TiDB 作为现有数据库的从库接在主 MySQL 库的后方，这样对业务方实现完全没有侵入性下使用 TiDB 对现有的业务进行备份，应对未来数据量或者并发量增长带来的单点故障风险，如需上线 TiDB，也只需要简单的将业务的主 MySQL 地址指向 TiDB 即可。

日前，PingCAP 联合创始人兼 CTO 黄东旭在「2016中国数据分析师行业峰会(CDAS)」 “数据库与技术实战”分论坛上，分享了《分布式数据库模式与反模式》的主题演讲。本文为演讲实录。

随着时代的发展，应用和数据的规模越来越大。然而在这个一切都可以水平扩展的时代，你会发现，大多数应用的最下层的关系型数据库，竟然难以找到一个优雅易用的水平扩展解决方案，一直以来不得不依赖静态 Sharding ，牺牲掉事务，然后在业务层各种 Workarounds。作为后端开发者应该深有体会。

最近几年来，越来越多的文章介绍了 Raft 或者 Paxos 这样的分布式一致性算法，且主要集中在算法细节和日志同步方面的应用。但是呢，这些算法的潜力并不仅限于此，基于这样的分布式一致性算法构建一个完整的可弹性伸缩的高可用的大规模存储系统，是一个很新的课题，我结合我们这一年多以来在 TiKV 这样一个大规模分布式数据库上的实践，谈谈其中的一些设计和挑战。