数据库编写密集型Web应用程序

Question

TLDR 将PHP应用程序的逻辑移动到与OracleDB交互的C ++守护进程是一种聪明的举动吗？

我为我们公司的一个团队创建了一个简单的应用程序，基本上他们审计所做的事务并标记他们找到的任何错误/不完整。

最初是在具有15个用户的Virtual CentOS上运行PHP Apachemod + MYSQL。 MYSQL多次占用CPU。从那时起，我将其转移到PHP-FPM＆amp;预言。

已优化查询并正确创建索引并在需要时创建索引。

该应用程序同时拥有大约16个用户，每个用户每天要审核约350个交易。写操作几乎每秒一次，每个事务需要在大约4个表中插入。 DB结构目前是一个大型数据库（没有分区，没有缓存）。每天大约有70K个新交易被添加到数据库中，并且到目前为止还有> 1M交易。

用户有时会看到延迟，因为PHP方需要在返回之前完成数据库写入。

我在想这可以通过以下方式改进：

• 转到专用服务器
• 首先优化数据库（分区 - 日志和tmp，每月分区）
• 创建归档结构以移动上一季度的事务和用户操作
• 可能将SQL移动到存储过程？
• 创建查找审核详细信息的C ++守护程序（思考可能是基于文件的事件，即查找文件并正确加载记录） - 然后可以作为PHP库
• PHP利用Gearman将详细信息发送到C ++的输入目录。或者也许使用memcached。

这样一来，PHP前端可以在将详细信息传递给memcached / gearman之后立即返回给用户，我希望它比DB写入更快。

还有哪些其他选择？这会使问题过于复杂吗？是的，团队负责人抱怨超过2秒的延误。 （＆＃34;过早优化是所有邪恶的根源＆＃34;这里不适用）

Answer 1

这听起来像你的应用程序目前是系统写入绑定。

有人可能会问，事务处理是否真的需要同步，或者也可以异步处理（想想消息队列）。

否则，我会看到两条合理的行动路径

1. 将持久层与应用层分开，即：在具有更好写入吞吐量的专用计算机上托管数据库。
2. 查看您的应用程序的实际持久性架构，4次写入听起来像是你正在进行非常昂贵的写入。

关于C ++和存储过程我不会看到高回报的可能性，因为看起来问题比硬件边界或业务规则更接近于使用的技术。