| « | September 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | |
|
公告 |
| 暂无公告... |
| Blog信息 |
|
blog名称:
日志总数:32
评论数量:9
留言数量:-1
访问次数:111276
建立时间:2008年12月3日 |
| |
|
 大规模数据处理漫谈【2】
软件技术
liangbin 发表于 2009/6/11 9:59:56 |
| 上回说到了磁盘的一些特性，感觉不说说文件不太妥。以及对比文件系统和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
|
|
|