看完这个故事，你就知道程序员为什么选公司就要去上升期的

https://www.toutiao.com/i6948390604984402462/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1617943363&app=news_article&utm_source=weixin&utm_medium=toutiao_ios&use_new_style=1&req_id=202104091242420102120380721500ECBC&share_token=895EC6CC-EEE7-4CEC-ACAD-0B4456097A97&group_id=6948390604984402462

人的发展，还是要看时机的。

我不由想起了呆过的一家公司。2年时间，我们的团队，由刚开始的100多人，发展到最后的2000多人，经历了一次次的技术迭代升级。这是一笔宝贵的财富，我的技术水平，也得到了极大的提升。

非常的感谢我们当时的技术总监。如果不是他亲自挂帅，带我们完成了一波波的技术升级，我不会了解到统一、正确的思路，能够节省多少时间。

这一次，我将简单的回忆一下数据治理方面的迭代，希望能从中找到一些共通的东西。

来一波重要的思路总结。

当年，入职第二天，领导给我的第一个任务，就是选一个长远的、能扩展、能维护的数据库。

由于历史的原因，公司的数据库选用了Oracle，但过了几年，噩梦开始了。Oracle极度复杂，在换了几个DBA后，没人敢动这台机器。领导萌生了换Oracle的念头，是因为一次事故。有一次，因为系统断电，Oracle死活启动不起来，给Oracle的技术支持打电话，结果来回推脱，到最后只能花了非常高的价钱，请一些代理机构来解决。大家得出的结论是：Oracle的技术支持并不可靠，还经常发生宰客行为。

核心技术要掌握在自己手里。经过在db-engines进行调研，综合国内的招聘情况，我们最终还是保守地选择了MySQL，而不是性能更高功能更全的Postgresql。

曾经想过全部使用NoSQL，但被领导果断的被判定为无知。虽然现在有各种各样的数据库，比如时序数据库、海量存储、各种NoSQL等，但目前使用最多的，还是RDBMS。在RDBMS方面，在互联网，Oracle的优势，已经完全比不上MySQL了。原因就在于MySQL的技术栈，工具全人才多，而且具有良好的扩展性。如果在一个互联网公司，领导选择采购Oracle，那一般是判定他的脑子被驴踢了，或者采购的脑子被钱砸了。

以前的领导，脑子肯定是被驴踢了。

但选择了MySQL，就要承受MySQL所带来的技术投入。随着系统的变大，这种投入也逐渐膨胀，但总体看来还是好于表面买放心的Oracle。在这期间，我经历了数据清洗、数据迁移、各种分层的数据库模型建设，是一笔非常宝贵的经验。

1. 重构填坑

在接下来很长一段时间里，我们做的工作就是重构、填坑。我知道这很难，很多公司就死在这一环，因为它需要持续的投入。在此期间，如果同时要求功能性建设的话，这个战线就会拉的很长，很少有领导能够撑过这一环。

幸运的是，我们的领导有魄力，能够向长远的目光去看，顶住了短期的无业绩压力，之后的很多改造和扩展顺风顺水，节省了很多人力和财力。但这种未雨绸缪的领导毕竟是少数的，我后面遇到的大多数公司，都是被销售和产品牵着鼻子走，到最后系统越做越烂以至于无法维护。

那对于数据库来说，我都获取了哪些经验呢？

小的系统叠加代码，可能会陷入玩SQL的状态。加功能，堆代码，一行SQL走天下，使用的SQL函数，也是越来越偏门。这个非常有意思，你的sql玩得越6，那么给后人埋的坑，越多。你的一句魔幻SQL，会给后人带来十倍甚至几十倍的重构代价。

这也是为什么不使用Oracle这样一些数据库的原因，因为里面80%的附加功能，基本上是用不到的。即使是MySQL，按照公司的规范，一些官宣的特性，在公司内也是严格禁止的。

因为功能和扩展性，完全是相反的两回事。除非是访问量固定，或者是外包这样的一锤子买卖。

随着业务的发展，系统的性能也发生了瓶颈，报应也如期而至，以前的技巧变成了现在的累赘。很快，以前用Oracle时写的一些代码，开始显现出它的弊端。

各种慢查询层出不穷，查询界面一直转圈
经常就发生全文扫描，DBA疲于奔命，最后撂挑子不干了
想要加缓存，发现无从下手，牵一发动全身
想要分库分表，结果根本找不到能分的维度，只好在一次次的讨论会中灰溜溜地承认现实

很多老板搞不明白。我原本一个好好的系统，为什么用户量才翻了一倍，大部分代码就得重写呢？很多项目经理搞不明白。技术人员在那里优化了好几个月，为什么我的功能体验不升反降呢？

那是因为。你的团队，在相当长的一段时间里，在填坑。

凡是都有规范，都有定律。照顾了工期，质量就要打折，如果加上开发人员并没有长远意识的话，接下来很大的工作，就是填坑。坑填不完，接下来的工作就无法进行。

2. 数据表的类型

首当其冲的，就是数据库表的重构。比如以什么ali规范为标准：一个超过3个表的联合查询业务，大概率是不合理的。这个虽然极端，但却是非常重要的指导意见。

忘掉什么数据库范式，我们将存在两类表：小表和宽表。

我们的改造过程，也是按照这种划分方式进行的。

小表提供了最基本的数据，可能一个简单的KV就完成了。一些联合查询，并不通过SQL进行JOIN查询，因为我们吃过这个东西的亏。

分布式系统的特点，就是消耗时的多次查询，比机器hang在那里更加有生命力。换句话说，程序里循环1000次10毫秒的查询，比单次查询耗费6秒要强的多。松散的结果，不仅在业务上能支持天马行空的自由组合，在扩展性上也更胜一筹。唯一的一个弱点，就是编码的要求高了，代码量多了，不过这也是我们所希望的。

这对一些运行系统来说，是天大的福音。但是问题又来了，统计性的工作又该怎么做？比如报表。

这就是宽表的用途了。宽表通过冗余的方式，提供了某个重要功能常用的分析数据。这种表的字段一般都特别多，在写入时通过拼接获取冗余数据，一般用在读多写少的场景。所以到最后，我们的业务数据，根据查询的维度，写了很多份。不同的团队维护着不同维度的副本，也是团队成员开始爆炸、业务开始飞速发展的开始。

为什么要这么做？主要还是解耦。有时候，我们通过MQ等分发数据；有时候，我们通过Binlog分发数据。同一份数据，因为维度的不同，有着不同的用途，最主要的业务就减少了宕机的风险。

3. 分库分表

理想很美好，但现实很骨感。在我们打算把大表小表方案落实的时候，一件更重要的事渐渐地浮上水面：我们的数据量已经到了一定级别，需要进行分库分表。

这也证明了领导的先见之明，如果采用的是Oracle数据库，我们的IT费用将会因为购入新的数据库实例急剧飙升。纵向扩展Oracle也能暂时的解决问题，但它总有爆发的一天。

分库分表分为纵向拆分和横向拆分。按照业务进行拆分这一块，我们本身就已经做的很好了，倒是单表的上限处理（比如十几亿的订单表），费了我们很大的功夫。

目前行业内的分库分表方案，集中在以代理方式存在的MyCat，还有以驱动形式存在的ShardingJDBC。为了尽量的少引入额外的维护成本，加上它们的效果都差不多，我们最后的评估，采用的就是ShardingJDBC。当然它的弱点也是很明显的：以Java驱动形式存在，不支持异构系统，比如golang开发语言。幸运的是技术爆炸这一块研发部控制的很好，我们的多数系统是Java的。

让人感叹技术统一的好处。永远不要为了尝鲜，引入一些与公司架构不一致的东西，会给所有人带来困扰。

技术组件好选，但等到真正落实下来，却非常的痛。一句原本好好运行的语句，到了分库分表环境下，竟然就不能运行。归根结底还是SQL写得太不规范了，用了一些不标准的东西，比如用了distinct、having、union等。这些在单库表的情况下，运行的很好。但到了分库分表环境下，由于组件的限制，它们通常不能好好工作。

这部分是最耗时的折腾。有些SQL由于改不动了，我们最后几乎把业务重写了一遍，最终使用最简单的CRUD完成了所有的功能。如果想要我再来第二遍的话，我会毫不犹豫地说：No。我会在项目开始设计的时候，就避免这些问题。

4. 数据同步

终于完成了数据库的扩展性，只要硬件够，可以支持到天荒地老了。现在有时间有精力，来看一下数据同步的问题了。

上面我们说了，有一大堆小表和大表，用在不同的场景。这些分库分表的原始表，我们就可以把它当作小表，需要把它同步到其他地方。

不同业务通过共享数据库来共享数据不得不说是个非常蠢的主意。这个时候就需要一些数据同步工具。我们采用了两种同步方式。一种是消息，一种是binlog。

一些有着明显业务属性的信息，我们是通过消息分享的。比如订单，在信息落地到DB后，我们会同时发送一条MQ消息。对订单信息感兴趣的业务方，只需要订阅对应的主题就可以了。当然这里有一个非常大的话题，就是分布式事务（关于这部分，我会在其他文章中分享），来保证消息能够发送成功。

一些有着共通特性的数据，因为技术原因需要扩展成宽表，或者转化为其他维度的查询数据的时候，就可以通过binlog，把数据共享出去。对于MySQL来说，国内的canal组件，能够非常容易地完成这个转变，我们选的就是这门技术。

那什么时候用MQ，什么时候用Binlog呢？MQ的信息流明显是比Binlog清晰的，但它的开发难度大，有更多要考虑的因素。如果非要找个边界的话。我觉得MQ主要用在跨业务方的数据交互上，而Binlog是用在自己业务组内的技术。

为了不对主库造成影响，我们一般会拉出多个从库，甚至是从库的从库。一部分从库参与读写分离的业务，一部分从库，就专门为Canal提供数据。

在我离开这家公司的时候，领导正在带领着兄弟们搞异地机房的数据同步。我知道很多公司可能永远用不上，但没有亲身经历这一块，还是有一点小遗憾的。

5. 数据仓库

数据同步是个非常脏的活，经常因为异常，造成了同步终止，这时候依赖的业务方就会陷入抓狂状态中。更脏的活，还是ETL。非常的佩服做数据清洗的同事们，是他们让专注于业务开发的同学，用着清清爽爽的数据。

就是这样令人啼笑皆非，因为某些需求，我们需要把分库分表完的数据，重新给合起来。比如某些报表业务需要全量的数据。那就需要把所有的数据汇总到一个地方进行查询，比如ElasticSearch、MongoDB等。

数据仓库有很多选择。如果数据量适中，就可以选择ElasticSearch，MongoDB等。如果数据量非常大，那就需要考虑Hbase，Druid等大数据产品。在我们这里，按照功能分了三个层次：

RDBMS（MySQL）作为原始的数据存储，提供扁平快的数据通道
ElasticSearch作为大型宽表，分布式的类RT的存储。用来存储一些中等规模的数据，并提供一些中延迟的搜索功能，比如商品搜索等
Hbase、Druid作为海量的存储系统，存储系统所有的历史记录，并提供离线分析功能

现在的风向，是使用一些分布式的数据库，比如PolarDB、TiDB等，由于它们在接入层采用的是MySQL协议，所以数据迁移起来、代码改起来是相对简单的。我们有部分非核心业务，已经迁入了这种分布式数据库，但是核心数据还是不敢动，需要更多的时间进行验证。

6. 总结

这几年走下来，我觉得最重要的收获，是对于技术的规划性，而不是车到山前必有路的勇往直前。这种工作，需要有能量的人去做。我们的技术总监，对于技术如何迭代，思路是非常清晰的，加上他一直在力推这些事情，就节省了非常多的论证时间和扯皮时间。在后面的从业生涯中，我再也没见过这样的技术总监。