將大型python對象存儲在RAM中以備后用

Question

是否可以將RAM（或C ++）數據存儲在RAM中以備后用，如何實現？

背景：我編寫了一個程序來查找輸入表中的哪些行與給定的正則表達式匹配。 我可以在大約一秒鍾或更短的時間內找到所有的行。 但是問題是，每次啟動此程序時，我都會將輸入表處理為python對象。 此過程大約需要30分鍾。

該程序最終將在具有超過128GB RAM的計算機上運行。 python對象大約需要2GB的RAM。 輸入表很少更改，因此python對象（我​​當前每次都在重新計算）實際上很少更改。 有沒有一種方法可以一次創建此python對象，將其存儲在RAM 24/7中（如果輸入表更改或服務器重啟，則重新創建），然后在需要時每次使用它？

注意：創建后將不會修改python對象。 但是，如果需要，我需要能夠重新創建該對象。

編輯：我能想到的唯一解決方案就是保持程序24/7（作為守護程序運行），然后根據需要向其發出命令。

Answer 1

您可以嘗試對對象進行腌制並將其保存到文件中，這樣，每次程序運行時，都必須對對象進行反序列化，而不必重新計算。 希望服務器的磁盤緩存將在必要時使文件保持高溫。

Answer 2

要將任何內容存儲在RAM中，您需要一個正在運行的進程。 因此，最簡單的解決方案是實現您在編輯中編寫的內容。 您還可以創建一個始終運行的新進程，並使舊進程連接到新進程以獲取數據。 如何連接取決於您。 您可以使用共享內存或TCP / IP套接字。 TCP / IP的優點是可以通過網絡訪問數據，但請確保數據安全。

- 編輯 -

大多數操作系統還允許您將RAM作為驅動器安裝。 RAM驅動器 。 您可以將對象寫入（如尼爾建議的那樣）。

Answer 3

我們定期加載和存儲比2 Gb大得多的內存塊，而無需花費任何時間（秒）。 我們可以從3年的SAN中獲得350 Mb / s的速度。

瓶頸/開銷似乎主要涉及python對象管理。 我發現使用元帥比cPickle快得多。 與使用涉及最少的python對象句柄的數據結構相關聯，這已經足夠快。

對於數據結構，可以使用array.array或numpy 。 array.array更具可移植性（不涉及額外的庫），但是numpy在許多方面都更加方便。 例如，您將創建一個具有1000萬個元素的array.array('i') ，而不是擁有1000萬個整數（python對象）。

使用元數據的最好之處在於，它是一種非常簡單的格式，您可以使用c / c ++代碼輕松地對其進行寫入和讀取。

Answer 4

您的問題描述有點含糊，可以用幾種不同的方式閱讀。

我讀到的一種方式是，磁盤上具有某種ASCII表示的數據結構。 您將此表示形式讀入內存，然后一次或多次grep查找與給定正則表達式匹配的內容。

加快速度取決於很多相關的數據結構。

如果您只是在進行行拆分，那么也許您應該只使用一條讀取指令將整個內容讀取到一個字節數組中。 然后，您可以更改grep的方式以使用不跨越多行的字節數組grep。 如果您通過放置^.*?來修飾表達式以始終匹配整行^.*? 在開始時使用.*?$ ，然后在末尾使用.*?$ （ ?強制執行最小而不是最大的修改），然后您可以檢查匹配表達式的大小，以找出要前進的字節數。

或者，您可以嘗試使用mmap模塊來實現類似的目的，而不必閱讀任何內容並招致復制開銷。

如果要進行大量處理來創建數據結構，並且您無法想到以一種非常原始的方式使用文件中的數據作為簡單字節數組的方法，那么您將獲得各種其他解決方案取決於，盡管這聽起來像是創建守護程序是最佳選擇。

由於您的基本操作似乎是“告訴我哪些表條目與正則表達式匹配”，因此您可以使用xmlrpc.server和xmlrpc.client庫簡單地包裝一個將正則表達式作為字符串並返回結果的調用形式是自然的。 該庫將負責將所有看起來像函數調用的事情包裝到套接字或其他任何消息上的工作。

現在，您實際上將其保留在內存中的想法有點麻煩。 我認為這些天從磁盤讀取2G信息不需要30分鍾。 它最多可能需要5個，可能少於1個。因此，您可能需要查看如何構建數據結構，以查看是否可以對其進行優化。

泡菜和/或元帥會為您提供的是高度優化的代碼，用於以序列化形式構建數據結構。 這將導致數據結構的創建可能受到磁盤讀取速度的限制。 這意味着您要解決的真正問題不是每次都從磁盤上讀取它，而是在自己的地址空間中構建數據結構。

將其保存在內存中並使用守護程序並不能保證它會保留在內存中。 它只是保證它在Python進程的地址空間內保持為所需的數據結構。 操作系統可以隨時決定將該內存交換到磁盤。

同樣，這意味着專注於從磁盤讀取它的時間可能不是正確的焦點。 相反，應專注於如何在Python進程的地址空間中有效地重新創建（或保留）數據結構。

無論如何，那是我對這個話題的漫長討論。 鑒於您的問題含糊不清，沒有確定的答案，所以我只不過是雜亂無章的可能技術和一些指導性想法。