是否有最適合分佈式遊戲樹遍歷的文件系統？

Question

我一直在尋找關於分佈式遊戲樹遍歷的this paper，並且（在別人的幫助下）試圖製作軟件樹遍歷器的Python/mpi4py克隆，以便解決2個玩家抽象策略遊戲。

首先，Wikipedia provides a breif description關於如何「解決」一個遊戲。

這是一個常見的優化，記住已經解決的結果，因此不需要進一步的樹遍歷。由於一羣計算機不能平均分享彼此的結果，因此採取了各種方法來解決這個問題。在紙張上的方法（轉換表驅動的工作調度）的工作原理基本上如下：

1. 給出一個ID給每個計算機1到n（I只是使用的標準MPI等級）
2. 在任何特定點的計算機可能會收到一個職位。檢查該位置是否在查找表中或平凡完成。如果是，則發送結果值，否則，生成子項。
3. 哈希每個孩子的位置，使他們有1到n的關聯值。使用散列的ID將每個位置發送到「正確的」計算機。
4. 重複，直到初始位置解決。

正如文件甚至提到，這種方法有點矛盾地工作，具有令人難以置信的高通信速率。

這裏有問題：

在它似乎很好地工作在一臺計算機。然後我在我的學校集羣上進行了一些測試，並遇到了一些嚴重的問題。解決像TicTacToe這樣的遊戲通常會在「調試模式」（4個節點，20個核心和15分鐘的時間限制）中超時。

我將TicTacToe解決方案數據庫保存到他們所稱的「用戶目錄」（更多可以是found here）。這與通常用於存儲數據的「scratch」目錄形成對比。當我這樣做時，TicTacToe的數據庫在幾秒鐘內解決了。

我注意到，「從零開始」的空間使用"Lustre FS"這似乎是對「對等網絡」的應用一個糟糕的選擇：

儘管Lustre文件系統可以在許多工作環境中正常運行，它 不一定是所有應用程序的最佳選擇。最好是 適用於超出單個服務器可提供的容量的使用，儘管在某些使用情況下，Lustre文件系統可通過單一服務器比其他文件系統更好地執行 ，這是由於其強大的鎖定和數據一致性而導致的 強大的 。

光澤文件系統當前不特別適合於 「對等網絡」，其中客戶端和服務器上 運行相同的節點的使用模式中，每個共享的存儲量小，由於缺乏 在Lustre軟件級別進行數據複製。在這種使用中，如果一個客戶端/服務器發生故障，那麼存儲在該節點上的數據將不會是 ，直到該節點重新啓動。

我可能對分佈式計算沒有足夠的把握，但似乎Lustre FS可能不會客觀地適合這類問題。不幸的是，我使用的羣集鎖定在使用Lustre FS。另一種選擇是像谷歌雲引擎或AWS做的任務，但我很困惑的一些問題：

1. 很多抽象似乎嚇倒我。所有這些雲平臺都提供「可擴展解決方案」，通常涉及「負載均衡」，這不僅是不必要的，而且對算法不利。 （這是必要的位置被髮送到正確的電腦，以便他們可以快速查找）。 Google雲引擎或AWS是否提供足夠的基本骨架來使此算法有效地工作？
2. 我應該使用什麼文件系統？ Google雲端引擎推薦使用NFS或Gluster，但我不確定。這篇論文相當過時，似乎沒有使用任何特別的東西。 AWS或Google Cloud Engine是否爲這類任務提供適當的文件系統？

Answer 1

沒有任何代碼也沒有描述文件系統是如何使用的，所以很難提供一些有價值的幫助。 無論如何，如果我的行之間，讀

• 你建立一個解決方案
• 這個「數據庫」在文件系統上
• 添加條目的基礎上實現的「數據庫」是一個文件創建
• 查找是一個文件存在檢查

我知道了嗎？

如果是，那麼這不是一個驚喜表現是可怕的，沒有規模。 你基本上在問一個並行文件系統它最糟糕的地方：從所有節點訪問大量元數據，這涉及引擎蓋下的流量以保持文件系統的一致視圖。

需要多少數據來存儲解決方案？乍一看，將它們存儲在舊學校數據庫（例如MySQL）中可能會更快一些。

另一種選擇是將其存儲在本地文件系統中，並讓遠程節點向存儲數據的任務發出查詢（創建該文件，該文件是否存在），因此不需要保留跨節點的元數據保持一致。

更好的版本將是讓所有節點存儲解答和答覆查詢。您可以散列解決方案並推斷其存儲在哪個節點上，以便知道應該要求哪些MPI任務存儲解決方案或發出查詢。

如果您確實需要使用文件系統，那麼NFS可能是比光驅，glusterfs或gpfs等並行文件系統更好的選擇。