解DBA之惑:数据库承载能力评估及优化手段(3)
到了这个层面,问题往往已经比较严重了.一般情况下,数据库的初始配置都是基于其上面运行系统的负载类型进行专门配置的.如果运行一段时间后,出现性能问题,经评估是属于全局性问题的,可以考虑进行数据库级别的调整.但是这种配置往往代价也比较大,例如需要专门的停机窗口操作等.而且这种操作的风险性也比较大,有可能会带来很多不确定因素,因此要慎而又慎. 5.?层次-数据库架构级如性能核心问题,无法在上述层面解决,可能就需要调整数据库架构.常见的例如采取读写分离的访问方式、分库分表存储方式等.这种对应用的侵入性很强了,有些情况下甚至不亚于重构整个系统. 例如,随着业务的发展,系统的数据量或访问量超出了预期,通过单一数据库无法满足空间或性能要求.此时,可能就需要考虑采用一种分库分表策略,来满足这部分的需求.但其改造难度,往往比重新开发一套系统还要大. 比如,我们可能需要一个数据中间层,来屏蔽后面的分库分表细节.这个中间层可能需要完成语句解析、访问路由、数据聚合、事务处理等一系列功能.即使使用了中间层产品,对于应用来说,数据库的功能也会相对“弱化”,应用级代码不得不进行很多的调整来适应这种变化.此外,如何把一个线上正在运行的系统,顺利平稳地迁移到新的结构下,这无疑又是一个给飞驰的跑车换轮胎的问题等等. 如果项目在运行中,出现了数据库架构级的调整,很有可能说明在前期项目设计规划阶段出现了失误,或者对项目的业务预期出现了偏差.因此,这两点一定在初始阶段进行充分的评估,并在设计上保留有充分的“弹性”. 6.?层次-应用架构级有些情况下,单纯依靠数据库是无法解决的,需要综合考虑整个应用架构.在整个系统架构中,数据库往往处于系统的最末端,其扩展性是最差的.因此,在应用架构设计初期,就应该本着尽量不要对数据库产生压力的原则进行设计.或者即使有大的压力,系统可以采取自动降级等方式保证数据库的平稳运行. 常见的例如增加缓存、通过MQ实现削峰填谷等.通过增加缓存,可以大幅度减少对数据库的访问压力,提高整体系统的吞吐能力.引入MQ,则可以将对数据库的压力以“稳态”的形式,向数据库持续施压,而不至于被某个异常高峰压死. 7.?层次-业务架构级最后一种情况是从业务角度进行一些调整.这往往是一种妥协,通过做适当的减法保证系统的整体运行.甚至不排除牺牲一部分用户体验等方式,来满足大部分用户的可用性.这就需要我们的架构师对系统能提供的能力要很清楚,对业务也要有充分的了解.对于承载什么样的业务,及为了承载业务所需要花费的代价成本有充分的认知,才可以做出一些取舍. 这里要避免一些误区,认为技术是“万能”的.技术可以解决一定的问题,但不能解决所有问题,或者解决所有问题的成本代价是难以接受的.这个时候,从业务角度稍作调整,就可以达到“退一步海阔天空”的结果. 文章出处:DBAplus社群(订阅号ID:dbaplus) (编辑:ASP站长网) |