hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars George <lars.geo...@gmail.com>
Subject Re: HBase tuning - minimise table read latency
Date Fri, 14 Jan 2011 10:17:02 GMT
Hi Joel,

Marking it "in-memory" is *not* making it all stay or be loaded into
memory. It is just a priority flag to retain blocks of that CF
preferably in the block caches. So it caches it up to the max block
cache size. The rest may cause some churn but that is the best you can
do.

Lars

On Tue, Jan 11, 2011 at 9:30 AM, Joel Halbert <joel@su3analytics.com> wrote:
> No, the second table is too large to fit in memory.
>
>
> On Mon, 2011-01-10 at 11:26 -0800, Stack wrote:
>> Mark the second-table in-memory in the schema.  And for the first,
>> have it not use cache at all.  This way, cache should only have
>> content from the table that is read.  Does the second table fit fully
>> in memory?
>>
>> St.Ack
>>
>> On Mon, Jan 10, 2011 at 2:00 AM, Joel Halbert <joel@su3analytics.com> wrote:
>> > Hi All,
>> >
>> > I have an application with two HBase tables.
>> >
>> > One table is written to frequently, by a crawler writing web pages.
>> >
>> > Another table is written to occasionally (the result of some
>> > processing), but end users read data from this table, and I want the
>> > read response times to be as low as possible.
>> >
>> > I only have one server on which to host both tables.
>> >
>> > What tuning should I consider to minimise the read latency on the second
>> > table (there will be relatively few users, so throughput is less of a
>> > concern, for the time being) ?
>> >
>> >
>> > Regards,
>> > Joel
>> >
>> >
>> >
>> >
>> >
>
>
>

Mime
View raw message