[
https://issues.apache.org/jira/browse/HBASE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294131#comment-14294131
]
Lars Hofhansl commented on HBASE-12934:
---------------------------------------
Still a bit skeptical. For the memstore we're writing at least 128mb chunks
(unless HBase is misconfigured and we're writing due to global heap pressure,
or one has too many column families).
SSDs and HDDs have similar throughput (although highend SSDs can be faster
here). The main difference is seek latency, which 0.1ms for SSDs and typically
at least 10ms for HDDs.
So assuming we have about 100mb/s throughput in both cases, we'd take
~1.28s+0.1ms for SSDs vs. ~1.28s+10ms for HDDs, a difference of less than 1%.
Flushes are also asynchronous (same as compactions).
The main advantage is (1) for random reads where the working set does not fit
into the aggregate cache and (2) the WAL writes *if* we're actually sync'ing
the WAL to disk.
My statement would change if SSDs have typically higher write throughput
compared to HDDs. Do they?
And even than, why limit this flushes then? Both flushes and compactions are
asynchronous.
> Utilize Flash storage for flushing
> ----------------------------------
>
> Key: HBASE-12934
> URL: https://issues.apache.org/jira/browse/HBASE-12934
> Project: HBase
> Issue Type: Sub-task
> Reporter: Ted Yu
> Assignee: Ted Yu
> Attachments: 12934-001.txt
>
>
> Store flushing should be able to make use of hdfs storage policy.
> One option is to allow setting storage policy for the directory path of the
> specified column family.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
