thinking about application known or un-known distributed storage-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

thinking about application known or un-known distributed storage

简介:
最近有个资源整合的项目,存储的话选择了mongodb的sharding来做,因为数据量较大。
原本可能会选择Hadoop来做的,不过从Hadoop的文档上看到好像不太适用大并发的小IO的操作(小文件),更加适用大吞吐量小并发的操作(大文件)。
应用要求多IDC部署,因此资源文件也要求在多IDC存储(相当于每个IDC需要有同样的资源文件)。
考虑到扩展性,在一个IDC内部使用了mongoDB的sharding特性。
但是这样带来一个问题,不方便复制到其他的IDC,所以目前的做法是应用层在写入文件存储的时候同时调用远端IDC的应用写入文件到远端IDC的mongoDB sharding。
thinking about application known or un-known distributed storage - 德哥@Digoal - The Heart,The World.

。这样做的好处是单个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完成。

如图 : 
thinking about application known or un-known distributed storage - 德哥@Digoal - The Heart,The World.
 
这样做的好处是在应用部署时会比较灵活,解决了就近存储的问题。同时也简化了应用设计,不需要应用来处理写多个IDC的问题。
当然,两种方式都可能使得IDC A 和IDC B在短时间内有一定的数据延时。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章