Bill
You have done it again :). Jonathan is the man you need to contact for this
or as I advised the mailing list is the best. But don't sign off as me. This
is the Nth time :).
Avinash
On Tue, Aug 2, 2011 at 8:17 PM, Bill Hastings wrote:
> Is this part of trunk and used? I see the code for Me
FB Inbox Search still runs on Cassandra and will continue to do so. I should
know since I maintain it :).
Cheers
Avinash
On Tue, Jul 6, 2010 at 3:34 AM, David Strauss wrote:
> On 2010-07-05 15:40, Eric Evans wrote:
> > On Sun, 2010-07-04 at 13:14 +0100, Bill de hÓra wrote:
> >> This person's und
at the time?
>
> On Tuesday, May 4, 2010, Avinash Lakshman
> wrote:
> > Hahaha, Jeff - I remember scampering to remove those references to the
> Trove maps, I think around 2 years ago.
> > Avinash
> >
> > On Tue, May 4, 2010 at 2:34 AM, Jeff Hammerbacher
> wrot
Hahaha, Jeff - I remember scampering to remove those references to the Trove
maps, I think around 2 years ago.
Avinash
On Tue, May 4, 2010 at 2:34 AM, Jeff Hammerbacher wrote:
> Hey,
>
> History repeating itself a bit, here: one delay in getting Cassandra into
> the open source world was removin
I think the GPL license of Trove prevents us from using it in Cassadra. But
yes for all its maps it uses Open Addressing which is much more memory
efficient than linear chaining that is employed in the JDK.
Avinash
On Fri, Apr 23, 2010 at 1:22 PM, Carlos Sanchez <
carlos.sanc...@riskmetrics.com>
Those memtable thresholds also need looking into. You are using some real
poor hardware configuration - 1.7 GB RAM is not a configuration worth
experimenting with IMO. Typical production deployments are running 16 GB RAM
and quad core 64 bit machines. Its hard I would presume to make any
recommenda
OPP is not required here. You would be better off using a Random partitioner
because you want to get a random distribution of the metadata.
Avinash
On Wed, Apr 14, 2010 at 7:25 PM, Avinash Lakshman <
avinash.laksh...@gmail.com> wrote:
> Exactly. You can split a file into blocks of any
Exactly. You can split a file into blocks of any size and you can actually
distribute the metadata across a large set of machines. You wouldn't have
the issue of having small files in this approach. The issue maybe the
eventual consistency - not sure that is a paradigm that would be acceptable
for
How large are the values? How much data on disk?
On Wednesday, April 14, 2010, James Golick wrote:
> Just for the record, I am able to repeat this locally.
> I'm seeing around 150ms to read 1000 columns from a row that has 3000 in it.
> If I enable the rowcache, that goes down to about 90ms. Acc
rst read of the row.
>
> On 2010-04-08 16:36, Mark Greene wrote:
> > So unless you re-try the write, the previous stale write stays on the
> > other two nodes? Would a read repair fix this eventually?
> >
> > On Thu, Apr 8, 2010 at 11:36 AM, Avinash Lakshman
>
What your describing is a distributed transaction? Generally strong
consistency is always associated with doing transactional writes where you
never see the results of a failed write on a subsequent read no matter what
happens. Cassandra has no notion of rollback. That is why no combination
will gi
The tooth wave in memory utilization could be memtable dumps. I/O wait in
TCP happens when you are overwhelming the server with requests. Could you
run sar and find out how many bytes/sec you are receiving/transmitting?
Cheers
Avinash
On Thu, Apr 8, 2010 at 7:45 AM, Mark Jones wrote:
> I don't
We use anywhere from 3-5 seeds for clusters that have over 150 nodes. That
should suffice for larger sizes too since they are only for initial
discovery.
Avinash
On Sat, Apr 3, 2010 at 9:19 AM, Benjamin Black wrote:
> Seeds are used for ring discovery, so there really isn't a load
> concern for
How far apart are the data centers? Technically there will be an increase in
latency for the writes if you are waiting for acks from the replicas. How
long does it for simple pings between machines in these data centers? If
inconsistency is not an issue you can mitigate this by doing asynchronous
r
We use ZK for some incrementing counters and this is method that does it
(this is wrapped in a Thrift call) :
public long getNextSequenceId()
{
Stat stat = null;
String path = "//" + "/SequenceId";
try
{
stat = zk_.setData( path , new byte[0] , -1);
}
I think Open PGM uses IP mulitcast and this is not available in all data
centers. For instance inside FB mulicast across racks is disabled for a
multitude of reasons. However using TCP should not be a major concern as
long as some discipline is in place w.r.t how size of packets are restricted
as y
have blob as large as 50mb compressed (XML compresses quite well).
> Typical documents we would deal with would be between 500K and 3MB
>
> Carlos
>
>
> ________
> From: Avinash Lakshman [avinash.laksh...@gmail.com]
> Sent: Wednesday,
My question would be how large is large? Perhaps you could compress the
blobs and then store them. But it depends on the answer to the first
question.
Cheers
Avinash
On Wed, Mar 17, 2010 at 5:10 PM, Carlos Sanchez <
carlos.sanc...@riskmetrics.com> wrote:
> Has anyone had experience storing large
19 matches
Mail list logo
