Todd,
Can you define what a Locality Group is for HBase and how it would
function? Eg, it sounds like the same thing as a column-family, and
it's not clear how one would benefit from the usage of an LG.
Jason
On Mon, Jun 13, 2011 at 8:45 PM, Todd Lipcon t...@cloudera.com wrote:
Keep in mind
If they have divergent read and write patterns why not put them in separate
tables?
That's an entirely fair question. I'm new to this. I figured if the data
was related to the same thing and could have the same key, then it ought to
go into various CFs on that key in a single table. I got
That's an entirely fair question. I'm new to this. I figured if the data
was related to the same thing and could have the same key, then it ought to
go into various CFs on that key in a single table. I got the feeling from
reading the BigTable paper that the typical design approach was to
Re: keyed by something like [timestamp, action details, session ID]
Read the part about monotonically increasing keys in the HBase book. There
have been lots of other threads in the dist-list about this topic too.
-Original Message-
From: Leif Wickland
Read the part about monotonically increasing keys in the HBase book. There
have been lots of other threads in the dist-list about this topic too.
Thanks for mentioning that, Doug. I did see that in the HBase book.
My wording was poor. I meant that the column names would be derived from
Table 2 provides some actual CF/table numbers. One of the crawl tables has
16 CFs and one of the Google Base tables had 29 CFs
What's Google doing in BigTable that enables so many CFs?
Is the cost in HBase the seek to each individual key in the CFs, or is
it the cost of loading each block
Re: monotonically increasing column names.
No problem with that.
-Original Message-
From: Leif Wickland [mailto:leifwickl...@gmail.com]
Sent: Monday, June 13, 2011 5:29 PM
To: user@hbase.apache.org
Subject: Re: Question from HBase book: HBase currently does not do well with
If they have divergent read and write patterns why not put them in separate
tables?
~Jeff
On 6/2/2011 4:06 PM, Doug Meil wrote:
Re: Is that still considered current? Do folks on the list generally agree with
that guideline?
Yes and yes. HBase runs better with fewer CFs.
-Original
On Thu, Jun 2, 2011 at 2:40 PM, Leif Wickland leifwickl...@gmail.com wrote:
Do you think I should look for ways to reduce the number of CFs?
If you can, yes (The book is current -- the work on making hbase do
better with more CFs is yet to be done).
Good luck,
St.Ack
Is there a JIRA for issuing flushes and compactions on a per column family
basis?
On 6/2/11 2:48 PM, Stack st...@duboce.net wrote:
On Thu, Jun 2, 2011 at 2:40 PM, Leif Wickland leifwickl...@gmail.com wrote:
Do you think I should look for ways to reduce the number of CFs?
If you can, yes
https://issues.apache.org/jira/browse/HBASE-3149 for flushes, not sure
about compactions.
J-D
On Thu, Jun 2, 2011 at 2:57 PM, Vidhyashankar Venkataraman
vidhy...@yahoo-inc.com wrote:
Is there a JIRA for issuing flushes and compactions on a per column family
basis?
On 6/2/11 2:48 PM, Stack
Re: Is that still considered current? Do folks on the list generally agree
with that guideline?
Yes and yes. HBase runs better with fewer CFs.
-Original Message-
From: Leif Wickland [mailto:leifwickl...@gmail.com]
Sent: Thursday, June 02, 2011 5:41 PM
To: user@hbase.apache.org
12 matches
Mail list logo
