Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: unknown ~allmx (nike.apache.org: encountered unrecognized
 mechanism during SPF processing of domain of janvb@ngdata.com)
Message-ID: <50BE4DD9.3030409@ngdata.com>
Date: Tue, 04 Dec 2012 20:24:09 +0100
From: Jan Van Besien <janvb@ngdata.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: dev@hbase.apache.org
Subject: Re: HBase - Secondary Index
References: 
 <0CE69E9126D0344088798A3B7F7F80863AEA0620@SZXEML553-MBX.china.huawei.com>
In-Reply-To: 
 <0CE69E9126D0344088798A3B7F7F80863AEA0620@SZXEML553-MBX.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 12/04/2012 09:10 AM, Anoop Sam John wrote:
 > I would like to hear what others think on this. :)

I found it interesting to read your approach on how the indexes can be 
used to speed up existing scan operations.

I couldn't find anything in your presentation though about whether your 
implementation makes any guarantees to ensure the source table and the 
index table are always (eventually) in sync.

What if data is inserted in the source table and then the region server 
crashes (before the coprocessor is executed)? Will the index be out of 
sync? Do you have a mechanisme in place to detect and restore this 
situation?

thanks
Jan