微信开发中 ACCESS TOKEN 过期失效的解决方案详解
378
2023-11-24
第一批上线国产数据库的系统该优化了
来源：白鳝的洞穴
随着XC工作的深入，一些较为关键的系统已经开始使用国产数据库了。上周和一个客户进行交流的时候，他们就提了一些关于迁移到国产数据库后的性能问题。比如他们的一个业务系统迁移到某国产数据库后变得忽快忽慢，快的时候与以前Oracle差不多，而慢的时候要慢上数倍，导致业务超时。
他们也请了数据库原厂来分析，不过原厂认为数据库本身没问题，问题出在他们使用的虚拟机上，建议他们把应用从虚拟机迁移到物理机上。细问下去，原厂也说不清楚具体的原因和道理。因为他们对这个国产数据库不熟悉，使用起来就像面对一个黑匣子一样。和传统的Oracle等数据库不同，国产数据库在性能优化方面的理论与实践确实不多。我们团队简单总结下来，国产数据库的优化不外乎以下几个方面。首先，更换更强的硬件。用硬件的性能来解决国产数据库的性能问题，反正现在硬件价格越来越低，性能也是逐年提升，替换硬件是最简单有效的优化工作。不过这种硬件替代效果有限，能整体提升数据库的性能，但是不能解决一些复杂的应用性能问题。而且通过花钱买新硬件也不是一个可持续的方式，一套两套还行，系统多了，地主家也玩不起。其次，优化IO。更换更强大的IO设备，将IO分散到更多的磁盘上等，对于解决因为IO问题而出现的数据库性能问题，是有立竿见影的好效果的。大多数国产数据库的性能问题是执行计划不够好引发的，从底层提升IO能力，降低IO延时，效果还是挺明显的。第三，优化操作系统。通过操作系统底层的参数优化去进一步挖掘潜力，这种方式有一定效果，但是效果有限。目前大多数国产数据库的性能受操作系统影响较大，如果出现同一条SQL执行计划相同，但是执行起来忽快忽慢，那么和操作系统底层调校得与国产数据库不够匹配可能是有一定关系的。只不过这种调校难度较大，甚至同一种数据库在不同的应用负载下，都会有所不同，因此这种优化是成本较高的。第四，SQL或者应用优化。在数据库技术发展的最近20多年里，国外的商用数据库厂商一直是在努力让开发变得更简单，把更多的应用开发需要关注的事情交给数据库来做，开发者只需要写好SQL语句就行了。互联网企业带来了一波逆潮流，他们认为解构复杂的应用，用微服务、中台技术等将复杂的应用拆解开来，让数据库回归本源，只是负责数据的存储与读取，让更多的业务逻辑回归到应用系统中。这种应用是互联网应用本身的高并发需求下产生的，十分适合互联网应用的单元化程度比较高的超高并发系统。第五，数据库参数的优化。实际上对于Oracle这样的商用数据库系统，数据库参数优化是应该摆在更重要，更早期的位置上的。数据库参数优化好了，数据库系统就不会有大的问题了。而对于我们的国产数据库，通过数据库参数的优化，将数据库适应于某种应用场景，恐怕效果最好的是针对BENCHMARK测试的场景，除此之外，数据库原厂拥有的经验也很少。而企业应用与BENCHMARK测试场景类似的场景极少，所以这些参数设置模板对于实际生产环境来说帮助不大。通过数据库参数优化来优化国产数据库，还需要经过大量的实际应用场景磨合，才能够总结出一些有用的经验。因此这个优化反而目前做起来比较费劲了。从上面的讨论中，可能已经有朋友看出来了，SQL和应用优化才是国产数据库的重头戏。在一些数据库国产化迁移的项目中，我们实际上已经验证了这一点。实际上这一点从这个数据库响应时间分析模型图上，也能够看得很清楚。上面这张图是我和朋友讨论性能优化时常用的图，横轴是每个毫秒的交易数量，纵轴是响应时间。从这张图上我们可以看到很多与性能优化相关的概念。首先响应时间是由QUEUE TIME和SERVICE TIME组成。SERVICE TIME是数据库真正地在RDBMS侧执行SQL的时间，而QUEUE TIME是各种数据库、网络、CPU调度等的等待时间。要降低QUEUE TIME时间，则要从操作系统、网络、数据库配置等方面去做调整与优化。这个我们一般称为系统级优化。要降低SERVICE TIME，那么就要从应用的角度入手，去优化SQL，优化应用软件。而应用优化好了，反过来会影响QUEUE TIME，降低数据库等层面的资源争用也会带来QUEUE TIME的减少。因此在一个数据库系统中，如果QUEUE TIME优化比较费劲了，那么从SERVICE TIME上入手也是可以的。这张图上还有一个大家容易忽视的点就是拐点，并发事务数与响应时间之间的关系接近于一个二次曲线，而这个曲线上存在一个拐点，当Arrival Rate超过这个拐点的时候，响应时间的增长会急剧上升，而在此之前，这个增长基本上是线性的。因此优化的还有一个要务就是尽可能让这个拐点出现得晚一些。要实现这个任务，也可以从系统级和应用级两方面入手。目前因为数据库厂商给我们提供的系统级优化的手段还十分有限，因此在做系统优化的时候，面对国产数据库，我们首先还是会从SQL与SQL的执行计划入手，一般来说也会取得不错的效果。不过这种从SQL或者应用入手的模式工作量较大，随着应用的不断变化，以及数据库中的数据量的变化，优化工作必须持续进行，否则很难保持持久。因此我们也需要国产数据库厂商提供更多的系统级分析与优化的手段，提供更多的数据库参数优化调整的经验模板，让优化工作的两条腿都能够走起来，而不能一瘸一拐。最近我们在OpenGauss 5.0发布的一些信息上看到了一些不错的东西。比如说gstack、DBMind等。DBMind是openGauss的一个开源数据库自动驾驶平台，它可以为openGauss数据库提供自动化的运维能力，包括异常检测、参数调优、索引推荐、慢SQL分析等功能。DBMind支持多种运行模式和对接模式，可以很容易地与现有的管理系统进行集成。
openGauss 3.0发布的时候，团队介绍了一个性能优化的案例。当时我就认为要想完成这种分析，必须对数据库、操作系统等都有十分强的分析能力才行，如果数据库必须依靠这种高级技能才能做优化分析，那么普通的用户是无法掌握的。在数据库技术发展到今天，DBMind这样的工具多一些才能让用户用得更轻松一些。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub-/70027826/viewspace-2949803/，如需转载，请注明出处，否则将追究法律责任。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
最近发表
推荐文章
热评文章
暂时没有评论，来抢沙发吧~