今天小编分享的健康经验：管理100万条数据是怎样一种体验？华为云RDS有多强？，欢迎阅读。
柴司的办公室，就设在北京五环外一座普普通通的写字楼里。在同一楼层里，还有其他十几家同样迷你的团队，包括几家电商公司。我们天天都能看到他们打包、点货。
电商的每一笔订单，都涉及到客户的个人信息，产品信息，订单信息，库存情况，物流信息等等，最终汇总成一个庞大的数据库。从客户下单，到发货、进货，分析营销推广策略等 ..... 全都要围绕着这个数据库来。
尤其在双 11、黑五这样的营销季，订单暴涨，数据库的一个故障，损失的就是实实在在的辛苦钱。
但当多年积累的数据摆在面前的时候，到底应该怎么管理、查询？难道用 Excel 吗？
为了演示这个问题，我们真的生成了100 万条数据，并趁着华为云数据库双 11 的活动，看看管理 100 万条数据是怎样一种体验？
视频版
↓↓ 看完这个视频就知道了 ↓↓
↑↑ 信我，真的超级好看 ↑↑
图文版
首先，当然不能用 Excel.....
不少小企业在订单数小，历史数据不多的时候，会用本地数据库。简单来说，就是自己买伺服器硬體，使用 MySQL 等数据库軟體，花钱请专门的运维人员，从头开始搭建一个数据库系统，并焚香洗手沐浴更衣，祈祷它能 7 × 24 小时稳定运行。
数据量小的时候，本地数据库确实可以应付。但一旦遇到双 11 和跨境电商的 " 黑五 " 这样的营销季，业务量暴涨，只要一次故障，就可能让客户刚下的订单，和原本能赚到的钱，直接消失。
但如果花钱买更强的硬體，又要看着它们在非高峰期落灰闲置。
所以也有一些企业会买虚拟的云伺服器，用来建立数据库，也就是大家说的用 ECS 自建数据库：这相当于把硬體外包了出去，但搭建数据库的成本，包括运维人员的成本，还是得自己负担。哪天运维大哥想喝酒撸串，其他人面对着复杂的数据库页面，只能一脸懵逼。
那云数据库能解决这些问题吗？
我们这次用的华为云提供的基于 MySQL 的关系型数据库服务，也就是 RDS for MySQL，来做个测试，看看它的性能有多强。
首先，我们要搭一个电商数据库，并生成 100 万条数据。数据库中要有客户表，产品表，订单表，以及付款，物流等等表格。总之，要尽可能模拟一个电商公司的真实运作。
之后，我们创建了一个 Python 脚本，用 Faker 库随机创建了 2 万个虚拟用户，以及 15 万条订单，付款和物流数据。
在运行之后，数据库中就出现了云南省哈尔滨市的王秀珍，和广西西安市的丁海燕 ...... 这不重要，反正这 2 万名随机生成的虚拟用户，只是我们测试道具罢了。
产品表里，我们也模拟了售价 823.62 元的小说，和仅售 121 块钱的空调等爆款商品。
而且请注意，这些表之间有着复杂的关系：比如订单表里面有 customer_id 关联到用户表里面的用户 id，付款表里有 order_id 关联到订单表。所以这类数据库才叫 "关系型数据库"。
在创建完这八张表，一共近 100 万条数据之后，我们就可以开始试试 RDS for MySQL 到底有几把刷子了。
我们使用了华为云现在提供免费试用的单机版 8 核 16G 配置，只需要点两下滑鼠，选择自己需要的配置就能直创建数据库，既开即用，相比于本地自建伺服器的繁流程来说实在太简单了～
因为我们已经用 Python 脚本設定好了数据，所以进入数据管理服务界面之后，能直接开始查询。
我们先看看过去一个月内注册的用户，热热身：
结果耗时1ms......
那么提高一下难度：我们想看看每个用户的购物总花费，并按照从高到低的顺序给他们排序，以便于后续给土豪推奢侈品，那可以使用聚合函数来查询：
你猜猜这次要多久？
答案是 177ms，对于 RDS for MySQL 来说，依然是没有流一滴汗。
那么我们继续上难度：这次我们想要查询所有客户的最近一次订单以及支付状态，并按照订单的时间顺序，排序返回最近的 50 名下单客户。这会涉及到多张表的 JOIN 操作，包括客户表，订单表和付款表：
结果我们看整个查询时间也仅仅只有 68ms，依然相当轻松。
那我们再试一些更复杂的业务逻辑：比如我们想查询最近一个月内，每个商品类别的销售总额，以便后续进货。那这次的查询时间是 256ms。
接着我们查询了平均订单金额高于所有订单平均值的客户，还是筛选土豪。这要先计算出所有用户的平均订单金额，然后再从所有用户中筛选出订单金额大于这个数的人。整个查询时间也仅仅只有 37ms。
看起来这些任务实在难不倒 RDS for MySQL，我们让测试同学施展毕生所学，来点狠的考验。
我们想根据消费总额，先找出最有钱的前 10 名客户，并定位他们最常购买的产品类别，方便后续针对性地服务好大客户。那这个查询会涉及多张表大量的 JOIN 操作。结果呢，也只花了 209ms 就完成了查询。
除了照顾大客户，我们还想看看那些已经很久没来下单的非活跃用户。我们可以把最近下单时间超过六个月的客户定义为非活跃客户，然后看看他们和活跃用户相比，对业务的贡献有多大区别。这次的查询时间是 235ms。
在这个拥有接近 100 万条数据的数据库里，我们用光了关于数据库查询的毕生所学。但所有复杂的查询操作，用时也从来没有超过 0.5 秒，不服不行。
最后我们的测试同学疯狂了：他把之前用的一个查询封装成一个函数，然后连续调用它 100 次，可以看到即便这么复杂的查询连续执行 100 次，用时也仅有 18 秒， CPU 利用率只有 2% 出头，也就跟我们筆記型電腦待机时的状态差不多。
除了这些查询测试以外，我们也用性能压测工具 sysbench 对数据库做了测试，这是在設定为 64 线程的测试结果。这里的 TPS 代表每秒执行的事务量，QPS 代表每秒的查询数量。可以看到平均 TPS 为 677，QPS 更是达到 1.3 万左右，足以看出数据库对于高并发场景的性能优势。
而且，我们这里用的只是试用配置，在华为的数据库性能白皮书里，还列出了不同 CPU 和内存搭配的性能测试结果，在其测试场景下，TPS 和 QPS 分别能够实现最高 6400 和 12.9 万的恐怖成绩。
当然，性能只是云数据库服务的一方面而已。对于数据库服务来说，稳定、安全也至关重要。
我们可以在 RDS 的云服务监控详情这里，看到数据库各项的指标监控，并及时收到异常告警。而且还可以根据业务需求，自定义告警规则。
而且很多时候，这些告警都用不着你自己来处理：比如担心磁盘空间不足，那可以在实例的页面选择磁盘自动扩容，自动化运维，不用劳烦正在喝酒撸串的运维大哥。
这也是 RDS for MySQL 相对于本地数据库的另一种优势：不管是性能，还是存储等不够用，那都可以随时随地根据实际需求变更扩容，成本低，弹性强。
此外，华为云 RDS for MySQL 还采取了多部署架构和容灾方案，确保数据库随时可用、且可恢复到任意时间节点。
你可以通过自动备份功能，方便地备份和恢复数据，不用担心数据丢失带来意外损失。
所以相比于自建数据库来说，RDS for MySQL 提供的不光是更强的性能，还有更弹性、稳定、省心的体验。
当然，一些小团队可能觉得 RDS for MySQL 这么强的性能目前还用不上。那可以考虑更轻量级的 Flexus 云数据库 RDS：
它同样提供了开箱即用的体验，也支持数据扩容，备份等功能。性价比很高，很适合中小企业与个人开发者。
我们也帮你体验过了，它在性能也很够用。而且可以无缝更新到标准版 RDS for MySQL，不用担心未来业务增长之后出现瓶颈——这一点很重要，虽然我们是小团队，但出来混，谁还不怀着一个做大做强的梦想呢？
如果你有需要的话，可以看看华为双 11 期间的云数据库专场，赶一波新客专享优惠。
最后，同样作为一家小团队，我们深知大家都面对着类似的问题：我们财力和人手有限，只能把资源集中在主业上。其他的事情，最好能交给简单、高效、稳定、性价比高的外部服务来解决。而不是投入大量成本，慢慢摸索，从 0 搭建。
从这个意义上来说，每家小公司，都高度依赖一个健全、完善的商业基础设施体系。高速的互联网、便捷的物流、广泛覆盖的通讯、协作工具，以及我们今天介绍的，稳定、易用、可靠的云服务等等加在一起，才共同构成了这一基础设施。
它们就像水和电一样，略显枯燥，容易被忽视，但却真实地支持了无数企业和员工的发展与成长。希望中国未来的商业基础设施能越筑越牢。
下期见！
