适用范围:客户正在运行一个基于web的金融应用程序,其主要功能包括大量的进出金融交易。这些过程是自动化的。我们在午夜运行几个cron作业任务,以便为适当的客户分配付款。每月平均我们有2000到3000个新客户,目前共有30000个客户。到目前为止,我们的事务表有近90万条记录,预计未来几个月将大幅增加。
技术:最初我们使用lamp环境,使用codeignator框架,使用laraveleleqontorm进行查询,使用mysql。托管:托管在aws中,t2小示例,没有负载均衡器实现**这个应用程序是三年前开发的。
问题:目前我们的客户在高峰时间面临停机,他们的客户在查看事务档案和统计数据时也面临加载时间问题。他们还担心,如果cron任务失败,他们将无法处理该任务(进行了大量计算,并插入了大量客户)。
我们的计划:所以现在,我们计划从零开始重新开发应用程序,将性能和容错作为我们的主要目标。而且这种应用至少还要可靠6到8年。
技术:node(sails.js)、angular5、带负载均衡器的aws、awsrds(mysql)
我们的方法:从我们的分析中,我们得到了一些直接的性能损失的原因。首先,对于访问重表的客户有许多统计信息。大部分数据都是本月的。因此,我们计划为这些方法添加日志表,并且只在特定的table.addmethod中保留当前月份的数据
所以,可能会有这样的日志表,只会有读取操作。
查询:
将只准备就绪的表拆分为单独的数据库是好的,还是我们可以在单个数据库中使用它。
mysql buffer cache与redis/memcache有何不同?当更多的流量流入时,是否会出现内存消耗问题?
在每个月底截断几个表的最佳方法是什么(正如我提到的日志文件)?
我前进的方向对吗?
1条答案
按热度按时间tuwxkamq1#
一百万行是一个适度的大小,而不是“巨大的”。既然您遇到了性能问题,我不得不相信它是由糟糕的索引和/或糟糕的查询公式造成的。
找出哪些查询最麻烦。有关使用mysqldumpslow-st或pt查询摘要查找它们的建议,请参阅本文。
提供
SHOW CREATE TABLE
以及EXPLAIN SELECT ...
讨论如何改进。它可以简单地添加一个“综合”指数。另一个可能的性能瓶颈可能是重复汇总旧数据。如果是这种情况,那么请考虑构建和维护摘要表的数据仓库技术。
至于你的4个问题,我暂时对每一个都说“不”。
各种各样的框架倾向于使小型应用程序易于开发,但是当您进行扩展时,它们开始给您带来麻烦。尽管如此,仍然有一些东西可以在不放弃框架的情况下修复。
aws等,给你很多的可靠性和可读性。但是,我重复一遍,可能要看的地方是缓慢的查询,而不是你提出的各种想法。
至于周期性截断,在了解了数据的外观以及数据保留的业务需求之后,让我们来讨论一下。