be sufficient here as well.
Regards,
Thomas
-Original Message-
From: BlueDavy Lin [mailto:blued...@gmail.com]
Sent: Donnerstag, 18. August 2011 04:06
To: user@hbase.apache.org
Subject: Re: GZ better than LZO?
We test gz also,but when we use gz,it seems will cause memory out of usage.
It seems
Ah, sorry. 550 mio. rows and not billions.
Thomas
-Original Message-
From: Steinmaurer Thomas [mailto:thomas.steinmau...@scch.at]
Sent: Donnerstag, 18. August 2011 14:55
To: user@hbase.apache.org
Subject: RE: GZ better than LZO?
After our tests with ~550 bill. rows, we probably will go
Subject: Re: GZ better than LZO?
For what's it worth I had similar observations.
I simulated heavy write load and I found that NO compression was the
fastest, followed by GZ, followed by LZO.
After the tests I did a major_compact of the tables, and I included that time
in the total.
Also
32MB. Does that difference dominate the computational cost of decompression?
Sandy
-Original Message-
From: lars hofhansl [mailto:lhofha...@yahoo.com]
Sent: Friday, July 29, 2011 08:44
To: user@hbase.apache.org
Subject: Re: GZ better than LZO?
For what's it worth I had similar
are currently running a test with ~ 4mio rows following the
pattern above.
Thanks,
Thomas
-Original Message-
From: Chiku [mailto:hakise...@gmail.com]
Sent: Donnerstag, 28. Juli 2011 15:35
To: user@hbase.apache.org
Subject: Re: GZ better than LZO?
Are you getting this results because
: Donnerstag, 28. Juli 2011 19:43
To: user@hbase.apache.org
Subject: Re: GZ better than LZO?
During the load did you add enough data to do a flush or compaction? P,
In our cluster that amount of data inserted would not necessarily be
enough to actually flush store files. Performance really depends on how
thomas.steinmau...@scch.at
To: user@hbase.apache.org
Cc:
Sent: Thursday, July 28, 2011 11:27 PM
Subject: RE: GZ better than LZO?
Hello,
we simulated real looking data (as in our expected production system) in
respect to row-key, column families ...
The test client (TDG) basically implement a three
@hbase.apache.org
Subject: Re: GZ better than LZO?
During the load did you add enough data to do a flush or compaction? P,
In our cluster that amount of data inserted would not necessarily be
enough to actually flush store files. Performance really depends on how
the table's regions are laid out
Are you getting this results because of the nature of test data generated?
Would you mind sharing some details about the test client and the data it
generates?
On Thu, Jul 28, 2011 at 7:01 PM, Steinmaurer Thomas
thomas.steinmau...@scch.at wrote:
Hello,
we ran a test client generating
During the load did you add enough data to do a flush or compaction? P, In our
cluster that amount of data inserted would not necessarily be enough to
actually flush store files. Performance really depends on how the table's
regions are laid out, the insert pattern, the number of regionservers
10 matches
Mail list logo
