SQL搜索緩存 - 高可擴展性

Question

我開發了一個網站，提供非常通用的數據存儲。目前它工作得很好，但我正在考慮優化速度。

對於不同情況，INSERT/SELECT比率很難預測和更改，但通常SELECT更常見。 INSERT足夠快。選擇是我擔心的。有很多LEFT JOIN。例如。每個對象都可以有一個存儲在單獨表格中的圖像（因爲它可以跨越多個對象）並存儲關於圖像的附加信息。

每次選擇最多可進行8次連接，處理時間最長可達1秒 - 平均值大約爲0.3秒。對於每個請求可以有多個這樣的選擇。它已經在SQL方面進行了多次優化，並且沒有太多可以在那裏完成的事情。

除了爲DB購買功能更強大的機器，還能做什麼（如果有的話）？

Django在這裏並不是速度惡魔，但我們仍然有一些優化在那裏。如果我們必須切換到PyPy。在數據庫方面，我有一些想法，但他們似乎並不常見 - 找不到任何真實的案例。

• 對此部件使用不同的存儲，速度更快。我們需要交易，我們需要一致性檢查，因此可能不是最好的。
• 可搜索的緩存？這有什麼意義嗎？例如。維護NoSQL中的所有表的平面副本或其他內容。插入將會更加昂貴 - 如果某些公用表更改，它需要更新NoSQL中的多個記錄。難以維護。

有沒有什麼有意義的東西，或者它只是最快的，可以獲得更多的RAM，增加rdbms中的緩存大小，獲取SSD並離開它。專注於優化其他部分，如彙集數據庫連接，因爲它們也很昂貴。

使用的技術：PostgreSQL 9.1和Django（python）。

總結。問題是：在優化所有SQL部分索引，集羣等之後，如果靜態超時高速緩存結果不是一個選項（不同的請求參數，不同的結果），可以做些什麼來進一步優化。

--- 編輯 30-08-2012 ---

我們已經使用檢查慢速查詢每天的基礎上。這是我們的瓶頸。我們只對索引進行排序和過濾。另外，抱歉不清楚這一點 - 我們不會將實際圖像存儲在數據庫中。只需文件路徑。

JOINs和ORDER BY在這裏殺了我們的表現。例如。一個吐出20000個結果的複雜查詢需要1800ms（使用EXPLAIN ANALYSE）。這假定我們沒有使用任何基於JOINed表的過濾。

如果我們跳過所有連接，我們會縮短到110ms。這是瘋狂的......這就是爲什麼我們想到某種可搜索的緩存或平面副本NoSQL。

沒有排序，我們得到了60ms，這很棒，但是PostgreSQL的JOIN性能如何？ 是否有一些不同的數據庫可以爲我們做得更好？最好是免費的。

Answer 1

首先，雖然我認爲有時間和地點將圖像文件存儲在數據庫中，但一般情況下，您將擁有與此類操作相關的額外I/O和內存。如果我正在考慮優化它，我會把每個圖像放在一個路徑中，並且能夠將這些圖像批量保存到fs中。這樣他們仍然在你的分貝用於備份目的，但你可以拉出相對路徑並生成鏈接，從而節省你一堆的SQL查詢，並減少開銷。在基於網絡的後端上，無論如何，在生成HTML和檢索圖像之間，您將無法真正實現事務處理，因爲這些事務在不同的HTTP請求下進行。

至於速度，我不能告訴你是否在查看總的http請求時間或db時間。但你需要做的第一件事是將所有事情分開，並尋找你的大部分時間都花在哪裏。這可能讓你感到驚訝。接下來的事情是讓那些慢速查詢查詢的查詢計劃：

http://heatware.net/databases/how-to-find-log-slow-queries-postgresql/

從那裏

然後，開始使用講解分析，找出是什麼問題。

同樣在決定升級硬件時，您希望知道當前正面臨的限制。更多的RAM通常會幫助你（如果你的db可以很好地適應RAM）是非常有用的，但除此之外，將更快的存儲放入cpu綁定服務器或切換到具有更快cpu的服務器在I/O綁定中是沒有意義的服務器。頂部是你的朋友。同樣地，根據併發性問題，它可能（或可能不會）！爲您的select語句使用熱備用。

但是，沒有更多的信息，我不能告訴你什麼是進一步優化你的數據庫的最佳途徑是。 PostgreSQL能夠在正確的條件下運行速度非常快，並且可以很好地擴展。