大数据存储

曾经负责过一款底层存储系统的测试工作，最近看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的负载压力，另一方面就是提高效率！