Search code examples
file-iofilesystemshadoopdistributed-systemgfs

Why doesn't Hadoop file system support random I/O?


The distributed file systems which like Google File System and Hadoop doesn't support random I/O.
(It can't modify the file which were written before. Only writing and appending is possible.)

Why did they design file system like this?
What are the important advantages of the design?

P.S I know Hadoop will support modifing the data which were written.
But they said, it's performance will very not good. Why?


Solution

  • Hadoop distributes and replicates files. Since the files are replicated, any write operation is going to have to find each replicated section across the network and update the file. This will heavily increase the time for the operation. Updating the file could push it over the block size and require the file split into 2 blocks, and then replicating the 2nd block. I don't know the internals and when/how it would split a block... but it's a potential complication.

    What if the job failed or got killed which already did an update and gets re-run? It could update the file multiple times.

    The advantage of not updating files in a distributed system is that you don't know who else is using the file when you update it, you don't know where the pieces are stored. There are potential time outs (node with the block is unresponsive) so you might end up with mismatched data (again, I don't know the internals of hadoop and an update with a node down might be handled, just something I'm brainstorming)

    There are a lot of potential issues (a few laid out above) with updating files on the HDFS. None of them are insurmountable, but they will require a performance hit to check and account for.

    Since the HDFS's main purpose is to store data for use in mapreduce, row level update isn't that important at this stage.