在內存中爲Django-Python維護一個大字典？

我有一個很大的key-value對轉儲，我需要查找我的django-Python webapp。在內存中爲Django-Python維護一個大字典？

所以，我有以下選項：

商店作爲JSON轉儲，並加載它作爲一個Python字典。
將其存儲在dump.py中，並從中導入字典。
對這個問題使用一些有針對性的系統：[這些真的用於這個用例嗎？ ]
- MEM-緩存
- 任何其他的選擇嗎？

從上面這是正確的方式去？

如何比較memcache和redis？

更新：

我的字典是約5 MB在規模和增長將隨着時間的推移。
使用Redis的/內存緩存增加觸及插座的每次的開銷，所以會dump.py會更好，因爲這將需要時間來加載到內存中，但之後，它將只能做內存查找。
我的字典裏每天都需要進行更新，考慮到dump.py會有任何問題，因爲我們必須重新啓動Django的服務器重裝哪裏，我想這將反映在飛行中Redis的和memcache。
One使用像Redis的系統只有當你有大量的數據，你必須非常頻繁查找，在這種情況下，插座給出了一個開銷的話，我們如何實現優勢呢？

請分享你的經驗！

來源

2012-05-15 Yugal Jindle

依賴。你的瓶頸在哪裏？ –

你需要一個數據庫嗎？ – moooeeeep

如果您擔心插座，您多久會檢查一次鑰匙？ –

對於選擇Memcache或REDIS，它們在低端硬件（例如80,000 req/s for REDIS on C2D Q8300）上每秒能夠處理幾萬個請求。潛伏期遠低於1ms。你的意思是你按20秒的順序做了一些事情，所以表現明智，這是非問題。

如果您選擇dump.py選項，則無需重新啓動Django即可重新加載。你可以讓你自己的簡單reloader：

dump.py：

[ dict code...] 

mtime = 0

djago代碼：

import dump #this does nothing if it's already loaded 
stat = os.stat(dump_filename) 
if(stat.mtime > dump.mtime): 
    reload(dump) 
    dump.mtime = stat.mtime

來源

2012-05-15 09:51:38 vartec

Redis的一部分對此非常有幫助。 reload（）對我來說是已知的，但是我在每個'mtime'之後重新加載它，這需要2秒來加載並掛起頁面請求。所以，我無法每隔2秒就花費2美元的開銷 - 一旦我更新了字典，我寧願重新啓動服務器。反正重新加載不是這裏的問題。 Redis的一部分是！ –

你的意思是「每隔一段時間」？你說過字典每天都會修改，你只能每天重新加載一次。 – vartec

亞..在這裏，時間是1天。很好，我說它可能會在一天半的時間裏更新。但是，並不重要。 Redis的信息很重要 –

Memcached雖然是一款優秀的產品，但在我的書中被Redis所高估。它提供了許多memcached所不具備的功能，如持久性。

它還提供了更復雜的數據結構，如散列。你的特定數據轉儲是什麼？它有多大，以及多大/什麼類型的值？

來源

2012-05-15 06:23:08 sberry

請參閱問題中的更新。 –

在過去，對於類似的問題，我使用了dump.py的想法。我認爲所有其他數據結構都需要一個圖層來將一種對象轉換爲python對象。不過，我仍然認爲這將取決於數據大小和您處理的數據量。Memcache和redis應該有更好的索引，並查找真正的大數據集和基於正則表達式的查詢。所以我的建議是

JSON - 如果你是通過HTTP服務的數據到其他服務 Python文件 - 如果數據結構不是太大，你不需要任何特殊的外觀UPS的

的memcache和redis - 如果數據變得真的很大

來源

2012-05-15 06:23:25 dusual

請參閱問題中的更新。 –

5Mb並不是那麼大。您可以將它保存在內存中，我建議您這樣做，直到從分析和測試中明白，該方法無法滿足您的需求。總是儘可能做最簡單的事情。

套接字通信本身並沒有引入太多開銷。通過使用unix域套接字，您可能可以稍微削減一點。無論如何，如果你沒有保存你的數據，你將不得不談論某種管道。

來源

2012-05-15 09:31:24 Marcin

同意..所以你認爲應該使用redis，如果查找是每個頁面加載5個，每分鐘加載總共100個頁面？ –

@YugalJindle不，我認爲你應該保留你的數據，直到實際分析表明它導致問題。 – Marcin

在內存中爲Django-Python維護一個大字典？

回答

相關問題