SQL連接生存期

Question

我正在研究一個API來查詢數據庫服務器（在我的情況下是Oracle）來檢索大量的數據。 （這實際上是一個位於JDBC之上的圖層。）

我創建的API試圖儘可能限制將每個查詢信息加載到內存中。我的意思是我更喜歡迭代結果集並逐個處理返回的行，而不是在內存中加載每行並稍後處理它們。

但我想知道如果這是最好的做法，因爲它有一些問題：

• 在整個處理過程中的結果集保存，如果處理是，只要檢索數據，這意味着我的結果集將打開兩倍長
• 在我的處理循環中執行另一個查詢意味着在我已經使用另一個結果集的同時打開另一個結果集，但同時開始打開太多結果集可能不是一個好主意。

另一方面，它具有一定的優勢：

• 我從來沒有在內存中的數據結果集的多個行，因爲我的查詢往往返回100k左右的行，它可能值得。
• 由於我的框架主要基於函數式編程概念，所以我從不依賴同時存在於內存中的多行。
• 在數據庫引擎仍然返回其他行時返回的第一行開始處理是一個很好的性能提升。

在回答甘道夫，我添加了一些更多的信息：

• 我總是要處理整個結果集
• 我沒有做的任何行的聚集

我正在與主數據管理應用程序集成並檢索數據以驗證它們或使用多種不同格式（到ERP，到Web平臺等）導出它們。

Answer 1

沒有普遍的答案。我親自實施了兩次解決方案。

這取決於什麼對你更重要：內存或網絡流量。

如果您的網絡連接速度很快（LAN），而且客戶端機器較差，請從服務器中逐行讀取數據。

如果你在Internet上工作，那麼批量獲取將幫助你。

您可以設置預取計數或數據庫圖層屬性並找到一箇中值。

憑經驗是：獲取的一切，你可以保持不知不覺

，如果您需要更詳細的分析，也有涉及六個因素：

• 排輩性反應的時間/速度（多快Oracle生成第一行/最後一行）
• 行傳遞響應時間/速率（多久可以得到f IRST行/最後一行）
• 行處理響應時間/速度（你們多久纔可以顯示第一行/最後一行）

他們中的一個將成爲瓶頸。

通常，rate和responce time是拮抗劑。

隨着預取，你可以控制行交付響應時間和行分娩率：高預取數將增加速度，但縮短響應時間，降低預取數卻反其道而行之。

選擇哪一個對您更重要。

您還可以執行以下操作：爲獲取和處理創建單獨的線程。

只需選擇多行以保持用戶在低預取模式（高響應時間）下的樂趣，然後切換到高預取模式。

它將獲取背景中的行，並且您可以在後臺處理它們，同時用戶瀏覽第一行。