大规模数据处理漫谈【2】

 

   上回说到了磁盘的一些特性，感觉不说说文件不太妥。以及对比文件系统和raw device的优劣。

   在目前的各种文件系统中，JFS是一种比较适合大规模数据处理的文件系统，但常用的依然是ext2,ext3. 不同的文件系统受到特定业务的影响在保持通用的前提下，各有侧重，下面谈谈主要优化需要考虑的问题：

   文件系统都要求整块读写磁盘的，按照block size = 4K为例，如果需要在一个块上写1K数据，则首先需要从磁盘将这个块读入内存，在内存中写入1K数据（看做是合并块中其他数据），再回写磁盘。显然如果写的是4K数据，且恰好是写在一个块上的，则系统就免去读入内存和合并的开销，因此我们一般一次写入尽可能多，例如写入10K，则有可能是前两个是整块写，而后一个是半块写，半块写的额外代价摊下来就不显的很多。
 
   由于寻道时间是磁盘访问代价中最大的一块，而且道次跳得越大代价越高，因此我们希望文件所包含的块（fileplace命令查看）尽可能连续，而文件系统也是这么做得，但遗憾的是无论怎样，文件也会向不连续的方向发展，特别是系统中各种文件大量创建，追加，删除后。因此在磁盘长期使用后，明明文件是顺序读写，但实际上已经是随机读写。这叫做文件碎片。

   如果事先知道结果文件的大小预分配是很好的选择，怎样快速创建一个大文件呢？
   这里有个快速的方法：
   int fd = open("./file", O_RDWR|O_CREAT|O_TRUNC,00777);
   off64_t set = 5*G;
   lseek64(fd,set,SEEK_SET);
   write(fd,"/0",1);
   然而遗憾的是，这样的做法分配的是一个空洞文件（稀疏文件），这个貌似5G的文件大小其实并没有申请到真正的磁盘块，只有在实际写入的时候才会分配，BDB的临时文件db00x就是这么创建出来的，这也是BDB慢的一个重要原因。
   怎么快速创建一个真正的大文件呢？我留一个问题，请大家回答。
   另外附带的一个问题是，为什么写磁盘比读磁盘要慢，慢在哪里，如果去掉这一部分是否可以加快写的速度？
  
   文件系统无论如何也很难满足业务上的需要，大部分情况下需要直接处理raw device。或者说自己按照业务需要对裸设备进行格式化，创建自己的特定读写系统。
   比如这样一个场景，需要对每一天的数据(key,value pair)写入raw device, key都是定长而value大小各异。如果把key，data 看做二维，看成如下矩形:
  
   date(近 ---------------------------->远)
   -------------------------------------------
key|  A |  B
   |----|---------------------------------C
   |    |
   |    |
   -------------------------------------------
   不难理解越近的日期访问频率越高(A区访问的概率远大约B区，A区为热区），而某些key会在一个长的日期范围内长期使用(线C是访问热点，叫做热线吧）。

   首先我们系统数据按照日期的顺序进行存放，条件允许的话，越近日期的数据放在距离raw device 零位置越近的区域，数据在顺序读写时均不会出现跃2个磁道以上的情况。在业务上这种顺序读写是显然的，大量的，数据按天生产，按天处理写入，使用（读）也多为按天处理。随机读写也多发生于A区，A区所占的道次比较有限，因此跳跃的道次也一般较少。不跳的概率较高。C线也很有趣，比如顺序读取某个key，全部天数的数据，则无论由近读到远或者由远读到近，道次都好像电梯一样升降，不会来回跑，因此开销也是很小的，当然与A区相比，想尽可能不跳只转是不可能的了。

   但如何解决value大小各异的问题呢？外部需要哪些索引呢？raw device怎么copy呢，怎么备份呢？在容量不够时如何扩展呢？在享受了raw device的好处后，还需要解决很多这些细节的问题，需要在实际的环境中更多实践。

 

 

 

讨论参见：http://www.newsmth.net/bbscon.php?bid=715&id=14744