如何设计分布式图片服务器存储方案
wing
sunway
On 3月31日, 上午10时25分, wing <wing922w...@gmail.com> wrote:
> 目前要设计一个分布式的文件服务器，主要存贮图片、文档等小文件，数量巨大且访问并发很高，不知道应该如何选型，考查过大量开源的分布式文件系统，目前主要关注-FastDFS，KFS与gluster，但是资料太少，且这些开源代码都不是特别稳定，用在生产系统比较担心，如果谁有这方面架构经验，希望能够指导一下，除-了使用分布式存储中间件，还有其他什么解决方案，另外在缓存等方面的设计要点，大家能不能交流一下心得，这方面的资料太少，而且文档上的东西流于书面化，希望听-到大家实际的架构经验，毕竟稳定性是第一位的。
yuliuxuanke
wing
dennis
MogileFS，也是为了存储图片，这个东西据说适合小文件分布存储，听说金山内部也用这个，也许楼主可以查查这方面的资料。
sunway
On 3月31日, 下午1时18分, wing <wing922w...@gmail.com> wrote:
> gfs只是几篇论文，kfs正在研究文档和代码，就是想知道有没兄弟在这个领域有实践的经验，另外，kfs是否适合高并发小文件的存储系统使用？hadoop的-底层hdfs简单研究了一下，似乎不太适合小文件的存储，楼上用过kfs，能不能说说它的优缺点，特别对比hdfs的优缺点，以及在类似项目中选用kfs的理由-？
XiongJia Le
esx
图片服务主要面向的是大量的小文件，而且需要密集的被访问。当前可获得的几乎所有分布式存储方式都不适合这么做。原因如下：
1. KFS、HADOOP，GFS均是对搜索引擎支持的存储解决方案，而非常规意义上的文件系统。其内存的都是以GB论的很大的文件。其设计本身不适
合小文件。就目前而言KFS、HADOOP，GFS等这类仿GoogleFS的作品都是以单个master+多机备份（一般还不是多机服务，只是备份而
已）+日志而存在。考虑到其需要简单实现，其metadata本身就不存在支持大量文件的能力（靠内存+snapshot撑，没有外存访问机制）。图片
的特点是文件小而数量大。诸如GFS面向的文件是，文件大，而数量相对较小。
2. 对大文件来说，(1)访问一次metadata，(2)再访问一次存储节点，(3)之后获得数据，其中(1)和(2)所产生的成本是可以忽略的，
并且可以通过多服务器的吞吐量来提高对大文件的吞吐能力。但就小文件来说，其所产生的查询、吞吐成本是不可忽略的。
3. 图片这种互联网应用，是访问量巨大的。诸如GFS这种存储方式，不能解决该问题。原因为其metadata服务器为单点，服务能力和扩展能力均有
限。试想如果每秒30000 IOPS，metadata server能承受这么大的查询量么？
4. 诸如像FastDFS，其特点是没有文件metadata，由应用去解决，个人认为还不算是一个分布式文件系统。且仍然不能避免上述三点。
5. MogileFS的特点就更有意思，干脆外包了metadata，由MySQL做的metadata。有点太山寨了。我认为就是为了做个所谓的
FS而做的。
不要被Google的paper迷惑了。
值得一提的是，虽然我不认为分布式文件系统不适合互联网级别的在线应用，但是分布式文件系统具有能存储海量数据，扩展性好，HA的特点。我认为非常适合
存近线数据和备份数据。即非访问热点数据。
On Mar 31, 10:25 am, wing <wing922w...@gmail.com> wrote:
> 目前要设计一个分布式的文件服务器，主要存贮图片、文档等小文件，数量巨大且访问并发很高，不知道应该如何选型，考查过大量开源的分布式文件系统，目前主要关注-FastDFS，KFS与gluster，但是资料太少，且这些开源代码都不是特别稳定，用在生产系统比较担心，如果谁有这方面架构经验，希望能够指导一下，除-了使用分布式存储中间件，还有其他什么解决方案，另外在缓存等方面的设计要点，大家能不能交流一下心得，这方面的资料太少，而且文档上的东西流于书面化，希望听-到大家实际的架构经验，毕竟稳定性是第一位的。
wing
但是目前我还是想不出什么样的架构更为适合，因为我们不是做网站的，对这块不太了解，希望你能再多说一些，另外从网上看到的一个照片网站的架构，后台也使用了MogileFS的方式，但对于fastDFS和MogileFS我有和你一样的困惑，这样的metaData管理是有问题的，尤其是MogileFS。
也许做过大型网站的，对这种文件系统更了解，你的回答对我帮助很大，能不能说说这种高并发小文件适用的架构，我们内部使用tcp长连接访问，也提供http形式的接入访问，前者是出于性能的考虑，这样的形式，应该如何架构？能否给出一些建议或者资料，非常感谢！
sunway
然后配合大量的memory cache，在数据量不是非常大的情况下可以解决并发问题。
wing
不高，这点比较特别。
大家可以看看这张图，http://www.yupoo.com/images/spacer.gif，附件中也包含了，但是感觉过于复杂，很多地方不太明白，希望有经验的指导一下，多谢！
wing
esx
On Apr 1, 10:13 am, wing <wing922w...@gmail.com> wrote:
> 非常感谢esx的回复，经过详细的阅读gfs论文和相关框架说明，得出和你一样的看法，gfs类似的不适合高并发小文件的存储，事实上gfs的论文中也明确说明-了主要对大文件操作，支持小文件但是不做优化，
> 但是目前我还是想不出什么样的架构更为适合，因为我们不是做网站的，对这块不太了解，希望你能再多说一些，另外从网上看到的一个照片网站的架构，后台也使用了M-ogileFS的方式，但对于fastDFS和MogileFS我有和你一样的困惑，这样的metaData管理是有问题的，尤其是MogileFS。
> 也许做过大型网站的，对这种文件系统更了解，你的回答对我帮助很大，能不能说说这种高并发小文件适用的架构，我们内部使用tcp长连接访问，也提供http形式-的接入访问，前者是出于性能的考虑，这样的形式，应该如何架构？能否给出一些建议或者资料，非常感谢！
lijie
> 我不认为当前通用的所谓的分布式存储解决方案能够解决你的问题。
> 图片服务主要面向的是大量的小文件，而且需要密集的被访问。当前可获得的几乎所有分布式存储方式都不适合这么做。原因如下：
> 1. KFS、HADOOP，GFS均是对搜索引擎支持的存储解决方案，而非常规意义上的文件系统。其内存的都是以GB论的很大的文件。其设计本身不适
> 合小文件。就目前而言KFS、HADOOP，GFS等这类仿GoogleFS的作品都是以单个master+多机备份（一般还不是多机服务，只是备份而
> 已）+日志而存在。考虑到其需要简单实现，其metadata本身就不存在支持大量文件的能力（靠内存+snapshot撑，没有外存访问机制）。图片
> 的特点是文件小而数量大。诸如GFS面向的文件是，文件大，而数量相对较小。
可以在这些文件系统上存储文件内容，小文件拼成大文件存储即可，GFS/HADOOP应该都支持流式存储。图片的metadata存放到其它性能较高的key-value存储上。
> 2. 对大文件来说，(1)访问一次metadata，(2)再访问一次存储节点，(3)之后获得数据，其中(1)和(2)所产生的成本是可以忽略的，
> 并且可以通过多服务器的吞吐量来提高对大文件的吞吐能力。但就小文件来说，其所产生的查询、吞吐成本是不可忽略的。
> 3. 图片这种互联网应用，是访问量巨大的。诸如GFS这种存储方式，不能解决该问题。原因为其metadata服务器为单点，服务能力和扩展能力均有
> 限。试想如果每秒30000 IOPS，metadata server能承受这么大的查询量么？
GFS的paper上提到使用客户端Cache来缓解metadata
server的压力，这是针对大数据的优化。如果图片的metadata自己管理，可以使用hash分布＋cache方式来解决压力问题。如果metadata使用MySQL存储，只要它能顶住cache未命中部分的压力即可。
> 4. 诸如像FastDFS，其特点是没有文件metadata，由应用去解决，个人认为还不算是一个分布式文件系统。且仍然不能避免上述三点。
> 5. MogileFS的特点就更有意思，干脆外包了metadata，由MySQL做的metadata。有点太山寨了。我认为就是为了做个所谓的
> FS而做的。
这种做法也无不可，我知道有几家大公司这么山寨的，用MySQL + HADOOP(或自己写的分布式文件系统)
：）metadata的安全性、可管理性很重要，一般从头做这样的系统会尽量使用已有的成熟方案，这部分有把握了以后再替换掉。
个人感觉找一个现成的、功能完全符合甚至是量身打造的解决方案并不容易，不过可以利用一些开源的系统组合出你要的方案。
wing
esx
On Apr 1, 1:21 pm, lijie <cpun...@gmail.com> wrote:
> 2009/4/1 esx <nay...@gmail.com>:
>
> > 我不认为当前通用的所谓的分布式存储解决方案能够解决你的问题。
> > 图片服务主要面向的是大量的小文件，而且需要密集的被访问。当前可获得的几乎所有分布式存储方式都不适合这么做。原因如下：
> > 1. KFS、HADOOP，GFS均是对搜索引擎支持的存储解决方案，而非常规意义上的文件系统。其内存的都是以GB论的很大的文件。其设计本身不适
> > 合小文件。就目前而言KFS、HADOOP，GFS等这类仿GoogleFS的作品都是以单个master+多机备份（一般还不是多机服务，只是备份而
> > 已）+日志而存在。考虑到其需要简单实现，其metadata本身就不存在支持大量文件的能力（靠内存+snapshot撑，没有外存访问机制）。图片
> > 的特点是文件小而数量大。诸如GFS面向的文件是，文件大，而数量相对较小。
>
> 可以在这些文件系统上存储文件内容，小文件拼成大文件存储即可，GFS/HADOOP应该都支持流式存储。图片的metadata存放到其它性能较高的key--value存储上。
>
你这个说的其实是facebook实现的类似的方式，使用heystack。其实把小文件拼成chunk，主要是为了解决传统FS对小文件的不足以及内
存管理对小文件的浪费。不能解决小文件在网络IO上的损耗。key-value存储是可以简单的实现对pic->location的定位。但是多引入了
存储以外的不可靠因素，一旦metadata出了问题，则整个系统出现问题。
另一方面，简单的key-value metadata方式，只能是一个存储解决方案，这种方式不支持目录、权限控制、link等文件系统特性，灵活性
受限。
> > 2. 对大文件来说，(1)访问一次metadata，(2)再访问一次存储节点，(3)之后获得数据，其中(1)和(2)所产生的成本是可以忽略的，
> > 并且可以通过多服务器的吞吐量来提高对大文件的吞吐能力。但就小文件来说，其所产生的查询、吞吐成本是不可忽略的。
> > 3. 图片这种互联网应用，是访问量巨大的。诸如GFS这种存储方式，不能解决该问题。原因为其metadata服务器为单点，服务能力和扩展能力均有
> > 限。试想如果每秒30000 IOPS，metadata server能承受这么大的查询量么？
>
> GFS的paper上提到使用客户端Cache来缓解metadata
> server的压力，这是针对大数据的优化。如果图片的metadata自己管理，可以使用hash分布＋cache方式来解决压力问题。如果metadata-使用MySQL存储，只要它能顶住cache未命中部分的压力即可。
缓存确实可以解决问题。我猜你是做互联网行业的吧？;)，但是有个问题，互联网的图片是用户产生的，不是自己产生的。用户可以产生数以十亿计的图片。而
且访问热点并不是那么集中。公开的数据是facebook把缓存做的如此好了，也只有92%左右的命中率，对于后端的存储来说，8%的穿透率足可以压垮
这个分布式存储机器。如GFS这种单机metadata的做法。是很难支撑的。
为什么不会复制metadata呢？如果是一个简单的存储解决方案，假设用MySQL+Replication，那么replication是有延时
的。不能在语义上得到保证。用户创建了一个文件并不能马上访问到。能否做到满足语义呢？可以。但是很难避免在创建时候的时间加长、技术复杂度上升。
>
> > 4. 诸如像FastDFS，其特点是没有文件metadata，由应用去解决，个人认为还不算是一个分布式文件系统。且仍然不能避免上述三点。
> > 5. MogileFS的特点就更有意思，干脆外包了metadata，由MySQL做的metadata。有点太山寨了。我认为就是为了做个所谓的
> > FS而做的。
>
> 这种做法也无不可，我知道有几家大公司这么山寨的，用MySQL + HADOOP(或自己写的分布式文件系统)
> ：）metadata的安全性、可管理性很重要，一般从头做这样的系统会尽量使用已有的成熟方案，这部分有把握了以后再替换掉。
>
> 个人感觉找一个现成的、功能完全符合甚至是量身打造的解决方案并不容易，不过可以利用一些开源的系统组合出你要的方案。
你说的很对。;)我觉得没必要为了分布式文件系统而分布式。实际上能解决问题即可。如果wing的存储、访问量都没有那么大。那么我认为也没必要考虑的
太长远，这是设计大计，能满足当前需要即可，将来的事情，很难预料。
Keep It Simple Stupid! 不过得知道什么是Simple什么不是，才够Stupid！;)
Keyou Liu
lijie
> 你这个说的其实是facebook实现的类似的方式，使用heystack。其实把小文件拼成chunk，主要是为了解决传统FS对小文件的不足以及内
> 存管理对小文件的浪费。不能解决小文件在网络IO上的损耗。key-value存储是可以简单的实现对pic->location的定位。但是多引入了
> 存储以外的不可靠因素，一旦metadata出了问题，则整个系统出现问题。
> 另一方面，简单的key-value metadata方式，只能是一个存储解决方案，这种方式不支持目录、权限控制、link等文件系统特性，灵活性
> 受限。
的确是这样，还是要根据应用来设计，metadata由于相对较小，办法自然也多一些，这种方式主要解决大数据存储问题。
> 缓存确实可以解决问题。我猜你是做互联网行业的吧？;)，但是有个问题，互联网的图片是用户产生的，不是自己产生的。用户可以产生数以十亿计的图片。而
> 且访问热点并不是那么集中。公开的数据是facebook把缓存做的如此好了，也只有92%左右的命中率，对于后端的存储来说，8%的穿透率足可以压垮
> 这个分布式存储机器。如GFS这种单机metadata的做法。是很难支撑的。
> 为什么不会复制metadata呢？如果是一个简单的存储解决方案，假设用MySQL+Replication，那么replication是有延时
> 的。不能在语义上得到保证。用户创建了一个文件并不能马上访问到。能否做到满足语义呢？可以。但是很难避免在创建时候的时间加长、技术复杂度上升。
目前的确是在互联网行业：）
这个问题以前也想过方法，比如创建了一个文件，马上把它的元数据塞进cache，访问就不会到metadata存储上，还是比较有效的，一般上传
一张图片都会马上在页面上显示一下，还可以减轻负载。当然复杂度还是会上升的，异地部署也更困难。也有其它办法避免，比如从文件名上就可以判断出图片是最近几天上传的，尽量从master上获取，老图就尽量从slave上获取，设计时多考虑一些方案。
facebook的用户、数据都是比较多的，由于是熟人网络，热点也较散，所以92％也很不错了。不过国内网站情况可能不太一样，国内用户产生内容也相对较少，有些产生内容较多的网站用户群又比较小，所以cache命中可以更高〜
好像离楼主的问题比较远了。建议楼主先统计图片热点、命中情况，说不定自己做几台CDN就解决问题了
lijie
2009/4/1 lijie <cpu...@gmail.com>:
wing
初步先用NFS加上自己开发的一些调度软件来解决，相对比较简单，同时会开发一个分布的文件存储系统来代替NFS，特别感谢esx，lijie和所有回复的兄弟们，看了你们的回复，解开了很多迷惑，非常感谢！^_^
wing
esx
On 4月2日, 上午11时26分, wing <wing922w...@gmail.com> wrote:
> 采用NFS主要原因还是因为NFS在内部已经有大容量的部署经验，所以可以很快部署上去，相应的调度备份软件也有现成的，只要做一些改造就可以，至于是否适合应 用，需要进一步做测试，NFS目前使用的最大问题是并发上不太好，其他倒没有遇到太大问题，至于开发分布式文件存储，也有后期的其他需求考虑，不过esx老大说 的对，没必要为分布而分布。。。
NFS，通用系统的NFS结构，普遍存在一些效率问题。对待小文件的访问效率上，NFS的效率不太敢恭维。另外NFS还有一些很讨厌的缺点：更新不能及
时、mount point太多、NFS Server挂了后容易使Client挂起等。
有些是能绕开的，有些则很难绕开。NFS是20多年前的经典设计，但现在看，有些显老了。但由于NFS的工业标准、适用面很广等因素，目前还没有一个能
够很好的替代NFS的下一代技术。
这要看你的需求，是不是真的有这么大的数据量和访问量。数据量和机器量变的更大的时候，可以考虑使用其他方法。
另外就是，如lijie兄弟所说，一般来说都需要缓存机制，很少有说只靠FS去生扛压力的。
Zoom.Quiet
2009/4/2 esx <nay...@gmail.com>:
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Time is unimportant, only life important!
esx
On 4月2日, 下午1时13分, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:
> ZFS
>
> 2009/4/2 esx <nay...@gmail.com>:
>
>
>
> > On 4月2日, 上午11时26分, wing <wing922w...@gmail.com> wrote:
> >> 采用NFS主要原因还是因为NFS在内部已经有大容量的部署经验，所以可以很快部署上去，相应的调度备份软件也有现成的，只要做一些改造就可以，至于是否适合应 用，需要进一步做测试，NFS目前使用的最大问题是并发上不太好，其他倒没有遇到太大问题，至于开发分布式文件存储，也有后期的其他需求考虑，不过esx老大说 的对，没必要为分布而分布。。。
>
> > NFS，通用系统的NFS结构，普遍存在一些效率问题。对待小文件的访问效率上，NFS的效率不太敢恭维。另外NFS还有一些很讨厌的缺点：更新不能及
> > 时、mount point太多、NFS Server挂了后容易使Client挂起等。
> > 有些是能绕开的，有些则很难绕开。NFS是20多年前的经典设计，但现在看，有些显老了。但由于NFS的工业标准、适用面很广等因素，目前还没有一个能
> > 够很好的替代NFS的下一代技术。
> > 这要看你的需求，是不是真的有这么大的数据量和访问量。数据量和机器量变的更大的时候，可以考虑使用其他方法。
>
> > 另外就是，如lijie兄弟所说，一般来说都需要缓存机制，很少有说只靠FS去生扛压力的。
>
wing
不敢在gtalk上贸然打扰，等esx有空时，可以简单说几个架构方案，我再去找资料看看，有个方向。
网上找到的几个网站架构方案，看起来也很山寨，可能有真正好的方案，也都是有经验的人做出来的，不一定会放在网上，所以现在只能先用NFS的方式在内部测试部署，至少目前是可行的，然后再寻找更好的方案进行替换。对于文件系统还是一个比较模糊的概念，通过esx、lijie等老大的指点，稍微有点了解了，一些初级问题让大家见笑了，请谅解，对个人来说，这是一个全新的领域，有点晕。^_^
HA
器，构建通用的文件系统很浪费。LZ能否说说特别的场景？
On Mar 31, 10:25 am, wing <wing922w...@gmail.com> wrote:
HA
就要访问db
hash 的方式非常棒，但是扩展性有些问题，因为假如要扩展服务器，文件都得移动
张沈鹏
关键字: tokyo tyrant, tokyo cabinet
Tokyo Cabinet 是日本人 Mikio Hirabayashi开发的一款 DBM
数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等
DBM 的几倍。
Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。
当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按
key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM
等等是相同的，但是比它们的性能要好得多（因此可以替代它们)
当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。
As for database of fixed-length array, records are stored with unique
natural numbers. It is impossible to store two or more records with a
key overlaps. Moreover, the length of each record is limited by the
specified length. Provided operations are the same as ones of hash
database.
对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限 制。读取方法和hash表的一样。
Tokyo Cabinet是用C写的，同时提供c,perl,ruby,java的API。Tokyo
Cabinet在提供了POSIX和C99的平台上都可用，它以GNU Lesser Public License协议发布。
Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。
Tokyo Tyrant 加上 Tokyo
Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo
Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。
http://approach.javaeye.com/blog/346652
2009/4/3 HA <heli...@gmail.com>:
--
张沈鹏
http://zsp.javaeye.com/
Mobile: 13693622296
wing
目前的应用场景是，应用服务器需要大容量和高并发的小文件访问系统，近期没有客户端的直接访问，但不排除以后通过架设http
server，提供互联网用户的直接下载、上传和编辑。
如果不通过db或者其他类似查表的方式来定位文件，有什么更好的办法，hash的效率确实很高，但是一旦节点扩展，迁移数据的代价也很大，个人的想法还是通过类似mogileDFS这样的方式进行架构，虽然可能代码会自行用c来实现，数据库方面可以利用
张沈鹏推荐的类似的高效mendb方式来查询，不知道这样的架构是否合理，是否有更好的方式？
因为目前的应用，有点类似网盘，每个用户的文件都是用户自身的，很难找出访问特别频繁的文件，因此cache作用不显著，以后可能会有相互的共享、推荐之类应用，那时候cache的作用会比较大一些。
HA
理。
btw, 访问特性不能凭借想象，要统计一下才行，有时事实出乎意料，我在其他的case是有过教训的
HA
张沈鹏
据我所知 还有baidu赞助的这个项目可选
不过这个我并没有实际用过
"""
如果不通过db或者其他类似查表的方式来定位文件，有什么更好的办法，hash的效率确实很高，但是一旦节点扩展，迁移数据的代价也很大，个人的想法还是通过类似mogileDFS这样的方式进行架构，虽然可能代码会自行用c来实现，数据库方面可以利用
"""
http://www.kuqin.com/web/20080725/12289.html
可以参考文章中的Consistent Hashing,来减少数据迁移
我们现在的key 采用类似url的方式
比如
blog/entry/335/text
这样也可以通过url前缀来制定分布方式
自己写也可以
我们公司在Tokyo Cabinet上写了一个分布式数据库(数据存3份),读性能是mogileFs 2-3倍,写性能是其50倍
wing
多谢ha兄的提醒，但因为现在是预先做方案，所以没法得到真实的测试数据，只能预测，这点很头痛，另外，如果需要做简单的文件搜索的话，用hash的方法，搜索这方面似乎也比较麻烦，如果用mem
db的方式，是不是可以直接在上面做搜索，之前看过sina的memcacheDb，现在再去看看沈鹏兄推荐的Tokyo Cabinet。
多谢二位的指点，这方面实在是菜鸟一个，很多入门问题都才刚刚搞懂，这些东西又需要比较多的经验，不是google就能得到，能得到几位有经验的前辈指点，实在是受益匪浅！^_^
wing
即便使用了memdb，数据量很大的情况下，性能是否还能很高，比如一个用户1000个文件，10万用户就是一亿，多个应用的话，这个数量更大，这样的话，这种架构是否存在问题？还是说干脆不要考虑metadata的搜索，只负责文件的存储，fastDFS就是这么做的，它的tacker
sever事实上负担不大，因此理论上还是可以承受比较高的并发，如果需要记录并维护每个文件的meta的话，数据量增大后，恐怕并发很难上去？
现在这个阶段没有搜索的需求，但是以后很可能有类似的需求，因此我在考虑架构时，不得不预先考虑这个问题，如果不保存metadata，或者将metadata和文件一起存放，完全由文件使用者维护，那么以后就不可能跨应用的搜索服务了，这是我目前没想好的一个地方，请大家指点。
--
wing
wing9...@gmail.com
Hope is a good thing, maybe the best of things.
张沈鹏
> 目前考虑的想法是，如果文件系统不做metadata查询的话，我可以直接对文件名做hash，然后hash的结果对应到一个数组，数组作为一个虚拟节点配置表，一旦节点调整了，我可以不修改hash算法也不迁移数据，只要修改虚拟节点配置表即可，对于我的应用来说，只要定义一个足够大的虚拟节点表，这样做法扩展和速度都不错，也不需要动用数据库。或者在url中包含一些规则来处理，具体的做法会结合存储系统再确定，这方面都不太困难，但是如果需要对文件metadata进行查询的话，我能想到就只能利用db来保存metadata了（是不是还有更好的方法？）
> 即便使用了memdb，数据量很大的情况下，性能是否还能很高，比如一个用户1000个文件，10万用户就是一亿，多个应用的话，这个数量更大，这样的话，这种架构是否存在问题？还是说干脆不要考虑metadata的搜索，只负责文件的存储，fastDFS就是这么做的，它的tacker
> sever事实上负担不大，因此理论上还是可以承受比较高的并发，如果需要记录并维护每个文件的meta的话，数据量增大后，恐怕并发很难上去？
只负责文件的存储就足够了吧 其他的再加一层进行
"""
不保存metadata，或者将metadata和文件一起存放，完全由文件使用者维护，那么以后就不可能跨应用的搜索服务了
"""
可以保存啊 但不是用文件系统保存 另外找个数据库去保存
esx
这种哈希只是哈希算法的一个变形而已。其更适合的领域应该是缓存系统、p2p系统等。也就是说是允许丢数据的系统。
memcache的那个一致性哈希也只是说，如果加入了一台mc的server，client如何尽量少的减少缓存损失的影响而已。
试想这和hash%1000出1000个片，存在10台机器上，每台机器上负责100个片，效果是类似的的。扩容的时候，要么成倍扩容，增至20台机
器，把每台机器上的片数由100减少至50。要么找个点存储1000个片和20台机器的对应（相当于DNS，这个数据量很小）。
另外我对TC也有怀疑（不过没有实际用过，只是瞎说）。看TC的代码，也不过是bdb的hash和b+tree。在算法上可以榨出的效率是非常有限
的。
其给出的测试结果却是比bdb甚至高出两个数量级。单就产生的数据量，直接的磁盘IO可能都达不到那个速度。所以我怀疑于此。
除非其用了很大的buffer来缓冲b+tree的node，否则很难达到这么惊人的速度。所以，这一切都是浮云~ ;)。这样可能会带来一个问题就是
突然停电的时候丢失的数据会很多。或者在一定时候会集中产生较多的IO。
另外你用关系型数据库和key-value型数据库进行比较是不科学的，这两个应用领域不同，可比性有限。
On 4月6日, 上午10时48分, 张沈鹏 <zsp...@gmail.com> wrote:
> http://www.hypertable.org/about.html
> 据我所知 还有baidu赞助的这个项目可选
> 不过这个我并没有实际用过
>
> """
> 如果不通过db或者其他类似查表的方式来定位文件，有什么更好的办法，hash的效率确实很高，但是一旦节点扩展，迁移数据的代价也很大，个人的想法还是通过类 似mogileDFS这样的方式进行架构，虽然可能代码会自行用c来实现，数据库方面可以利用
esx
不过后来TC也做了一个mc的接口。
mcdb的模型是单进程单线程模型，简而言之就是使用了memcache的协议来处理bdb存储。对通常的简单应用来说还是够用了。
但是存在的问题是：由于其单进程单线程模型，会造成因为进程在等待IO时造成进程挂起等待IO，从而严重降低了响应能力。
mcdb一边要处理网络IO，另一边要处理bdb的磁盘IO。单进程模型的能力很有限。
TC的模型是使用线程池的概念做的。在上述的问题中，会得到相对较好的解决。其主线程相应网络IO，子线程去处理磁盘IO。响应能力理论上应该有很大提
高。
On 4月7日, 上午10时02分, wing <wing922w...@gmail.com> wrote:
> 沈鹏兄对比过Tokyo Cabinet和sina的memcachedb的性能？
>
> 多谢ha兄的提醒，但因为现在是预先做方案，所以没法得到真实的测试数据，只能预测，这点很头痛，另外，如果需要做简单的文件搜索的话，用hash的方法，搜索 这方面似乎也比较麻烦，如果用mem
esx
我觉得heystack结构是处理图片等互联网级的小文件的一个相对妥善的解决办法。如果有足够的开发力量，确实可以考虑。
haystack结构是使用一个一个的chunk来保存多张图片（chunk还有很多对OS有益的好处）。
简言之，图片的ID就是这个文件的文件名+其所在的偏移位置和一些相关信息。
图片ID是交由业务去保存的，和存储无关。这样存储就解决了metadata保存的问题，也就是说，不保存metadata，由应用去保存。
不过这么做是有限制的，即图片不能更改（本来图片就不会更改），图片删除后空间难以再被利用（这对需要长期保存的用户数据来说，也不是什么问题）。
On 4月7日, 下午1时59分, wing <wing922w...@gmail.com> wrote:
> 目前考虑的想法是，如果文件系统不做metadata查询的话，我可以直接对文件名做hash，然后hash的结果对应到一个数组，数组作为一个虚拟节点配置表 ，一旦节点调整了，我可以不修改hash算法也不迁移数据，只要修改虚拟节点配置表即可，对于我的应用来说，只要定义一个足够大的虚拟节点表，这样做法扩展和速 度都不错，也不需要动用数据库。或者在url中包含一些规则来处理，具体的做法会结合存储系统再确定，这方面都不太困难，但是如果需要对文件metadata进 行查询的话，我能想到就只能利用db来保存metadata了（是不是还有更好的方法？）
> 即便使用了memdb，数据量很大的情况下，性能是否还能很高，比如一个用户1000个文件，10万用户就是一亿，多个应用的话，这个数量更大，这样的话，这种 架构是否存在问题？还是说干脆不要考虑metadata的搜索，只负责文件的存储，fastDFS就是这么做的，它的tacker
> sever事实上负担不大，因此理论上还是可以承受比较高的并发，如果需要记录并维护每个文件的meta的话，数据量增大后，恐怕并发很难上去？
> 现在这个阶段没有搜索的需求，但是以后很可能有类似的需求，因此我在考虑架构时，不得不预先考虑这个问题，如果不保存metadata，或者将metadata 和文件一起存放，完全由文件使用者维护，那么以后就不可能跨应用的搜索服务了，这是我目前没想好的一个地方，请大家指点。
>
> --
> wing
> wing922w...@gmail.com
esx
如果我没理解错，你的图片需求，还是以用户为单位的。这种以用户为单位的数据挖掘和搜索，往往都是和用户绑在一起的。
即要由用户提供的信息来进行搜索，很难在纯图片存储这一层进行搜索。考虑太多了，反而不利于你伸展拳脚，对于那些虚无缥缈的需求，则以后再说，否则你还
睡的着觉么？;D
况且目前图片搜索的生产可用实现几乎没有，全部都是基于用户提供的信息的搜索，譬如用户给这个图片起了个什么名字之类。
如果仅仅是维护性的对FS的遍历性的搜索某个文件。那通用的FS就能解决你的问题了。
On 4月7日, 下午1时59分, wing <wing922w...@gmail.com> wrote:
> 目前考虑的想法是，如果文件系统不做metadata查询的话，我可以直接对文件名做hash，然后hash的结果对应到一个数组，数组作为一个虚拟节点配置表 ，一旦节点调整了，我可以不修改hash算法也不迁移数据，只要修改虚拟节点配置表即可，对于我的应用来说，只要定义一个足够大的虚拟节点表，这样做法扩展和速 度都不错，也不需要动用数据库。或者在url中包含一些规则来处理，具体的做法会结合存储系统再确定，这方面都不太困难，但是如果需要对文件metadata进 行查询的话，我能想到就只能利用db来保存metadata了（是不是还有更好的方法？）
> 即便使用了memdb，数据量很大的情况下，性能是否还能很高，比如一个用户1000个文件，10万用户就是一亿，多个应用的话，这个数量更大，这样的话，这种 架构是否存在问题？还是说干脆不要考虑metadata的搜索，只负责文件的存储，fastDFS就是这么做的，它的tacker
> sever事实上负担不大，因此理论上还是可以承受比较高的并发，如果需要记录并维护每个文件的meta的话，数据量增大后，恐怕并发很难上去？
> 现在这个阶段没有搜索的需求，但是以后很可能有类似的需求，因此我在考虑架构时，不得不预先考虑这个问题，如果不保存metadata，或者将metadata 和文件一起存放，完全由文件使用者维护，那么以后就不可能跨应用的搜索服务了，这是我目前没想好的一个地方，请大家指点。
>
> --
> wing
> wing922w...@gmail.com
wing
“试想这和hash%1000出1000个片，存在10台机器上，每台机器上负责100个片，效果是类似的的。扩容的时候，要么成倍扩容，增至20台机
器，把每台机器上的片数由100减少至50。要么找个点存储1000个片和20台机器的对应（相当于DNS，这个数据量很小）。”
我也是这么想的，结合hash和维护一个较小的映射表，就能满足速度和扩展的要求了，metadata交给应用系统自己去维护，目前就可以满足需求了，加入memdb或数据库只会使问题复杂化。
其他就是对文件系统进行优化，应对高iops的小文件访问，以及处理备份和热点数据迁移等问题，这些就要通过性能测试结合需求再确定了。
因为文件系统通过tcp提供接入访问，这样的话cache应该做在什么地方？每个文件服务器上做cache还是独立cache服务器，用memcached还是类似的cache系统？或者说目前不考虑cache，等访问并发确实过载时，再做cache方案？
--
wing
wing9...@gmail.com
张沈鹏
> 我不认为一致性哈希能解决减少数据迁移的问题。
>
> 这种哈希只是哈希算法的一个变形而已。其更适合的领域应该是缓存系统、p2p系统等。也就是说是允许丢数据的系统。
> memcache的那个一致性哈希也只是说，如果加入了一台mc的server，client如何尽量少的减少缓存损失的影响而已。
一致性hash的场景是这样的
在磁盘系统中
为了保证数据的可靠性
一个数据存3份(依次的3个节点)
可以添加和移除机器
而添加和移除机器后节点之间可以自动同步
> 试想这和hash%1000出1000个片，存在10台机器上，每台机器上负责100个片，效果是类似的的。扩容的时候，要么成倍扩容，增至20台机
> 器，把每台机器上的片数由100减少至50。要么找个点存储1000个片和20台机器的对应（相当于DNS，这个数据量很小）。
>
> 另外我对TC也有怀疑（不过没有实际用过，只是瞎说）。看TC的代码，也不过是bdb的hash和b+tree。在算法上可以榨出的效率是非常有限
> 的。
> 其给出的测试结果却是比bdb甚至高出两个数量级。单就产生的数据量，直接的磁盘IO可能都达不到那个速度。所以我怀疑于此。
这个是有缓冲的 它的测试的小规模数据
> 除非其用了很大的buffer来缓冲b+tree的node，否则很难达到这么惊人的速度。所以，这一切都是浮云~ ;)。这样可能会带来一个问题就是
> 突然停电的时候丢失的数据会很多。或者在一定时候会集中产生较多的IO。
>
> 另外你用关系型数据库和key-value型数据库进行比较是不科学的，这两个应用领域不同，可比性有限。
?是说我吗?我比较了吗?
> On 4月6日, 上午10时48分, 张沈鹏 <zsp...@gmail.com> wrote:
>> http://www.hypertable.org/about.html
>> 据我所知 还有baidu赞助的这个项目可选
>> 不过这个我并没有实际用过
>>
>> """
>> 如果不通过db或者其他类似查表的方式来定位文件，有什么更好的办法，hash的效率确实很高，但是一旦节点扩展，迁移数据的代价也很大，个人的想法还是通过类 似mogileDFS这样的方式进行架构，虽然可能代码会自行用c来实现，数据库方面可以利用
>> """http://www.kuqin.com/web/20080725/12289.html
>> 可以参考文章中的Consistent Hashing,来减少数据迁移
>>
>> 我们现在的key 采用类似url的方式
>> 比如
>> blog/entry/335/text
>> 这样也可以通过url前缀来制定分布方式
>>
>> 自己写也可以
>> 我们公司在Tokyo Cabinet上写了一个分布式数据库(数据存3份),读性能是mogileFs 2-3倍,写性能是其50倍
> >
>
--
nn hust
nn hust
我不认为当前通用的所谓的分布式存储解决方案能够解决你的问题。
图片服务主要面向的是大量的小文件，而且需要密集的被访问。当前可获得的几乎所有分布式存储方式都不适合这么做。原因如下：
1. KFS、HADOOP，GFS均是对搜索引擎支持的存储解决方案，而非常规意义上的文件系统。其内存的都是以GB论的很大的文件。其设计本身不适
合小文件。就目前而言KFS、HADOOP，GFS等这类仿GoogleFS的作品都是以单个master+多机备份（一般还不是多机服务，只是备份而
已）+日志而存在。考虑到其需要简单实现，其metadata本身就不存在支持大量文件的能力（靠内存+snapshot撑，没有外存访问机制）。图片
的特点是文件小而数量大。诸如GFS面向的文件是，文件大，而数量相对较小。
2. 对大文件来说，(1)访问一次metadata，(2)再访问一次存储节点，(3)之后获得数据，其中(1)和(2)所产生的成本是可以忽略的，
并且可以通过多服务器的吞吐量来提高对大文件的吞吐能力。但就小文件来说，其所产生的查询、吞吐成本是不可忽略的。
3. 图片这种互联网应用，是访问量巨大的。诸如GFS这种存储方式，不能解决该问题。原因为其metadata服务器为单点，服务能力和扩展能力均有
限。试想如果每秒30000 IOPS，metadata server能承受这么大的查询量么？
4. 诸如像FastDFS，其特点是没有文件metadata，由应用去解决，个人认为还不算是一个分布式文件系统。且仍然不能避免上述三点。
5. MogileFS的特点就更有意思，干脆外包了metadata，由MySQL做的metadata。有点太山寨了。我认为就是为了做个所谓的
FS而做的。
不要被Google的paper迷惑了。
值得一提的是，虽然我不认为分布式文件系统不适合互联网级别的在线应用，但是分布式文件系统具有能存储海量数据，扩展性好，HA的特点。我认为非常适合
存近线数据和备份数据。即非访问热点数据。
On Mar 31, 10:25 am, wing <wing922w...@gmail.com> wrote:
> 目前要设计一个分布式的文件服务器，主要存贮图片、文档等小文件，数量巨大且访问并发很高，不知道应该如何选型，考查过大量开源的分布式文件系统，目前主要关注-FastDFS，KFS与gluster，但是资料太少，且这些开源代码都不是特别稳定，用在生产系统比较担心，如果谁有这方面架构经验，希望能够指导一下，除-了使用分布式存储中间件，还有其他什么解决方案，另外在缓存等方面的设计要点，大家能不能交流一下心得，这方面的资料太少，而且文档上的东西流于书面化，希望听-到大家实际的架构经验，毕竟稳定性是第一位的。
esx
熊熊兄
如果能够自己实现存储模型是最好的了，
1。使用hadoop或者kfs来存储这些图片，但是不对外提供服务。这样也就避免了稳定的问题。
2。没段时间建立这些图片的索引，这具体看你对时效性的要求了
3。自己实现取索引的方法，图片一般是用hash。
4。自己实现取索引的方法。
注意实现的“读”索引的时候考虑到分布式就可以。
On Mar 31, 10:25 am, wing <wing922w...@gmail.com> wrote:
> 目前要设计一个分布式的文件服务器，主要存贮图片、文档等小文件，数量巨大且访问并发很高，不知道应该如何选型，考查过大量开源的分布式文件系统，目前主要关注FastDFS，KFS与gluster，但是资料太少，且这些开源代码都不是特别稳定，用在生产系统比较担心，如果谁有这方面架构经验，希望能够指导一下，除了使用分布式存储中间件，还有其他什么解决方案，另外在缓存等方面的设计要点，大家能不能交流一下心得，这方面的资料太少，而且文档上的东西流于书面化，希望听到大家实际的架构经验，毕竟稳定性是第一位的。
raymond
我以前面试一家搜索公司的时候，一个题目是设计MP3服务器提供用户下载，我没有经验，就很简单的说了分布式加缓存，然后对热点数据要重点关注，面试官
说他们的实现中确实大量的利用缓存，而且他们的服务器模型采用倒金字塔型，那就是注意统计各个文件的访问量，对热点数据多备份，这些是金字塔的顶端，每
个文件都在不止一台机器上可以访问，所以无形中相当于增加了并发度，而金字塔低端的是访问量很少的，每个文件可能只有一份拷贝就能满足需求，这样的话，
节省了服务器数量，并且也满足要求。
我觉得他们的方案是过多的关注在现有FS之上如何解决问题（当然，无不知道他们是否更改了FS），考虑的是负载平衡问题，而楼主这里考虑的是FS本身的
问题，是如何让FS自己适应小文件暴多的访问模式。
哦，好像有点跑题了
wing
至于fs的问题，我开始也很受gfs论文的误导，后来受esx指点，才搞清大部并行fs的作用，个人觉得通用的fs不适合做类似的系统。
笔端
MogileFS也可以做小文件的分布存储，不过建议机器做一些划分，划分成不同的域名（二级）
划分后又多个metaserver对应于的多个二级域名
比如img1.xxxx.com ;img2.xxx.com
看豆瓣也是这么做的，因为不是同一个域名，客户的http请求可以用到多个连接
On Apr 1, 10:13 am, wing <wing922w...@gmail.com> wrote:
> 非常感谢esx的回复，经过详细的阅读gfs论文和相关框架说明，得出和你一样的看法，gfs类似的不适合高并发小文件的存储，事实上gfs的论文中也明确说明-了主要对大文件操作，支持小文件但是不做优化，
> 但是目前我还是想不出什么样的架构更为适合，因为我们不是做网站的，对这块不太了解，希望你能再多说一些，另外从网上看到的一个照片网站的架构，后台也使用了M-ogileFS的方式，但对于fastDFS和MogileFS我有和你一样的困惑，这样的metaData管理是有问题的，尤其是MogileFS。
> 也许做过大型网站的，对这种文件系统更了解，你的回答对我帮助很大，能不能说说这种高并发小文件适用的架构，我们内部使用tcp长连接访问，也提供http形式-的接入访问，前者是出于性能的考虑，这样的形式，应该如何架构？能否给出一些建议或者资料，非常感谢！