為什麼要用IPFS儲存大量資料？IPFS最吸引人的特點是什麼？哪些地方是大家擔心的？在IPFS的官方論壇針對人們為什麼使用或不使用IPFS來儲存大量資料的原因做了一個調查。
針對於這些有大量資料處理需求的使用者來說，IPFS吸引他們的關鍵因素以及他們的憂慮是什麼？
一、在大量(多達10TB)二進位制檔案透過非常耗時的模擬產生。因此恰當地儲存這些檔案非常重要(一旦丟失檔案，意味著得重新模擬，耗時長達幾個月)。把檔案分享給同事也很重要，不幸的是，在實際操作中這很難實現。比如說，我在歐洲工作，就無法下載儲存在斯坦福資料庫幾TB的模擬資料集，要花很長的時間才能辦到。
二、就目前瞭解到的IPFS相關資訊來說，重點是能透過聯絡到網路中離你最近的人，從而提高檔案分享速度，而不再是基於一箇中央儲存庫。但同時也瞭解到這樣就不能再複製了，網路中的每個節點只儲存它“感興趣”的內容。
三、大多數公司把大型工作負載儲存在 EMC Isilon 或 Netapp，我的工作是儲存銷售這塊，幾乎所有的顧客都想把大量的工作檔案儲存在 AMS (亞馬遜旗下雲端計算服務平臺)或 Azure(微軟雲端計算服務平臺) – 這總是比較容易實現。因此，檔案儲存用例會是一個有趣的切入點，尤其是在資料生成量達到PB級的行業，比如媒體或研究領域。
四、我在一家網路使用者行為研究公司工作，類似於谷歌分析(Google Analysis)。跟蹤程式碼每天產生幾TB的資料，我們把資料儲存在 AWS S3，設定有效期限，把總量控制在幾百TB內。我們正在尋求減少資料重複的方法，以節約成本。每天有數百萬個時域(session)，一旦配置js-ipfs後，意味著整個網路上會有數百萬個ipfs節點(短期的，幾秒到幾十分鐘)。我相信這能釋放IPFS的最大潛力。
五、當使用者訪問一個站點時，我們監看和記錄網頁產生的所有DOM更改，儲存 session，便於之後用於分析。目前我們需要這些東西：
1. 版本控制(version control)或IPFS白皮書6.3中提到的樹物件(The Tree Object)。現在我們用的是一種差異演算法來計算DOM更改，把原始資料和差異都存入文件。如果IPFS的樹物件能實現，我們就能減少很多重複內容，節約大量空間。
2. 可靠的push (或上傳) 方法。我用 PubSub(釋出/訂閱模式)演示過，似乎還無法保證內容接收。因為標籤可能隨時關閉，我們需要在微秒之內將資料push到後臺。
六、我的理解是，它允許我們在一個地點隨機且可根據需求更改的廣義系統中，可以把一切事物都看做節點、服務和工作者 — 比如，它可以讓你模糊服務端和客戶端之間的區別。取代了強制將服務端和客戶端進行二分的方式，讓你可以在一臺接近資料的裝置或一臺距離很遠的裝置上進行分析，或者將資料複製到一個新的地點進行分析。某種程度上這樣簡化了你的程式碼基，因為你可以少編寫一些能讓客戶端應用、工作者重複利用的庫和服務，無論他們身在何處。
