Hey Maxim,
Very cool stuff, and J-D definitely hit the high notes.. For a cluster
that's going to do real work, unless you're sold on AWS for all of your
infrastructure, I'd definitely recommend real hardware from a vendor like
Supermicro or moving to a "bare metal" cloud environment like SoftLaye
Hey Luke,
A couple comments inline below:
On Tue, Aug 3, 2010 at 8:40 AM, Luke Forehand <
luke.foreh...@networkedinsights.com> wrote:
> Thanks to the help of people on this mailing list and Cloudera, our team
> has
> managed to get our 3 data node cluster with HBase running like a top. Our
> im
Sorry took a day to answer, see inline.
J-D
On Mon, Aug 2, 2010 at 10:47 AM, Maxim Veksler wrote:
> Hello,
>
> We're setting up a data warehouse environment that includes Hadoop, HBase,
> Hive and our own in-house MR jobs.
> I would like with your permission to discuss the architecture we should
Inline.
J-D
On Tue, Aug 3, 2010 at 2:44 PM, Vidhyashankar Venkataraman
wrote:
> A few issues I have been observing on changing block settings:
>
> 1. What happens if we change the block size of a column family on an
> already populated database? Will this not throw apps on db out of whack
>
On a small cluster like that I wouldn't bother giving 3 machines to
zookeeper since your cluster is a reliable as your master node.
Instead, make sure that your master has some redundant hardware and
put a standalone zookeeper on it.
J-D
On Tue, Aug 3, 2010 at 3:41 PM, Justin Cohen wrote:
> I ha
I have an hbase setup with 1 master, 3 zookeepers and 10 region servers
in distributed mode. What kind of stability should I expect? I can
lose 1 zookeper, right? What happens if I lose 2? What if a region
server goes down, or if the master goes down?
thanks,
-justin
A few issues I have been observing on changing block settings:
1. What happens if we change the block size of a column family on an already
populated database? Will this not throw apps on db out of whack because of
compression and Hfile index which depend on block size? So, once the db is
po
Hegner, Travis writes:
>
> Going out on a limb, I think it will perform MUCH faster with multiple copies,
as the data is already sitting
> in each mappers memory, ready to be accessed locally. The time to process per
mapper should be very
> dramatically reduced. With that in mind, you only have
Going out on a limb, I think it will perform MUCH faster with multiple copies,
as the data is already sitting in each mappers memory, ready to be accessed
locally. The time to process per mapper should be very dramatically reduced.
With that in mind, you only have to scale up as disk space requi
We'll know for sure when we see those stack traces (both master and DNs).
J-D
On Tue, Aug 3, 2010 at 6:22 AM, Jamie Cockrill wrote:
> Hi JD,
>
> The cluster is on a separated network, I'll see if any of the traces
> remain. As for the ulimit and xceivers bit, those are setup correctly
> as per t
Edward Capriolo writes:
> Generally speaking: If you are doing full range scans of a table
> indexes will not help. Adding indexes will make the performance worse,
> it will take longer to load your data and now fetching the data will
> involve two lookups instead of one.
>
> If you are doing fu
On Tue, Aug 3, 2010 at 11:40 AM, Luke Forehand
wrote:
> Thanks to the help of people on this mailing list and Cloudera, our team has
> managed to get our 3 data node cluster with HBase running like a top. Our
> import rate is now around 3 GB per job which takes about 10 minutes. This is
> great.
Thanks to the help of people on this mailing list and Cloudera, our team has
managed to get our 3 data node cluster with HBase running like a top. Our
import rate is now around 3 GB per job which takes about 10 minutes. This is
great. Now we are trying to tackle reading.
With our current setup,
PS, yes that was coming from master
On 3 August 2010 14:22, Jamie Cockrill wrote:
> Hi JD,
>
> The cluster is on a separated network, I'll see if any of the traces
> remain. As for the ulimit and xceivers bit, those are setup correctly
> as per the API doc you mention.
>
> Thanks
>
> Jamie
>
> On
Hi JD,
The cluster is on a separated network, I'll see if any of the traces
remain. As for the ulimit and xceivers bit, those are setup correctly
as per the API doc you mention.
Thanks
Jamie
On 2 August 2010 19:18, Jean-Daniel Cryans wrote:
> Is that coming from the master? If so, it means tha
Thanks, confirmed.
See https://issues.apache.org/jira/browse/HBASE-2897 and
https://review.hbase.org/r/482/
- Andy
> From: Sasha Maksimenko
> Subject: Re: [stargate] transaction?
> To: user@hbase.apache.org
> Date: Monday, August 2, 2010, 2:32 AM
> same error in hbase 0.20.6
>
> On Mon,
16 matches
Mail list logo