数据库发展至今，已经有许多人为的分类和产品，开发者使用最多的关系型数据库，包括MySQL、PG和SQL Server；为适应新的业务逻辑和场景而生的缓存数据库Redis、Memcached；顺应数据爆炸时代的分析型数据库ClickHouse；以及一些其他的图数据库和时序数据库等。
而在开发者眼中，这些分类并不是这么重要，大多数开发者使用数据库的日常是这样的：申请资源——设计表结构——写SQL语句——找DBA审核语句——复现诡异问题——申请扩缩容。而在一遍遍的日常中，总有些痛点让人糟心。接下来就给大家盘点开发者使用数据库时遇到的三大糟心时刻，看看你中招了吗？
产品上线前，数据库总会经历各种各样的测试，在确定压力正常，没有慢查询，数据库各方面都没有问题后，上线了。然后发现：数据库实例CPU打满，全是慢查询
回过头来究其原因，就是在测试环境的压力模拟很难完全模拟到生产环境的各个情况，而如果在各种迭代中都进行全量测试的成本又太高。而在选择前者的时候，就容易出现一些不易觉察的问题。
当然有办法，以后测试，不妨加上这个：数据库智能诊断报告。
在测试环境中开启全量审计日志，记录运行过程中的各种行为，业务全量回归。这时候，数据库则可以基于全量审计日志和智能诊断系统获得一份专属的数据库诊断报告，这个报告基于真实的运行情况，通过AI来提前发现潜在风险并进行规避。
往往只有热点来的时候，才能直观感受到网民的力量有多恐怖，无论是突发新闻热点，还是各种突然的爆火，在面对业务突发场景，开发者第一件要做的事就是扩容，但扩容，哪有那么简单。
但为了保险起见，传统的数据库扩容时必须先拷贝，动辄上T的数据，掐指一算可能拷贝就要2小时起步，上不封顶，这时候，高峰期都过去了，还扩什么容？
这种情况下，只需要计算存储分离，扩容太慢的问题就可以迎刃而解。腾讯云数据库TDSQL-C serverless版就是一款这样的产品，在这种计算存储分离的架构模式下，数据库扩容没有数据拷贝过程，开发者直接拉起虚拟机即可提供新的服务，从而实现秒级扩容，在高峰期过后，相应的可以秒级缩容。同时，得益于这样的技术架构，在运维过程中也可以少考虑限流、分流等技术方案，省事省心。
数据库+缓存的方案已经是很多情况下比较普遍的模式了，这种情况下，怎么加，数据库一致性怎么保证，缓存淘汰怎么处理？面试的时候，类似的问题都能聊很久，实质上，当回归到最本质的需求，只是需要能够又快又准地进行数据读写，之所以出现这种方案，就是由于数据库不够快，缓存又太贵。
这时候，不防试试这款神器——腾讯云开源的KV存储数据库Tendis，在读写时拥有和Redis媲美的速度，同时保证全量数据落盘，不需要考虑缓存数据丢失等问题，在这种模式下省去了数据库+缓存带来的各种数据问题，比纯Redis成本降低85%，同时，以后面试的时候，也许也可以少费点口舌了。
实际上，这些“糟心时刻”，往往开发者都是受害者，很多时候，这些多熬的夜，多掉的头发，可能只是因为数据库产品本身的问题导致的。那么，数据库本应是什么？未来的数据库又可能是怎样的？
林晓斌（网名丁奇）给出了他的答案——数据库的未来就是“没有数据库”。智能化、超融合和去服务化将是未来的数据库形态。在过去，数据库也在不断地由繁化简。在云化前，开发者还需要关注数据库部署位置，两个节点放哪个机房，扩缩容还受到物理空间的限制，现在如果选择上云，就不需要考虑这些，但这并不是数据库发展的终点。数据库简化到最后，应该是无感的。首先，开发者不需要关系数据库的部署，甚至不需要关注数据库的性能和调优，没有所谓的数据库瓶颈，所有工作都交给已经云化和智能化的产品本身来完成。其次，在数据库之间是相互融合的，就像内存和存储从MySQL+Redis向Tendis演变一样，曾经，数据存取用交易型数据库，数据分析用分析型数据库，未来，希望每条数据都可以在各种类型的数据库之间自由流动，开发者不用再关心数据库的特性和选型。最后，回归最本质最朴素的需求，数据库存在的意义就是存取和利用数据，这里面，数据库本身并不重要，就像自来水，什么源头的水，哪家公司的产品，什么样的管道，这些并不重要。数据的使用发展到最后，可能只需要一个个函数或者更加简洁的形式来体现，至于背后是什么数据库存的，数据库怎么存的，就是一个完美的黑箱，复杂，但好用。
- End -
元宵节小福利，回复“红包封面”，无门槛领取牛气冲天「红包封面」，先到先得
更多精彩
