TiDB 架构的演进和开发哲学

TiDB 架构的演进和开发哲学
https://segmentfault.com/a/1190000008288188


十问 TiDB ：关于架构设计的一些思考
https://juejin.im/entry/5b29bde4518825749725c28f

其实并没有什么技术是完美和包治百病的，在存储领域更是如此，如果你的数据能够在一个 MySQL 装下并且服务器的压力不大，或者对复杂查询性能要求不高，其实分布式数据库并不是一个特别好的选择。 选用分布式的架构就意味着引入额外的维护成本，而且这个成本对于特别小的业务来说是不太划算的，即使你说需要高可用的能力，那 MySQL 的主从复制 + GTID 的方案可能也基本够用，这不够的话，还有最近引入的 Group Replication。而且 MySQL 的社区足够庞大，你能 Google 找到几乎一切常见问题的答案。

我们做 TiDB 的初衷并不是想要在小数据量下取代 MySQL，而是尝试去解决基于单机数据库解决不了的一些本质的问题。

有很多朋友问我选择分布式数据库的一个比较合适的时机是什么？ 我觉得对于每个公司或者每个业务都不太一样，我并不希望一刀切的给个普适的标准（也可能这个标准并不存在），但是有一些事件开始出现的时候：比如是当你发现你的数据库已经到了你每天开始绞尽脑汁思考数据备份迁移扩容，开始隔三差五的想着优化存储空间和复杂的慢查询，或者你开始不自觉的调研数据库中间件方案时，或者人肉在代码里面做 sharding 的时候，这时给自己提个醒，看看 TiDB 是否能够帮助你，我相信大多数时候应该是可以的。

而且另一方面，选择 TiDB 和选择 MySQL 并不是一刀切的有你没他的过程，我们为了能让 MySQL 的用户尽可能减小迁移和改造成本，做了大量的工具能让整个数据迁移和灰度上线变得平滑，甚至从 TiDB 无缝的迁移回来，而且有些小数据量的业务你仍然可以继续使用 MySQL。所以一开始如果你的业务和数据量还小，大胆放心的用 MySQL 吧，MySQL still rocks，TiDB 在未来等你。