Irrespective of performance and latency numbers there are fundamental flaws
with using EBS/NAS and Cassandra, particularly around bandwidth contention and
what happens when the shared storage medium breaks. Also obligatory reference
to http://www.eecs.berkeley.edu/~rcs/research/interactive_laten
Sorry - should have been clear I was speaking in terms of route optimizing,
not bandwidth. No idea as to the implementation (probably instance
specific) and I doubt it actually doubles bandwidth.
Specifically: having an ENI dedicated to API traffic did smooth out some
recent load tests we did for
does an elastic network interface really use a different physical network
interface? or is it just to give the ability for multiple ip addresses?
On June 19, 2014 at 3:56:34 PM, Nate McCall (n...@thelastpickle.com) wrote:
If someone really wanted to try this it, I recommend adding an Elastic N
If someone really wanted to try this it, I recommend adding an Elastic
Network Interface or two for gossip and client/API traffic. This lets EBS
and management traffic have the pre-configured network.
On Thu, Jun 19, 2014 at 6:54 AM, Benedict Elliott Smith <
belliottsm...@datastax.com> wrote:
>
I would say this is worth benchmarking before jumping to conclusions. The
network being a bottleneck (or latency causing) for EBS is, to my
knowledge, supposition, and instances can be started with direct
connections to EBS if this is a concern. The blog post below shows that
even without SSDs the
Ok, looks fair enough.
Thanks guys. I would be great to be able to add disks when amount of data
raises and add nodes when throughput increases... :)
2014-06-19 5:27 GMT+02:00 Ben Bromhead :
>
> http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningEC2_c
http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningEC2_c.html
From the link:
EBS volumes are not recommended for Cassandra data volumes for the following
reasons:
• EBS volumes contend directly for network throughput with standard
packets. Th
While they guarantee IOPS, they don't really make any guarantees about
latency. Since EBS goes over the network, there's so many things in the
path of getting at your data, I would be concerned with random latency
spikes, unless proven otherwise.
Thanks,
Daniel
On Wed, Jun 18, 2014 at 1:58 AM, A
In this document it is said :
- Provisioned IOPS (SSD) - Volumes of this type are ideal for the most
demanding I/O intensive, transactional workloads and large relational or
NoSQL databases. This volume type provides the most consistent performance
and allows you to provision the exac
Hi,
I just saw this :
http://aws.amazon.com/fr/blogs/aws/new-ssd-backed-elastic-block-storage/
Since the problem with EBS was the network, there is no chance that this
hardware architecture might be useful alongside Cassandra, right ?
Alain
10 matches
Mail list logo
