數據庫 - 寫密集型Web應用程序

Question

TLDR 將移動PHP應用程序的邏輯來一個C++守護進程與OracleDB的相互作用是一個聰明的舉動？

我爲我們公司的一個團隊創建了一個簡單的應用程序，基本上他們審覈交易並標記他們找到的任何錯誤/不完整性。

最初是在15個用戶的虛擬CentOS上運行的PHP Apachemod + MYSQL。 MYSQL多次佔用CPU。從那以後，我將它移到了oracle-FPM &。

查詢已經過優化，索引正確創建並在需要的地方創建。

該應用程序同時擁有大約16個用戶，每個用戶預計每天審計約350筆交易。寫操作幾乎是每秒鐘，每個事務需要在大約4個表中插入。數據庫結構目前是一個大型數據庫（不分區，不緩存）。每天大約有70K個新事務被添加到數據庫中，並且截至今天，有大於1M的事務。

由於PHP端需要在返回之前完成數據庫寫入，用戶有時會目睹延遲。

我在想，這可以改善由：

• 移動到專用服務器
• 第一優化DB（分區 - 日誌和TMP，每月分區）
• 創建歸檔結構移動之前的季度交易和用戶操作
• 也許將SQL移動到存儲過程？
• 創建C++守護看起來審計信息（思維可能是一個基於文件的事件即查找文件，並適當地加載記錄。） - 可以那麼作爲一個PHP庫
• PHP使用Gearman的送發輸入C++目錄的細節。或者可能使用memcached。

這樣，PHP前端可以在它將詳細信息傳遞給memcached/gearman後立即返回給用戶，我希望這會比數據庫寫入更快。

還有其他的選擇嗎？這是否會讓問題過於複雜？是的，隊長已經抱怨了超過2秒的延遲。 （「過早優化是萬惡之源」不適用於此）

Answer 1

這聽起來像您的應用程序此刻系統寫入綁定。

有人可能會問，事務處理是否真的需要同步或是否可以異步處理（思考消息隊列）。

否則，我見行動

1. 單獨從應用層的持久層，即兩個合理路徑：具有較好的寫入吞吐量主機數據庫專用的機器上。
2. 檢查您的應用程序的實際持久性架構，2s爲四個寫入聲音，就像您正在做的非常昂貴的寫入。

關於C++和存儲過程我沒有看到高回報的潛力，因爲它看起來問題更接近硬件邊界或業務規則而不是使用的技術。