Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # user >> Timestamp as a key good practice?


+
Jean-Marc Spaggiari 2012-06-13, 16:16
+
Otis Gospodnetic 2012-06-14, 06:06
+
Jean-Marc Spaggiari 2012-06-14, 10:39
+
Michael Segel 2012-06-14, 11:55
+
Jean-Marc Spaggiari 2012-06-14, 12:22
+
Michael Segel 2012-06-14, 18:14
+
Jean-Marc Spaggiari 2012-06-14, 18:47
+
Michael Segel 2012-06-14, 19:46
+
Michael Segel 2012-06-15, 14:21
+
Jean-Marc Spaggiari 2012-06-16, 11:22
+
Michel Segel 2012-06-16, 14:35
+
Jean-Marc Spaggiari 2012-06-16, 14:42
+
Michael Segel 2012-06-16, 16:33
+
Rob Verkuylen 2012-06-16, 19:10
+
Jean-Marc Spaggiari 2012-06-21, 11:43
+
Michael Segel 2012-06-21, 14:20
+
Jean-Marc Spaggiari 2012-06-22, 19:43
+
Jean-Marc Spaggiari 2012-06-23, 02:20
+
Jean-Daniel Cryans 2012-06-26, 17:50
+
Jean-Marc Spaggiari 2012-06-26, 17:56
+
Jean-Daniel Cryans 2012-06-26, 18:12
Copy link to this message
-
Re: Timestamp as a key good practice?
> Network is always good to check, it's all fun and games until an
> interface negotiates 100Mb.
>
> 50ms per get sounds a bit extreme.
<mini-rant>
Funny you should mention hardware.
I did submit a talk on cluster design to Strata (NY and London) Seems it didn't make the cut on NY, but who knows about London...

It seems that people are now starting to get the idea that its important to think about your hardware and cluster design before you actually start to build a cluster.
</mini-rant>

You're right we don't know enough about the hardware and configuration to talk intelligently...

Depending on the size of the row... it could cause a long time to do a single fetch. (err get() )

On Jun 26, 2012, at 1:12 PM, Jean-Daniel Cryans wrote:

> On Tue, Jun 26, 2012 at 10:56 AM, Jean-Marc Spaggiari
> <[EMAIL PROTECTED]> wrote:
>> Am I better to run it on 1? Or on 3? I just want to do some testing
>> for now. but for ZK, can I keep it in only one server for now? Or it will be
>> more efficient if  Iconfigure it on 3?
>
> FWIW your system will be as available is PC1 is, so just put 1 ZK on
> that node. ZK is not on the read path so whether you have 1 or 10 it
> won't change anything.
>
>> But I have issues with the performances. It's taking 20
>> seconds to do 1000 gets with the actual configuration... I'm tracking
>> the issues. I think the network is one so I will address it this week,
>>
>
> Network is always good to check, it's all fun and games until an
> interface negotiates 100Mb.
>
> 50ms per get sounds a bit extreme.
>
>>
>> Thanks,
>>
>> JM
>>
>> 2012/6/26, Jean-Daniel Cryans <[EMAIL PROTECTED]>:
>>> A quorum with 2 members is worse than 1 so don't put a ZK on PC2, the
>>> exception you are seeing is that ZK is trying to get a quorum on with
>>> 1 machine but that doesn't make sense so instead it should revert to a
>>> standalone server and still work.
>>>
>>> J-D
>
+
Jean-Marc Spaggiari 2012-06-26, 19:04
+
Doug Meil 2012-06-14, 21:18
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB