快速複製大型數據庫表的方法

我們正在嘗試解決性能問題。搜索數據並以分頁方式顯示的時間大約需要2-3分鐘。快速複製大型數據庫表的方法

經過進一步調查（並在幾次sql調優之後），似乎由於數據量很大，搜索速度很慢。

我目前正在研究的一種可能的解決方案是將數據複製到可搜索的緩存中。現在這個緩存可以在數據庫中（例如物化視圖），也可以在數據庫之外（nosql方法）。但是，由於我希望緩存水平擴展，我傾向於將其緩存到數據庫之外。

我創建了一個概念證明，事實上，在我的緩存中搜索速度比在db中快。但是，初始完整複製需要很長時間才能完成。雖然完全複製只會發生一次，然後成功複製只會增加自上次複製以來發生更改的複製，但如果我可以加速初始完全複製，它仍然很棒。

但是，在完全複製期間，除了查詢執行的緩慢之外，我還必須對抗網絡延遲。事實上，我可以處理緩慢的查詢執行時間。但網絡延遲實際上確實降低了複製速度。

那麼，這導致我的問題，我怎麼能加快我的複製？我應該產生幾個線程，每一個做一個查詢？我應該使用可滾動嗎？

來源

2010-07-15 Franz See

這是實時數據，還是事後報告？您可能想嘗試查看nosql解決方案是否適用於此特定查詢（s） – 2010-07-15 14:26:24

是的。我將在nosql存儲中複製我們的RDBM（或其一些表）。 – 2010-07-16 06:37:11

SELECT * FROM YOUR_TABLE
地圖結果轉換成一個對象或數據結構
指定爲每個對象或數據結構
加載密鑰和對象或數據結構的唯一鑰匙插入WeakHashMap中充當您的緩存。

我不明白你爲什麼需要排序，因爲你的緩存應該通過O（1）時間的唯一鍵訪問值。什麼是排序購買你？

一定要考慮線程安全性。

我假設這是一個只讀緩存，並且這樣做是爲了避免不斷的網絡延遲。我還假設你在啓動時會這樣做。

每條記錄有多少數據？每條記錄1KB的12M記錄意味着您需要12GB的RAM才能保存您的緩存。

來源

2010-07-15 00:19:58 duffymo

是不是12M記錄真的沒有那麼多的DBMS？我的意思是索引和其他技巧... – hvgotcodes 2010-07-15 00:26:18

我只提到了關於sql分頁和排序，以指出爲什麼我打算將它複製到我們的數據庫之外並進入緩存。對困惑感到抱歉。另外，'select * from your_table'方法太慢了。我希望能夠加速它的發展（而不是等待幾個小時才能完成）。 – 2010-07-15 00:27:36

實際上，問題出在你何時加入其他表格並對分頁進行排序。我們的DBA已經優化了可以優化的所有內容，但是要分類的數據量（分頁）太大，每個查詢仍需要2到3分鐘。 – 2010-07-15 00:30:05

複製高速緩存中的數據看起來像複製數據庫的功能。

從閱讀其他評論，我看到你沒有這樣做，以避免網絡往返，但由於昂貴的加入。在許多DBMS，您可以創建臨時表 - 這樣的：

CREATE TEMPORARY TABLE abTable AS SELECT * FROM a , b ;

如果a和b是大（相對固定的）表，那麼你將有2-3分鐘的一次性成本，創建臨時表。但是，如果你使用abTable許多查詢，則隨後的每次查詢費用會比

SELECT name, city, ... , FROM a , b ;

其它數據庫系統更小的有，它可以讓你做這樣的事情

CREATE VIEW abView AS SELECT * FROM a , b ;

更改視圖概念在底層的a和b表中會反映出abView。

如果您真的關心網絡往返，那麼您可能能夠在本地計算機上覆制部分數據庫。

一個好的數據庫管理系統應該能夠處理你的數據需求。那麼爲什麼要重新發明輪子？

來源

2010-07-15 01:13:35 emory

再次請諒解。我不是在重新創建緩存解決方案或搜索解決方案。我只需要從數據庫中讀取數據（足夠快），並將它們存儲在我正在使用的緩存中，並使用我的搜索解決方案將它們編入索引。另外，儘管我可以在數據庫中進行緩存，但最好不管我使用的緩存是水平可伸縮的（這就是爲什麼我試圖避免RDBM進行緩存的原因）。 – 2010-07-15 01:20:31

此外，如果我沒有弄錯，VIEW（與Materialized VIEW不同）就像查詢的快捷方式，意味着與視圖相關的查詢仍將被執行。當然，由於內存中的緩存和更少的磁盤空間，它可能會更快，但我認爲我們不能依靠它來獲得一致的快速查詢。 – 2010-07-15 01:21:43

快速複製大型數據庫表的方法

回答

相關問題