2009-11-04 36 views
6

因此,對於一些研究工作,我需要分析大量的原始運動數據(目前幾乎是一個數據,並增長),並吐出定量信息和圖表。加載和分析大量數據

我使用Groovy編寫了大部分代碼(使用JFreeChart進行製圖),當性能成爲問題時,我重寫了Java中的核心部分。

問題是分析和繪圖需要大約一分鐘,而加載所有數據需要大約5-10分鐘。正如你可以想象的,當我想對繪圖進行小的改變並看到輸出時,這會變得非常煩人。

我對解決這個一對夫婦的想法:

  1. 加載所有的數據到一個SQLite數據庫。優點:它會很快。如果需要的話,我將能夠運行SQL來獲取彙總數據。我不得不寫所有的代碼。另外,對於一些情節,我需要訪問每個數據點,因此加載幾十萬個文件,某些部分可能仍然很慢。

  2. Java RMI返回對象。所有的數據都被加載到一個根對象中,當它被序列化時,大約是200兆。我不確定需要多長時間通過RMI傳輸200meg對象。 (同一客戶)。

    我不得不運行服務器並加載所有的數據,但這不是什麼大不了的事情。

    主要職業:應該採取的時間最少寫

  3. 運行加載數據和服務器VM內執行上命令Groovy腳本的服務器。總體而言,這似乎是最好的辦法(執行時間與性能,以及其他長期利益)

我想知道的是有其他人解決這個問題呢?

後分析(3/29/2011):寫了這個問題幾個月後,我結束了不得不學習R運行一些統計數據。使用R對於數據分析和聚合來說比我所做的要容易得多,速度也更快。

最終,我結束了使用Java運行初步聚合,然後運行其他所有內容在RR製作漂亮的圖表要比使用JFreeChart容易得多。

回答

5

如果您要擁有海量數據,數據庫具有很高的可擴展性。在MS SQL中,我們目前在4分鐘內對大約30GB的數據進行分組/整理/過濾(我認爲大約有1700萬條記錄)。

如果數據不會增長太多,那麼我會嘗試方法#2。您可以製作一個簡單的測試應用程序,用於創建一個帶有隨機數據的200-400mb對象,並在決定是否要轉到該路線之前測試轉移它的性能。

+0

我知道數據庫總體上是最好的選擇,也是最可擴展的,什麼不是。如果我正在寫一個實際的應用程序,這將是沒有問題的。 我認爲你是對的,但如果#2可以用最小的性能打擊來實現(因爲它可以在大約5行代碼中實現),這可能是我最好的選擇。 –

+0

@Rev - 不是「最具擴展性」。像Hadoop這樣的技術更具可擴展性。 –

1

如果您的數據具有關係屬性,沒有比在一些SQL數據庫中存儲它更自然的事了。在那裏你可以解決你最大的問題 - 性能,花費「僅僅」來編寫適當的SQL代碼。

看起來很明顯。

1

我會研究使用R的分析。它是一種具有圖形功能的統計語言。它可以讓你領先,特別是如果那是你打算做的那種分析。爲什麼要寫所有的代碼?

+0

這是一個好主意,但現在或此項目並不完全可行。 雖然我聽說過R,但我不能用一種不同的語言重寫所有的數據分析,同時學習它。 –

+0

回顧大約一年後的一年。當我必須運行一些我無法用Java輕鬆完成的統計數據時,我最終學習了R語言。學過R後,我希望從一開始就使用它。一切,我的意思是一切,世界更容易。 –

-4

啊,是的:Java中的大型數據結構。祝你好運,倖存"death by garbage collection"和所有。 Java看起來最擅長的是將UI包裝在其他處理引擎中,儘管它從大多數內存管理任務中解放了開發人員 - 只是付出了代價。如果是我,我很可能會在Perl中進行繁重的操作(出於性能原因,必須在perl中重新編碼批處理系統中的幾個塊而不是java),然後將結果吐回到您現有的圖形代碼中。

但是,根據您的建議選擇,您可能需要使用SQL DB路由。只要確保它確實對於一些示例查詢更快,查看查詢計劃數據和所有這些(假設您的系統將記錄或交互式顯示此類詳細信息)

編輯,(對Jim Ferrans) -N比perl快(下面的評論):你引用的基準測試主要是小的「算術」循環,而不是幾百MB的IO,並將其存儲在Map /%hash/Dictionary/associative-array中供以後使用再訪。 Java I/O可能會變得更好,但我懷疑所有的抽象性仍然會讓它比較慢,我知道GC是一個殺手。我最近沒有檢查過,我不像現在這樣每天在我目前的工作中處理多GB數據文件。

餵食巨魔(12/21):I measured Perl to be faster than Java for doing a bunch of sequential string processing。事實上,根據我使用的機器,Perl的工作(批次+字符串)這種的速度比Java快3到25倍。當然,我整理的特定測試不涉及任何數字工作,我懷疑Java會做得更好,也不涉及在Map/Hash中緩存大量數據,我懷疑Perl會擁有這些數據。做得好一點。請注意,雖然Java在使用大量線程方面做得更好。

+0

咦? Perl的速度比Java慢30-100倍*,請參閱http://www.coderanch.com/t/201887/Performance/java/Java-vs-Perl-Speed或http://shootout.alioth.debian.org/ U32/perl.php。 –

+0

在Java中有很多IO錯誤需要提交,但是不要做錯誤可以提供很多幫助:http://java.sun.com/developer/technicalArticles/Programming/PerfTuning/ – Carl

+0

-1 - 瀏覽您的博客,並它的主要觀點(沒有可證實的事實)和很多事實上的不準確。例如,沒有現代的JVM使用標記和清理垃圾收集器。我懷疑,Java的很多「糟糕的結果」實際上是由錯誤的做法造成的。但是,當然,沒有具體的例子就沒有辦法知道。 –

0

我會建議運行一個分析器來查看加載過程的哪個部分花費的時間最多,以及是否有可能的快速獲勝優化。您可以下載JProfilerYourKit的評估許可證。

2

在您做出決定之前,您可能需要了解您的JVM以及物理系統資源的情況。

有幾個因素可能是在這裏打球:

  • JVM堆大小
  • 垃圾收集算法
  • 你多少物理內存已經
  • 你如何加載數據 - 是從一個碎片遍佈磁盤的文件?
  • 你甚至需要一次加載所有的數據 - 能不能做到這批處理
  • 如果你正在做這在批次可以改變批量大小,看看會發生什麼
  • ,如果系統有多個核心也許你可以看一次使用多個線程來處理/加載數據如果已經使用多個核心並且磁盤I/O是瓶頸,也許你可以嘗試同時從不同的磁盤加載

如果您不熟悉th,您還應該查看http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp e虛擬機的設置。