Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D627617B19 for ; Wed, 28 Jan 2015 02:08:35 +0000 (UTC) Received: (qmail 92331 invoked by uid 500); 28 Jan 2015 02:08:36 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 92286 invoked by uid 500); 28 Jan 2015 02:08:36 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 92274 invoked by uid 99); 28 Jan 2015 02:08:36 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jan 2015 02:08:36 +0000 Date: Wed, 28 Jan 2015 02:08:36 +0000 (UTC) From: "Lars Hofhansl (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-12934) Utilize Flash storage for flushing MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294592#comment-14294592 ] Lars Hofhansl commented on HBASE-12934: --------------------------------------- SSD wear is well documented. I am not sure it is an issue specifically, just a concern to rule out. Would definitely use SSDs only for data that mostly read, especially with LSM trees. The title of this jira is about utilizing flash for flushing. It only does flushes, and when enabled does all flushes to SSDs. That just makes no sense to me. Why would I want to place all HFiles resulting from flushes on SSDs across the board? I can't think of a single use case where this is useful. It's the wrong way to slice this problem. Flushes are asynchronous, they only become a problem when we reach the number of the blocking store files, which is a problem of *compactions* not being able to keep, not flushes. Now... If you slice it the other way and say "all files written on behalf of this column family are written to SSD", then we have a story. And that would *not* be about improving writes but about *reads*. In that case you write all flushes and compaction of a specific column families to SSDs. This jira is not doing that, nor does it provide a path to get there. > 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)