2010/9/6 Murali Krishna. P :
> Hi,
> My row size is around 300 bytes with total 20 columns. I tried the custom
> indexing without the write to WAL. Currently having only 2 tables, one for the
> main table and another for all 20 indexes. My key to the index table is
> columnValue+columnName+rowKey
se the key
generation-> cName+ cValue + rowKey. I went for this schema to reduce the
number of tables involved.
Thanks,
Murali Krishna
From: Ted Yu
To: user@hbase.apache.org
Sent: Mon, 6 September, 2010 7:23:22 PM
Subject: Re: HBase secondary index performa
Thanks,
> Murali Krishna
>
>
>
>
>
> From: Andrey Stepachev
> To: user@hbase.apache.org
> Sent: Sun, 5 September, 2010 11:54:45 PM
> Subject: Re: HBase secondary index performance
>
> 2010/9/5 Murali Krishna. P :
> > Hi,
> &
it be better during the initial write
itself (since each table has different region) ??
Thanks,
Murali Krishna
From: Andrey Stepachev
To: user@hbase.apache.org
Sent: Sun, 5 September, 2010 11:54:45 PM
Subject: Re: HBase secondary index performance
2010/9/5 M
non indexed region (disable
indexedtables extension)?
What numbers did you got?
>
> Thanks,
> Murali Krishna
>
>
>
>
>
> From: Andrey Stepachev
> To: user@hbase.apache.org
> Sent: Sun, 5 September, 2010 3:53:26 AM
> Subject: Re
2010/9/5 Samuru Jackson :
> Hi,
>
>> where key will be [value:key] and insert rows every time, when we insert
>> our values. We will got 30k rows/s/node.
>
> Could you specify on what kind of hardware you did this?
3 node "cluster", 16Gb core2duo. sas raid10.
> How did you design your indexer? Is
: Andrey Stepachev
To: user@hbase.apache.org
Sent: Sun, 5 September, 2010 3:53:26 AM
Subject: Re: HBase secondary index performance
2010/9/3 Murali Krishna. P :
>* custom indexing is good, but our data keeps changing every day. So,
>probably
> indextable is the best option for us
Hi,
> where key will be [value:key] and insert rows every time, when we insert
> our values. We will got 30k rows/s/node.
Could you specify on what kind of hardware you did this? How did you
design your indexer? Is it multithreaded?
/SJ
---
http://uncinuscloud.blogspot.com/
2010/9/3 Murali Krishna. P :
> * custom indexing is good, but our data keeps changing every day. So,
> probably
> indextable is the best option for us
In case of custom indexing you can use timestamps to check, that index
record still valid.
(or ever simply recheck existance of the value)
On Fri, Sep 3, 2010 at 7:57 AM, Michael Segel wrote:
>
>
>
> > Date: Fri, 3 Sep 2010 18:00:42 +0530
> > From: muralikpb...@yahoo.com
> > Subject: Re: HBase secondary index performance
> > To: user@hbase.apache.org
> >
> > Thanks Andrey,
>
gets split and when we have lots of
> > data,
> > writes will improve ? (Now it is just writing to one region for the main
> > table)
> >* Is there some way to do bulk load the indexedtable? Earlier I
> have
> > used the
> > bulk loader tool (mapreduce job which c
From: Samuru Jackson
To: user@hbase.apache.org
Sent: Fri, 3 September, 2010 6:24:16 PM
Subject: Re: HBase secondary index performance
Hi,
I wrote my own Indexer and actually I have a pretty good performance.
However, there are still known places where I could gain even more
performance (just not h
> Date: Fri, 3 Sep 2010 18:00:42 +0530
> From: muralikpb...@yahoo.com
> Subject: Re: HBase secondary index performance
> To: user@hbase.apache.org
>
> Thanks Andrey,
>
> * Setting the autoflush to false and increasing the writeBuffer size to
> 12MB
>
___
> From: Andrey Stepachev
> To: user@hbase.apache.org
> Sent: Fri, 3 September, 2010 12:14:29 AM
> Subject: Re: HBase secondary index performance
>
> First, check that you connection not in autoflash mode.
> Second, you can think about custom indexing instead
>
From: Andrey Stepachev
To: user@hbase.apache.org
Sent: Fri, 3 September, 2010 12:14:29 AM
Subject: Re: HBase secondary index performance
First, check that you connection not in autoflash mode.
Second, you can think about custom indexing instead
of using
First, check that you connection not in autoflash mode.
Second, you can think about custom indexing instead
of using indexedtable. In my experience custom idexing
(especially if data doesn't modified), is much more performant.
Problem with indexedtable is in fact, that on every insert
hbase perform
Hi,
I have an indexedtable with index on around 20 columns. The write
performance on the original table is around 60 per second. This is just a one
node setup. Even with mutiple parallel clients, I am getting just 60
writes/second. That means a total write of 60 * 20 = 1200 writes/second due
17 matches
Mail list logo
