在我的辦公室,我們有一個傳統會計系統,它將所有數據以純文本文件(TXT擴展名)存儲在固定寬度的記錄中。每個數據文件都被命名爲例如FILESALE.TXT。我的目標是將這些數據帶入我們的MySQL服務器,以供許多其他無法與傳統軟件進行交互的程序進行只讀使用。每個文件基本上都是一個表格。將傳統文本數據庫轉換爲SQL
總共有大約20個文件需要訪問,大約1GB的總數據。每行可能有350-400個字符,並且有30-40列。在拉入數據之後,沒有任何MySQL表大於100MB。
傳統會計系統可以修改文本文件中的任何行,刪除舊行(它具有已刪除的記錄標記 - 0x7F),並隨時添加新行。
這幾年裏,我一直在運行的cron作業每5分鐘即:
- 檢查的最後修改時間每個數據文件。
- 如果文件未被修改,請跳過它。否則:
- 解析數據文件,清理所有問題(只是非常簡單的檢查),並吐出我需要的列(我忽略的某些列)的製表符分隔文件。
截斷表,並導入新的數據到我們的MySQL服務器這樣的:
START TRANSACTION; TRUNCATE legacy_sales; LOAD DATA INFILE '/tmp/filesale.data' INTO TABLE legacy_sales; COMMIT;
這個cron腳本運行的每個文件檢查和並行分析,所以整個更新過程中並沒有真正的需要很長時間。最大的表(不經常更換)需要約30秒才能更新,但大多數表需要不到5秒。
這一直工作正常,但也有一些問題。我猜它與數據庫緩存混淆,所以每次我必須對錶進行TRUNCATE和LOAD時,其他使用MySQL數據庫的程序起初速度很慢。另外,當我切換到並行運行更新時,數據庫可能會處於稍微不一致的狀態幾秒鐘。
這整個過程似乎非常低效!有沒有更好的方法來解決這個問題?有關可能值得研究的優化或程序的任何想法?來自任何面臨類似情況的人的任何巧妙的技巧?
謝謝!
我想補充的一件事是,TRUNCATE在交易中不起作用! – Raolin 2013-04-24 18:53:55