DuyHai Doan wrote
it looks like there is a need for a tool to take care of the bucketing
switch
But I still can't understand why bucketing should be better than `DELETE row
USING TIMESTAMP`. Looks like the only source of truth about this topic is
the source code of Cassa.
--
View this
Are you interested in cassandra-stress in particular? Or in any tool
which will allow you to stress test your schema?
I believe Apache Jmeter + CQL plugin may be useful in the latter case.
https://github.com/Mishail/CqlJmeter
-M
On 8/17/14 12:26, Clint Kelly wrote:
Hi all,
Is there a way
Hello,
I would try something like that (I have not tested, no guarantee ..) :
import com.datastax.driver.core.ColumnDefinitions;
import com.datastax.driver.core.ResultSet;
import com.datastax.driver.core.Row;
import com.datastax.driver.core.utils.Bytes;
/* ... */
ResultSet result =
The Cassandra team is pleased to announce the sixth release candidate for
the
future Apache Cassandra version 2.1.0.
Please note that this is not yet the final 2.1.0 release and as such, it
should
not be considered for production use. We'd appreciate testing and let us
know
if you encounter any
This kind of question belong to the java driver mailing list, not the
Cassandra one, please try to use the proper mailing list in the future.
On Tue, Aug 19, 2014 at 10:11 AM, Fabrice Larcher fabrice.larc...@level5.fr
wrote:
But this is probably not very usefull, since you get only prints of
Distinguished Colleagues:
Our current Cassandra cluster on AWS looks like this:
3 nodes in N. Virginia, one per zone.
RF=3
Each node is a c3.4xlarge with 2x160G SSDs in RAID-0 (~300 Gig SSD on
each node). Works great, I find it the most optimal configuration for a
Cassandra node.
But the
The last guidance I heard from DataStax was to use m2.2xlarge's on AWS and
put data on the ephemeral drivehave they changed this guidance?
Brian
On Tue, Aug 19, 2014 at 9:41 AM, Oleg Dulin oleg.du...@gmail.com wrote:
Distinguished Colleagues:
Our current Cassandra cluster on AWS looks
I’m not sure about Datastax’s official stance but using the SSD backed
instances (ed. i2.2xl, c3.4xl etc) outperform the m2.2xl greatly. Also, since
Datastax is pro-ssd, I doubt they would still recommend to stay on magnetic
disks.
That said, I have benchmarked all the way up to the c3.8xl
Hi Mikail,
This plugin looks great! I have actually been using JMeter + a custom
REST endpoint driving Cassandra. It would be great to compare the
results I got from that against the pure JMeter + Cassandra (to
evaluate the REST endpoint's performance).
Thanks! I'll check this out.
Best
The stress tool in 2.1 also now supports clustering columns:
http://www.datastax.com/dev/blog/improved-cassandra-2-1-stress-tool-benchmark-any-schema
There are however some features up for revision before release in order to
help generate realistic workloads. See
The latest consensus around the web for running Cassandra on EC2 seems to
be use new SSD instances. I've not seen any mention of the elephant in
the room - using the new SSD instances significantly raises the cluster
cost per TB. With Cassandra's strength being linear scalability to many
terabytes
Short answer, it depends on your use-case.
We migrated to i2.xlarge nodes and saw an immediate increase in performance.
If you just need plain ole raw disk space and don’t have a performance
requirement to meet then the m1 machines would work, or hell even SSD EBS
volumes may work for you.
You're pricing it out at $ per GB… that's not the way to look at it.
Price it out at $ per IO… Once you price it that way, SSD makes a LOT more
sense.
Of course, it depends on your workload. If you're just doing writes, and
they're all sequential, then cost per IO might not make a lot of sense.
Thanks for the update, Benedict. We are still using 2.0.9
unfortunately. :/ I will keep that in mind for when we upgrade.
On Tue, Aug 19, 2014 at 10:51 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
The stress tool in 2.1 also now supports clustering columns:
I agree that it belongs on that mailing list but it's setup weird.. .I
can't subscribe to it in Google Groups… I am not sure what exactly is wrong
with it.. mailed the admins but it hasn't been resolved.
On Tue, Aug 19, 2014 at 1:49 AM, Sylvain Lebresne sylv...@datastax.com
wrote:
This kind of
Again, depends on your use case.
But we wanted to keep the data per node below 500gb,
and we found raided ssds to be the best bang for the buck
for our cluster. I think we moved to from the i2 to c3 because
our bottleneck tended to be CPU utilization (from parsing requests).
(Discliamer, we're
After we dropped a table, we noticed that the sstables are still there. After
searching through the forum history, I noticed that this is known behavior.
1) Is there any negative impact of deleting the sstables off disk and then
restarting Cassandra?
2) Are there any other
The stress tool will work against any version of Cassandra, it's only
released alongside for ease of deployment. You can safely use the tool from
pre-release versions.
On Tue, Aug 19, 2014 at 11:03 PM, Clint Kelly clint.ke...@gmail.com wrote:
Thanks for the update, Benedict. We are still
That is great news keep up the great work!
Best Regards,
Tony Anecito
Founder/PresidentMyUniPortal LLC
http://www.myuniportal.com
On Tuesday, August 19, 2014 2:38 AM, Sylvain Lebresne sylv...@datastax.com
wrote:
The Cassandra team is pleased to announce the sixth release candidate for the
Sorry for the spam - but I wanted to double check if anyone had experience
with such a scenario.
Thanks.
On Sun, Aug 17, 2014 at 7:11 PM, Viswanathan Ramachandran
vish.ramachand...@gmail.com wrote:
Hi,
How does LOCAL_QUORUM read/write behave when the data center on which
query is
On Tue, Aug 19, 2014 at 8:59 AM, Parag Patel ppa...@clearpoolgroup.com
wrote:
After we dropped a table, we noticed that the sstables are still there.
After searching through the forum history, I noticed that this is known
behavior.
Yes, it's providing protection in this case, though many
Still using good ol' m1.xlarge here + external caching (memcached). Trying
to adapt our use case to have different clusters for different use cases so
we can leverage SSD at an acceptable cost in some of them.
On Tue, Aug 19, 2014 at 1:05 PM, Shane Hansen shanemhan...@gmail.com
wrote:
Again,
I completely agree with others here. It depends on your use case. We were
using Hi1.4xlarge boxes and paying huge amount to Amazon, lately our
requirements changed and we are not hammering C* as much and our data size
has gone down too, so given the new conditions we reserved and migrated to
added, thanks.
On 08/18/2014 06:15 AM, Otis Gospodnetic wrote:
Hi,
What is the state of Cassandra Wiki -- http://wiki.apache.org/cassandra ?
I tried to update a few pages, but it looks like pages are immutable.
Do I need to have my Wiki username (OtisGospodnetic) added to some ACL?
We have cassandra cluster in three different datacenters (DC1, DC2 and DC3)
and we have 10 machines in each datacenter. We have few tables in cassandra
in which we have less than 100 records.
What we are seeing - some tables are out of sync between machines in DC3 as
compared to DC1 or DC2 when
On Tue, Aug 19, 2014 at 4:14 PM, Check Peck comptechge...@gmail.com wrote:
What could be the reason for this sync issue? Can anyone shed some light
on this?
Since our java driver code and datastax c++ driver code are using these
tables with CONSISTENCY LEVEL ONE.
1) write with CL.ONE
2)
I have 1 DC that was originally 3 nodes each set with a single token:
'-9223372036854775808', '-3074457345618258603', '3074457345618258602'
I added two more nodes and ran nodetool move and nodetool cleanup one
server at a time with these tokens: '-9223372036854775808',
'-5534023222112865485',
Hi,
As you are writing as CL.ONE and cqlsh by default reads at CL.ONE, there is
a probability that you are reading stale data i.e. the node you have
contacted for the read may not have the most recent data. If you have a
higher consistency requirement, you should look at increasing your
28 matches
Mail list logo
