选公司，就要去上升期的！

程序员大咖

于 2021-04-19 10:24:00 发布

阅读量575

点赞数

文章标签：数据库分布式 java 编程语言 jdbc

原文链接：https://j.youzan.com/-2-ESY

版权

????????关注后回复 “进群” ，拉你进程序员交流群????????

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

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

我不由想起了呆过的一家公司。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。我会在项目开始设计的时候，就避免这些问题。