最近有个资源整合的项目，存储的话选择了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在短时间内有一定的数据延时。
原本可能会选择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 A 和IDC B在短时间内有一定的数据延时。
