半道出家的和尚

题记：google 的成功除了一个个出色的创意外，还因为有 Jeff Dean 这样的软件架构天才。                                                  ------ 编者 官方的 Google Reader blog 中有对BigTable 的解释。这是Google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如 R

最适合使用Hbase存储的数据是非常稀疏的数据（非结构化或者半结构化的数据）。Hbase之所以擅长存储这类数据，是因为Hbase是column-oriented列导向的存储机制，而我们熟知的RDBMS都是row- oriented行导向的存储机制（郁闷的是我看过N本关于关系数据库的介绍从来没有提到过row- oriented行导向存储这个概念）。在列导向的存储机制下对于Null值得存储是不占用任何

 测试hbase和hadoop操作文件的性能1:单线程hbase的文件存入        String parentPath = "F:/pic/2003-zhujiajian";        File[] files = getAllFilePath(parentPath);                HBaseConfiguration config = new HBaseConfi

 GFS(Google File System): http://www.codechina.org/doc/google/gfs-paper/MogileFS: http://www.danga.com/mogilefsHadoop/HDFS: http://hadoop.apache.org/coreKFS(Kosmos Distributed File System): ht

  学习hadoop也有一段时间了,在测试了多天,分析了多天,其实对其内部实现还是不是很了解.源代码不是很好看哦.  今天yahoo的一个hadoop的专家过来介绍了一下,yahoo的使用经验,普遍讲的是mapreduce这块内容.而hdfs这块涉及不多.在hadoop的archetcture里也提到hadoop不适合存储小文件.它本身就是从nutch项目里分出来的,目的是存放大文件.

最近看了一下 Kosmos File System (KFS), 目前的版是 0.2.1 。现在总结一下。 KFS 是一个克隆 GFS 的文件系统，用 C++ 编写，客户端支持 C++,pyton 和 JAVA 。主要也是用来存储大文件的，其中的 chunk 相当于 Hadoop 中的 block ，每个 chunk 都为 64M. 一、编译 从 SourceForge 上下载的源代码之后

Web2.0网站，数据内容以几何级数增长，尤其是那些小文件，几K～几百K不等，数量巨多，传统的文件系统处理起来很是吃力，很多网站在scaling的过程中都遇到了这样的问题：磁盘IO过高；备份困难；单点问题，容量和读写无法水平扩展，还存在故障的可能。YouTube也碰到这样的问题，每一个视频有4个缩微图，这样的话缩微图数量是视频数量的四倍，想象一下YouTube有多少视频，看一下他们遇到的问题：

    distributed key-value store是当下比较流行的话题，尤其在构建诸如搜索引擎、IM、P2P、游戏服务器、SNS等大型互联网应用以及提供云计算服务的时候，怎样保证系统在海量数据环境下的高性能、高可靠性、高扩展性、高可用性、低成本成为所有系统架构们挖苦心思考虑的重点，而怎样解决数据库服务器的性能瓶颈是最大的挑战。    按照分布式领域的CAP理论（Cons