[1] 記事本的開啟方式是一次讀入,小檔尚可大檔肯定掛,加上其設計本來就沒針對大檔案讀取作特殊處理,所以久是正常的,更何況你的檔案大小甚至有超過100MB;UltraEdit則是只讀取片段,捲頁時再讀取,你所翻捲到的頁面,一定比較快。
有機會自己寫個小程式嗎?
每個檔案只擷取前面一小段,例如100MB取100KB,我想你的文字檔格式應該也是一段一段重複性,看前面一小部份,後面的格式也是相同的;如果我的假設成立,這樣做會不會讓你的分析工作快些?
[2] 我不知道你的資料經過整理後,是要以什麼方式呈現,查詢/歸納/整理方式為何?
從你的字裡行間似乎是做新聞檢索?類似Google打Keyword後,列出你所要的各條新聞(內容/時間/出處...)?
方法與習慣不好該改就是得改;筷子都不會拿了,怎麼夾豆腐?
如果我沒猜錯你的需求,就算轉成MSDE/MSSQL,
HDD I/O效能還是會拖效能,更何況你老闆是拿隨身碟去access。
[3] 請查詢 "Primary Key" 以及 "Indexes" ,這兩者加了之後,對 Insert/Update/Delete 沒有幫助,但對 Query 幫助非常大請適當加上(多或少都不好)。
只是恐怕你的資料量...MSSQL也撐不住...
或許規劃DB+分散式的架構會比較適合你。
引用:
作者lobben
謝謝您的建議與指教
歹勢我沒說清楚,我是要處理新聞文章,十年分的文件大概6G
其中兩年的文件轉換成資料庫後,資料筆數分別是八百萬和一千兩百萬筆
1.,文件檔大概有幾百個,每個都幾十MB~112MB,如果用程式讀取文字檔是沒問題的,一次讀一點就好
而我所謂的"開啟"是用筆記本,效率很差...後來發現用ultraedit開比較快
之所以要開啟文件檔,是因為要看文件格式長怎麼樣以便剖析,才知道怎麼寫轉換程式
2.3.4 這幾天會著手轉換資料庫工作
5.如我前面所說,環境的問題和我老闆個人的習慣問題,所以才會有這種弔詭的做法
至於index的問題
在做資料轉換時,就把某個文字出現在哪一年哪一篇文章的哪一句
所有出現過的資訊都記錄下來
然後另外開個資料庫存放index table
而比數只會增加不會減少,user只會改資料的屬性不會刪除
剛開始效果還不錯,但筆數大概超過600萬筆時就變慢...
|