c*****e
发帖数: 3226 | 1 1） the file system will be distributed across 3 台机器
2） 文件系统将被 apache farms mount to local file system 用于 serves
static files and 文件上传
3） 任何一台机器突然 断电不要丢失数据。
4） 这个系统最好安装简单， 小巧。
hdfs? owfs? Ceph? shrift? |
c*****e
发帖数: 3226 | 2 nnd, 发觉版上尽是些南郭先生，看似牛逼的architecture夸夸其谈和吵架，真问个具
体的技术问题，屁都没一个。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
f******2
发帖数: 2455 | 3 你这个需求HDFS与Ceph都行，如果文件都是小文件建议用Ceph，但是Ceph的缺点是
系统比HDFS复杂很多。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
f******2
发帖数: 2455 | 4 这个版上的很多都是语言类科普读物阅读(例如master Java in 21 days)
后出来切磋的,其实没有什么不好，因为更多的人是科普读物都没有读完，
看看版上的讨论，省21天时间也很好。
不喜欢就不要来好了。
【在 c*****e 的大作中提到】
: nnd, 发觉版上尽是些南郭先生，看似牛逼的architecture夸夸其谈和吵架，真问个具
: 体的技术问题，屁都没一个。
|
z****e
发帖数: 54598 | 5 现在开源的distributed file system弄来弄去就那么几个
甚至主流的就那一个
有什么选择可以做的？
你完全可以无脑上
就跟你问web server如果在jvm上用tomcat还是用resin好一样
没有什么意义，这种问题连回答的必要都没有
【在 c*****e 的大作中提到】
: nnd, 发觉版上尽是些南郭先生，看似牛逼的architecture夸夸其谈和吵架，真问个具
: 体的技术问题，屁都没一个。
|
c*****e
发帖数: 3226 | 6
那只能说明你半瓶水在那里晃，根本没实际的实用经验。就像你回答买车：车都差不多
，随便买一部就可以，这种问题连回答的必要都没有。
给你看看真的专业水平：
http://architects.dzone.com/articles/overview-and-recommendatio
【在 z****e 的大作中提到】
: 现在开源的distributed file system弄来弄去就那么几个
: 甚至主流的就那一个
: 有什么选择可以做的？
: 你完全可以无脑上
: 就跟你问web server如果在jvm上用tomcat还是用resin好一样
: 没有什么意义，这种问题连回答的必要都没有
|
c***d
发帖数: 996 | 7 你这个需求， 整分布式文件系统太麻烦了。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
g*****g
发帖数: 34805 | 8 像你这样的需求，很多带read replica的DB就可以完成。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
c*****e
发帖数: 3226 | 9 uploaded 的文件有好百兆， db 不可能
【在 g*****g 的大作中提到】
: 像你这样的需求，很多带read replica的DB就可以完成。
|
z****e
发帖数: 54598 | 10 又装逼
FILE SYSTEM都倒腾半天，干活要到什么时候去
毫无必要
你有兴趣自己搞就行了
没有必要拿出来显摆
当然有啥经验分享还是欢迎的
顺便，车的确都差不多，我开车是无所谓的
有车我就开
【在 c*****e 的大作中提到】
: uploaded 的文件有好百兆， db 不可能
|
|
|
z****e
发帖数: 54598 | 11 抓大放小
很多脚本在我看来也是一回事
ruby==python==groovy==javascript
要不你来议一议这几个的区别
【在 c*****e 的大作中提到】
: uploaded 的文件有好百兆， db 不可能
|
c***d
发帖数: 996 | 12 自己写个sync, 或者用s3, 连edge都有了.
【在 c*****e 的大作中提到】
: uploaded 的文件有好百兆， db 不可能
|
c*****e
发帖数: 3226 | 13 有些道理， rsync 也能凑合用，但是没法做到 single node down 不影响系统的使用。
另外 分布式文件系统API也可以用于 self implemented services.
【在 c***d 的大作中提到】
: 你这个需求， 整分布式文件系统太麻烦了。
|
c***d
发帖数: 996 | 14 没看懂。 你同时读两下， 哪个先回来就用哪个。 node down不down有什么关系。
不知道分布式文件系统有什么特别的api对你特别有意义。
用。
【在 c*****e 的大作中提到】
: 有些道理， rsync 也能凑合用，但是没法做到 single node down 不影响系统的使用。
: 另外 分布式文件系统API也可以用于 self implemented services.
|
z****e
发帖数: 54598 | 15 所以说
cassandra就可以了
【在 c***d 的大作中提到】
: 没看懂。 你同时读两下， 哪个先回来就用哪个。 node down不down有什么关系。
: 不知道分布式文件系统有什么特别的api对你特别有意义。
:
: 用。
|
c*****e
发帖数: 3226 | 16 apache 有这样的功能：可以同时 读两下， 哪个先回来就用哪个？ 除非自己改吧。
【在 c***d 的大作中提到】
: 没看懂。 你同时读两下， 哪个先回来就用哪个。 node down不down有什么关系。
: 不知道分布式文件系统有什么特别的api对你特别有意义。
:
: 用。
|
c***d
发帖数: 996 | 17 你upload和读都有自己的code吧。不过自己搞这些没必要，推上edge server算了。
【在 c*****e 的大作中提到】
: apache 有这样的功能：可以同时 读两下， 哪个先回来就用哪个？ 除非自己改吧。
|
b*******s
发帖数: 5216 | 18 别人要文件系统，你给上个数据库...
这样吧，我要scp东西上去，你给用数据库实现一下？楼主其实有一点说得对，这里有
几杆火铳遇到具体问题就抓瞎
【在 g*****g 的大作中提到】
: 像你这样的需求，很多带read replica的DB就可以完成。
|
z****e
发帖数: 54598 | 19 如果我告诉你vert.x可以轻松搞定scp呢？
【在 b*******s 的大作中提到】
: 别人要文件系统，你给上个数据库...
: 这样吧，我要scp东西上去，你给用数据库实现一下？楼主其实有一点说得对，这里有
: 几杆火铳遇到具体问题就抓瞎
|
g*****g
发帖数: 34805 | 20 如果文件大的话，DB管理metadata，文件可以扔s3上。
【在 c*****e 的大作中提到】
: uploaded 的文件有好百兆， db 不可能
|
|
|
z****e
发帖数: 54598 | 21 然，再用vert.x管理一下具体的网络传输协议
搞定
SOA都做好了
【在 g*****g 的大作中提到】
: 如果文件大的话，DB管理metadata，文件可以扔s3上。
|
g*****g
发帖数: 34805 | 22 这种应用层的实现毫无压力，现成的就有，所谓数据库也不过是存metadata，Blob还是
另存文件罢了。
【在 b*******s 的大作中提到】
: 别人要文件系统，你给上个数据库...
: 这样吧，我要scp东西上去，你给用数据库实现一下？楼主其实有一点说得对，这里有
: 几杆火铳遇到具体问题就抓瞎
|
g*****g
发帖数: 34805 | 23 S3存文件是个标准的解决方案。又简单又保证high availability，
如果你有meta data可以EC2上起个cluseter跑cassandra (simpleDB也行)，文件小的话
直接扔cassandra
里即可。
我说的这个方案是可以无限扩展，无论文件多少，用户多少，都可以保证速度的方法。
我们本身就这么管理一些文件。dropbox 也是用的S3。
楼上有几位啥都不懂的，动不动又要造轮子了。先想想把availability做到S3 99.99%
那么容易吗？ |
z****e
发帖数: 54598 | |
g*****g
发帖数: 34805 | 25 我老N年前就用jsch写过cloud上的concurrent logging search应用，拿scp来吓人实在
太外行了。你说问tcp能实现吗也罢了。
【在 z****e 的大作中提到】
: 我怀疑她压根不知道scp是怎么回事
: 只是想来显摆一下的
: 哈哈
: 她以为这种问题无法用lib解决
: 只能自己瞎写
: 这是mod for vert.x
: http://github.com/crashub/mod-shell
: 这是lib for java
: http://www.jcraft.com/jsch/
: 随便搞，有的是办法
|
c*****e
发帖数: 3226 | 26 AmazonS3？我的系统是内部的。
【在 g*****g 的大作中提到】
: 如果文件大的话，DB管理metadata，文件可以扔s3上。
|
g*****g
发帖数: 34805 | 27 必须内部那你还是hdfs吧。
【在 c*****e 的大作中提到】
: AmazonS3？我的系统是内部的。
|
z****e
发帖数: 54598 | 28 你信不信你最终会end up到hdfs和hadoop
cassandra来做cache管理这个最最最传统的方法上
所以说，无脑上就没错，讨论这么多不累么？我看着都累啊
【在 c*****e 的大作中提到】
: AmazonS3？我的系统是内部的。
|
c*****a
发帖数: 1638 | 29 除非他有处理这些文件内容的需求，否则end up在hdfs是很奇怪的事情。
hdfs当年设计出来就不是做他主贴里面这种事情的，HDFS的多数特性都是为了一个分部
计算系统做支持的file system提供的，单独作为file system挺弱。
LZ还是比较一下别的file system，你这种需求用hdfs+cassandra是很奇怪的。
S3对于LZ的需求可能会比较省事，但是会受制于带宽而且可能有思维上面的限制（很多
公司不愿意把文件放在外面）。除非他们已经开始用aws了，否则很难想象他们会为这
么个项目用aws。
LZ还是看看别的吧，虽然不很确定什么是最好的，但是HDFS和cassandra应该不适合你
这种情况，TCO会很高（除非你预见将来会有处理大数据文件的需求）。
【在 z****e 的大作中提到】
: 你信不信你最终会end up到hdfs和hadoop
: cassandra来做cache管理这个最最最传统的方法上
: 所以说，无脑上就没错，讨论这么多不累么？我看着都累啊
|
g*****g
发帖数: 34805 | 30 如果他们这些文件是给外部客户用的，用S3很合适。不用EC2但用了S3的应用也很常见。
如果只是内部用的，那才会有带宽限制这个问题。不过另一方面内部应用，通常也不用
考虑high availability。
【在 c*****a 的大作中提到】
: 除非他有处理这些文件内容的需求，否则end up在hdfs是很奇怪的事情。
: hdfs当年设计出来就不是做他主贴里面这种事情的，HDFS的多数特性都是为了一个分部
: 计算系统做支持的file system提供的，单独作为file system挺弱。
: LZ还是比较一下别的file system，你这种需求用hdfs+cassandra是很奇怪的。
: S3对于LZ的需求可能会比较省事，但是会受制于带宽而且可能有思维上面的限制（很多
: 公司不愿意把文件放在外面）。除非他们已经开始用aws了，否则很难想象他们会为这
: 么个项目用aws。
: LZ还是看看别的吧，虽然不很确定什么是最好的，但是HDFS和cassandra应该不适合你
: 这种情况，TCO会很高（除非你预见将来会有处理大数据文件的需求）。
|
|
|
z****e
发帖数: 54598 | 31 我觉得HDFS是一种GENERAL PURPOSE的系统
如果不是有什么很特殊的要求，就无脑上
我是这么搞的
【在 c*****a 的大作中提到】
: 除非他有处理这些文件内容的需求，否则end up在hdfs是很奇怪的事情。
: hdfs当年设计出来就不是做他主贴里面这种事情的，HDFS的多数特性都是为了一个分部
: 计算系统做支持的file system提供的，单独作为file system挺弱。
: LZ还是比较一下别的file system，你这种需求用hdfs+cassandra是很奇怪的。
: S3对于LZ的需求可能会比较省事，但是会受制于带宽而且可能有思维上面的限制（很多
: 公司不愿意把文件放在外面）。除非他们已经开始用aws了，否则很难想象他们会为这
: 么个项目用aws。
: LZ还是看看别的吧，虽然不很确定什么是最好的，但是HDFS和cassandra应该不适合你
: 这种情况，TCO会很高（除非你预见将来会有处理大数据文件的需求）。
|
w***g
发帖数: 5958 | 32 你要的不是distributed filesystem，而是三个镜像。rsync就可以。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
N*n
发帖数: 456 | 33 Linux 上可以选veritas或者GFS。 veritas 貌似要收钱，GFS不是很好用。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
N*n
发帖数: 456 | 34 搜了一下
Ceph 似乎是比 GFS 更新一些的系统。。 HDFS 就是Hadoop FS.. 其它两个都
没找到。
我的经验，这些cluster FS还真是有差别的。。设置，维护的难易程度挺不一样的。
文件数量大到一定程度以后是否撑得住。。平时运行好好的，加个security patch
重启一下回不来了或者在 fsck..从这个角度，云确实对开发者看起来是好事。。省
很多这些零碎问题。。
【在 N*n 的大作中提到】
: Linux 上可以选veritas或者GFS。 veritas 貌似要收钱，GFS不是很好用。
|
c*****a
发帖数: 1638 | 35 HDFS只能作为一个分布式处理系统的支撑，作为一个独立的文件系统来说，功能太弱了
。从长远来说，如果只是作为文件存储的解决方案，我个人觉得对未来功能扩展能提供
的可能性太低。
【在 z****e 的大作中提到】
: 我觉得HDFS是一种GENERAL PURPOSE的系统
: 如果不是有什么很特殊的要求，就无脑上
: 我是这么搞的
|
z****e
发帖数: 54598 | 36 我觉得文件系统-弱，是应该的
不弱那是不正常的，如果对哪些部分有其他需求
比如要求查找快，io快之类的
再通过某一个方面的强化产品来处理
而不是把所有的需求一股脑儿地丢给所谓的文件需求去处理
这样做的后果就象以前的数据库，啥都有，但是很难搞
成本也高，我对文件系统就几个要求，能存文件，别丢了，做好备份
没了，如果慢的话，我再想办法，做点cache什么的去处理
c*和hadoop是互补的两个处理系统，然后nosql和db本身也是互补的
所以你完全可以通过各种组合来实现你要的目的
而不用捆绑在一个所谓的产品上，我个人不喜欢又大又全的东西
喜欢先满足基本需求，然后挨个功能点做突破
【在 c*****a 的大作中提到】
: HDFS只能作为一个分布式处理系统的支撑，作为一个独立的文件系统来说，功能太弱了
: 。从长远来说，如果只是作为文件存储的解决方案，我个人觉得对未来功能扩展能提供
: 的可能性太低。
|
D*******a
发帖数: 3688 | 37 试过glusterfs吗？
hdfs好像没有人直接用来serve static files的，而且也不是很好集成吧（至少需要写
点code）
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
w***g
发帖数: 5958 | 38 glusterfs是个垃圾。idea不错，就是implement一直有问题，不适合用来存数据。
上了这个之后有你受的。我记得它读目录是去每个节点读一下，然后把结果合并，连数
据丢了都不会报错的。
【在 D*******a 的大作中提到】
: 试过glusterfs吗？
: hdfs好像没有人直接用来serve static files的，而且也不是很好集成吧（至少需要写
: 点code）
|
w***g
发帖数: 5958 | 39 非要上文件系统的话可以用MapR。这个是用来drop in替代HDFS的，而且设计非常科学
，存大文件小文件都没有问题。性能上可以秒杀HDFS。我在地下室就搞了个8个节点的
MapR机群用来存数据(自己做民科实验，用不起amazon)。Ceph我看过一两眼。这东西出
发点是并行计算而不是文件系统，存临时数据还可以，用来做主存储服务还是算了。
【在 c*****e 的大作中提到】
: 1） the file system will be distributed across 3 台机器
: 2） 文件系统将被 apache farms mount to local file system 用于 serves
: static files and 文件上传
: 3） 任何一台机器突然 断电不要丢失数据。
: 4） 这个系统最好安装简单， 小巧。
: hdfs? owfs? Ceph? shrift?
|
q*c
发帖数: 9453 | 40 现在用的都是 dynamDB...
【在 g*****g 的大作中提到】
: S3存文件是个标准的解决方案。又简单又保证high availability，
: 如果你有meta data可以EC2上起个cluseter跑cassandra (simpleDB也行)，文件小的话
: 直接扔cassandra
: 里即可。
: 我说的这个方案是可以无限扩展，无论文件多少，用户多少，都可以保证速度的方法。
: 我们本身就这么管理一些文件。dropbox 也是用的S3。
: 楼上有几位啥都不懂的，动不动又要造轮子了。先想想把availability做到S3 99.99%
: 那么容易吗？
|
|
|
g*****g
发帖数: 34805 | 41 Cassandra便宜呀，当然坏处就是得自己管。
http://www.datastax.com/2012/05/cassandra-vs-dynamodb-tco
【在 q*c 的大作中提到】
: 现在用的都是 dynamDB...
|
h**********0
发帖数: 88 | 42 就这要求3个linux装个直接nfs和autofs就可以了 |
c*****e
发帖数: 3226 | 43 我只能说你的那个方案是 a poor man's solution.
第一： autofs 不能mount two nfs into the same local directory. 估计还得写个
script 监控 first nsf mount is down, then mount 2nd nsf onto the same local
mounting point. 可靠性太差
第二：如果在上传文件过程中nfs server is down, 上传的内容没了， client 也没有
续传功能的话，整个操作就失败了。
distributed file system 内部包装解决了这些问题。
【在 h**********0 的大作中提到】
: 就这要求3个linux装个直接nfs和autofs就可以了
|
