大数据存储

曾经负责过一款底层存储系统的测试工作,最近看hdfs的文章发现,从架构上真心没啥特别大的区别。组成如下:
zookeeper:节点注册、选主
name node:元数据存储
data node:block数据存储
备份:3?
区别:
hdsf更多的与其他的计算框架如Mapreduce进行配合使用,也就是大数据存储+大数据计算。而我送负责的底层存储系统更多的是面上中、小文件,如视频、图片、文件等,显然如果直接用hdfs去干这类事情,首先有点大材小用,因为文件本身不是特别大,如果block最大值设置的太大,很多文件其实也就是存一个block,这个分块存储可能没啥太大意义,文件似乎变得很容易损坏!。如果block最大值设置的太小,本身就不大的文件,又被打的支离破碎。因为我测的那个系统,其实主要用于数据的云备份和数据的恢复,打的太散反而性能不咋地。
当然以上说的问题,难道自己写个文件存储系统就不会碰到吗?当然会碰到。以下是我个人的分析:
hdfs的文件系统,其实就是一个大目录结构,在面对海量的数据时候,这个目录很难去定义,怎么明明算合适,毕竟是海量的用户的备份数据。
hdfs我理解原声其实没有类似LRU这种的缓存优化,我测的系统我记得是又一定的缓存优化,这样针对热点的数据,性能会好点。
定制性需求,其实拿开源社区的hdfs过来用,然后持续的做定制化的例子不少,但是真的很累,费力不讨好,能自己写点东西,why not不写呢?
速度,因为这个系统上游可能对接的我们的大客户,也可能是S3公有云存储,这类的文件服务很重要的一点就是快,虽然没有进行实测,但是据我了解,hdfs对于这种小文件的单纯的读写操作,速度应该不是特别出众,要是真用hdfs,这些产品可就玩完了~
我个人对hdfs的理解,我认为要从类似MapReduce这样的计算框架理解,MapReduce是一个移动计算而不是移动数据的框架,从这一点上来说hdfs从设计的出众上,应该就不是为了移动数据而生,个人理解,如果理解的不对,待我后续对hdfs了解的更深入再行补充、修正。
这里补充以下,我所测的文件存储系统,对于客户端又一个很不错的优化,就是索引缓存,这里的文件的读写的客户端是比较重的,其进行操作的过程中,会将文件的索引信息进行缓存,这样很多时候可以绕过name node,直接与data node进行通信,一方面减轻了name node的负载压力,另一方面就是提高效率!

你可能感兴趣的:(大数据存储)