2012-08-07 84 views
2

希望這個問題不是太多開放式......簡而言之:我正在尋找一種腳本或編程語言,可以快速但容易地訪問數據庫(PostgreSQL)。快速靈活的語言(PostgreSQL)數據庫訪問?

我想使用PostgreSQL數據庫中的某些表上的查詢結果作爲某些R分析的輸入。查詢是簡單的SELECT請求(請求中可能有改進空間,但目前我沒有這種方式 - 我已經做了一段時間),但在第一個查詢的結果循環內。表格包含數字和字符串,並且如果不是數十萬行,則是數以千計,所以查詢的總數可能非常大。

顯然我首先用RPostgreSQL寫了一個R腳本。但是,使用起來需要很長時間(我希望能夠隨時修改和重新運行)。我已經非常有效地優化了這個腳本,''system.time''顯示我大部分時間都花在循環中的DB查詢上。

然後,我想通了,這將是更快的方式,如果我用一個文本文件作爲輸入R,我決定把這個R腳本翻譯成python,使用psycopg2。不幸的是,python腳本的速度並不比R腳本快得多。

最後我開始用libpq-fe寫一個C++程序,但我停下來,因爲我發現它不夠靈活(我的意思是,我必須將我的代碼的行數乘以至少3或4爲了處理查詢)。因此,我想知道哪種語言(或者其他Rpython庫?)能夠在數據庫訪問(即查詢結果:列表,數組,字符串操作等)方面提供最佳的速度和靈活性之間的妥協,PostgreSQL)。也就是說,它需要比R + RPostgreSQLpython + psycopg2快得多,並且幾乎和「靈活」一樣。

感謝您的建議(語言必須是Linux友好的)。


更新:這裏是僅使用第一500個檢索元件,校正所述N+1問題代碼之後舊與新的代碼的一個典型的定時由Ryan和建議:

> system.time(source("oldcode.R")); 
    user  system  elapsed 
    3.825  0.052  49.363 

> system.time(source("newcode.R")); 
    user  system  elapsed 
    1.920  0.140  3.551 

的1000首次檢索元素相同:

> system.time(source("oldcode.R")); 
    user  system  elapsed 
    9.816  0.092  100.340 

> system.time(source("newcode.R")); 
    user  system  elapsed 
    5.040  0.072  6.695 

確實值得一改。 ;-)

+2

搜索並閱讀「N + 1選擇問題」。 – 2012-08-08 23:33:46

+0

事實上,我似乎陷入了這個陷阱。所以如果我理解正確的話,我應該假定數據庫比我用於分析從數據庫中獲得的數據的編程語言慢得多。也就是說,代替對數據庫的N + 1請求,我應該只執行一個大的請求,轉儲我需要的所有數據,然後在包含所有這些數據的對象上的代碼中循環。 – 2012-08-19 14:49:56

+0

正確。更準確地說,假設數據庫具有較高的*延遲*(相對於您的編程語言而言);這就是爲什麼N 1行查詢比1 N行查詢更昂貴的原因。 – 2012-08-19 18:31:46

回答

2

爲了使數據庫的任何接口走得快;優化您的數據庫查詢。正如你發現即使你使用R的優化代碼,大部分時間都花在db上。所以你應該選擇你最熟悉和熟悉的編程語言;因爲就前端而言,這將是最快的。

然而,無論您使用哪種編程語言,總體結果(就感知性能而言)都是相同的。沒有庫可以提高查詢的速度,因爲這純粹是數據庫的功能。所有庫/語言將允許您將多個查詢合併爲單個事務,但查詢的結果仍依賴於您的數據庫佈局和優化。

簡單的事情,如列上缺少索引可能會產生很大的影響。

通過在您的查詢上運行EXPLAIN ANALYZE開始,並將結果粘貼到this tool中以可視化數據庫正在執行的操作,以便您知道從何處開始優化。

+0

那麼,你假設編程語言和數據庫之間的接口是最優的,並且它們的速度比數據庫速度快得多,以至於在數據庫中花費的時間可以忽略不同語言之間的時間差異。我相信你對第二點的看法,但實際上我問這個問題是因爲我已經閱讀了一些'R'數據庫接口的性能問題,所以第一點可能並非總是如此(但它是一箇舊線程,所以我現在想它已經過時)。 – 2012-08-19 14:39:01

+0

無論如何,感謝您的回覆,您可能是正確的我正在尋找錯誤的方向(正如Ryan所建議的,n + 1問題可能是正確的)。我也不知道'EXPLAIN ANALYSE',儘管我不能用它來處理當前的查詢(因爲它們很簡單,所以我會在後面記住它)。 – 2012-08-19 14:42:39