[
https://issues.apache.org/jira/browse/HBASE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433581#comment-13433581
]
Andrew Purtell commented on HBASE-6572:
---------------------------------------
HDFS-3672 could be viewed as the beginnings of an API for device aware block
placement (the query side).
If:
* HDFS had an API for querying the nature of its underlying storage volumes
* That API can distinguish solid state from spinning media
* HDFS also adds an API for specifying block placement according to the storage
volume type, perhaps as a new argument to {{FileSystem#create}}.
then the above would allow us to rewrite, probably through compaction, HFiles
from one media type to another.
If additionally parts of the namespace can be tagged with storage device
affinity, perhaps by setting an attribute on a directory, then file blocks
could be migrated in the background via {{FileSystem#rename()}} as a natural
part of replication: If a DataNode reports block X on media type Y but the path
prefers type Z, then the NameNode should figure out how to move the block if
possible.
> Tiered HFile storage
> --------------------
>
> Key: HBASE-6572
> URL: https://issues.apache.org/jira/browse/HBASE-6572
> Project: HBase
> Issue Type: New Feature
> Reporter: Andrew Purtell
>
> Consider how we might enable tiered HFile storage. If HDFS has the
> capability, we could create certain files on solid state devices where they
> might be frequently accessed, especially for random reads; and others (and by
> default) on spinning media as before. We could support the move of frequently
> read HFiles from spinning media to solid state. We already have CF statistics
> for this, would only need to add requisite admin interface; could even
> consider an autotiering option.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
