最近有個資源整合的項目，存儲的話選擇了mongodb的sharding來做，因為資料量較大。
原本可能會選擇hadoop來做的，不過從hadoop的文檔上看到好像不太适用大并發的小io的操作（小檔案），更加适用大吞吐量小并發的操作(大檔案)。
應用要求多idc部署，是以資源檔案也要求在多idc存儲(相當于每個idc需要有同樣的資源檔案)。
考慮到擴充性，在一個idc内部使用了mongodb的sharding特性。
但是這樣帶來一個問題，不友善複制到其他的idc，是以目前的做法是應用層在寫入檔案存儲的時候同時調用遠端idc的應用寫入檔案到遠端idc的mongodb sharding。
。這樣做的好處是單個idc的檔案存儲擴充變得比較靈活，不過又帶來一些問題，由于sharding是mongodb來做的，可能不能做到就近存儲（比如存進去的資源，需要讀取這個資源的應用和存儲的位置應該最近，這樣的話才是最優的。針對write-once-read-some型應用。）
還一個問題是，可能出現一個idc檔案資源存儲成功了，另一個idc的檔案資源沒有存儲成功的情況，同時也是應用需要考慮來解決的問題。
是以最近我也在考慮是否有其他的解決方案，即能夠做到分布存儲，又可以讓檔案存儲來做多idc複制，例如mongodb的master-slave。
例如
idc a ： （讀寫）
增加一個postgresql，用于存儲檔案存放的位置，
如:
idc_id,file_name,mongodb_hostname,mongodb_namespace
當檔案被寫入到mongodb時，同時寫入記錄到postgresql,這樣的話如果一個mongodb不夠了，可以加mongodb伺服器，
如果一台postgresql資料庫不夠用，甚至還可以對file_name進行hash分區，使用多台postgresql來堆。
當檔案被讀取時，先到postgresql讀取到檔案存放的位置，然後到mongodb讀取。
idc b： （隻讀）
利用postgresql的複制功能和mongodb的複制功能複制idc a的資料到idc b。idc b隻提供讀取功能，所有的寫在idc a完成。
如圖 :
這樣做的好處是在應用部署時會比較靈活，解決了就近存儲的問題。同時也簡化了應用設計，不需要應用來處理寫多個idc的問題。
當然，兩種方式都可能使得idc a 和idc b在短時間内有一定的資料延時。