Thanx Joe. Great stuff and very encouraging.
Lenin
Sent from my BlackBerry® wireless handheld
-Original Message-
From: Joe Stump
Date: Sat, 20 Mar 2010 09:27:21
To:
Subject: Re: Startup issue when big data in.
On Mar 20, 2010, at 3:33 AM, Lenin Gali wrote:
> 1.what kind
On Mar 20, 2010, at 3:33 AM, Lenin Gali wrote:
> 1.what kind of performance are you getting, how many writes vs reads do you
> do per min?
Our performance is quite good. Here are some HDD benchmarks I've ran:
http://stu.mp/2009/12/disk-io-and-throughput-benchmarks-on-amazons-ec2.html
> 2. have
perham.com/2010/03/13/cassandra-internals-writing/
>
> Thanks,
> Stu
>
> -Original Message-
> From: "Tatu Saloranta"
> Sent: Friday, March 19, 2010 1:17pm
> To: user@cassandra.apache.org
> Subject: Re: Startup issue when big data in.
>
> On Fri,
On Fri, Mar 19, 2010 at 11:25 AM, Stu Hood wrote:
> All write patterns should provide the same performance with Cassandra, since
> all writes to disk occur sequentially.
Ok that makes sense.
> The only variance might be in the data structure used for the Memtable (a
> concurrent skip list), bu
/cassandra-internals-writing/
Thanks,
Stu
-Original Message-
From: "Tatu Saloranta"
Sent: Friday, March 19, 2010 1:17pm
To: user@cassandra.apache.org
Subject: Re: Startup issue when big data in.
On Fri, Mar 19, 2010 at 10:56 AM, Jonathan Ellis wrote:
> On Fri, Mar 19, 201
On Fri, Mar 19, 2010 at 10:56 AM, Jonathan Ellis wrote:
> On Fri, Mar 19, 2010 at 12:52 PM, Tatu Saloranta wrote:
>> One sort of related question: given that order of insertions has huge
>> effects on some stores, like BDB (where inserting in key order is 10x
>> faster than arbitrary order), woul
On Fri, Mar 19, 2010 at 12:52 PM, Tatu Saloranta wrote:
> One sort of related question: given that order of insertions has huge
> effects on some stores, like BDB (where inserting in key order is 10x
> faster than arbitrary order), would insertion order possibly have
> significant effect on Cassan
On Fri, Mar 19, 2010 at 7:40 AM, Marcin wrote:
> Hi guys,
>
> is there a way to avoid compacting, flushing and all of this thing on
> startup and perform it while node is running ?
>
> It takes a lot of on startup.
One sort of related question: given that order of insertions has huge
effects on s
Probably that was the reason of course ;-)
thanks for pointing it out.
cheers,
/Marcin
You have to wait for the flush to finish, of course.
On Fri, Mar 19, 2010 at 11:44 AM, Marcin wrote:
I have done that before plus compact and it didn't help? (I have been using
nodeprobe)
cheers,
You have to wait for the flush to finish, of course.
On Fri, Mar 19, 2010 at 11:44 AM, Marcin wrote:
> I have done that before plus compact and it didn't help? (I have been using
> nodeprobe)
>
>
> cheers,
> /Marcin
>
>> Flush before you kill the process and restart will be much faster.
>>
>> On
I have done that before plus compact and it didn't help? (I have been
using nodeprobe)
cheers,
/Marcin
Flush before you kill the process and restart will be much faster.
On Fri, Mar 19, 2010 at 9:40 AM, Marcin wrote:
Hi guys,
is there a way to avoid compacting, flushing and all of thi
Flush before you kill the process and restart will be much faster.
On Fri, Mar 19, 2010 at 9:40 AM, Marcin wrote:
> Hi guys,
>
> is there a way to avoid compacting, flushing and all of this thing on
> startup and perform it while node is running ?
>
> It takes a lot of on startup.
>
>
> cheers,
>
Hi guys,
is there a way to avoid compacting, flushing and all of this thing on
startup and perform it while node is running ?
It takes a lot of on startup.
cheers,
/Marcin
13 matches
Mail list logo
