Deleting the data may not be the right approach here if you want to have a
clean slate to start the next test. It will leave tombstones around, which may
reduce your performance if you make a lot of deletes. It's pedantic, but it's
different to truncate or drop.
Truncate is doing a few more th
Hi,
For our Grails + Cassandra application's clean-DB-for-every-test needs, we
finally went back from using costly "truncate" calls to
"range-scans-and-delete" approach, and found such a great different between
the performance of the two approaches, that wrote a small blog post here
about it: "Gra
Thanks for sharing your inputs, Edward. Some comments inline below:
On Thu, Sep 22, 2011 at 7:31 PM, Edward Capriolo wrote:
>
>
>> 1) Should should try to dig in an determine why the truncate is slower.
> Look for related jira issues on truncation.
>
I should give it a try. I thought I might get
On Thu, Sep 22, 2011 at 9:27 AM, Roshan Dawrani wrote:
> Hi,
>
> We recently switched from Cassandra 0.7.2 to 0.8.5 and observing
> considerable performance degradation in embedded server's response times
> that we use in integration tests.
>
> One thing that we do is that we truncate our app colu
Hi,
We recently switched from Cassandra 0.7.2 to 0.8.5 and observing
considerable performance degradation in embedded server's response times
that we use in integration tests.
One thing that we do is that we truncate our app column families after each
integration test so that the next one gets a
