Thank you both very much, Erick and Steve.
Steve,
1. You are right on the target. I realized it later last week and did
additional tests. I am in the process summarizing it and I am going to put
it here as a comparison reference for others.
2. It is good to know.
3. Yes, I am using EBS. I under
A few observations from what you've said so far:
1) IN clauses in CQL can have performance impact by including sets of keys
that are spread across the cluster.
2) We previously used m3.large instances in our cluster and would see
occasional read timeouts even at CL.ONE. We upgraded to i2.xlarge w
Hello, there.
In relation to the Java driver, I would recommend updating to the latest
version as there were a lot of issues reported in versions earlier that
2.0.9 were the driver is incorrectly marking nodes as down/not available.
In fact, there is a new version of the driver being released in
Date: Sunday, January 27, 2013 6:51 PM
> To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <
> user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
> Subject: Re: Denormalization
>
> When I said that writes were cheap, I was speaking t
@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Denormalization
When I said that writes were cheap, I was speaking that in a normal case people
are making 2-10 inserts what in a relational database might be one. 30K inserts
lo mailto:edlinuxg...@gmail.com
> >>
> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <
> user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
> Date: Sunday, January 27, 2013 5:50 PM
> To: "user@cassandra.apache.org&l
@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Denormalization
One technique is on the client side you build a tool that takes the even and
produces N mutations. In c* writes are cheap so essentially, re-write
everything on all changes.
One technique is on the client side you build a tool that takes the even
and produces N mutations. In c* writes are cheap so essentially, re-write
everything on all changes.
On Sun, Jan 27, 2013 at 4:03 PM, Fredrik Stigbäck <
fredrik.l.stigb...@sitevision.se> wrote:
> Hi.
> Since denormalized dat
o:aventure...@gmail.com>>
Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Date: Sunday, January 27, 2013 3:44 PM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cass
@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Denormalization
In my experience, if you foresee needing to do a lot of updates where a
"master" record would need to propagate its changes to other records, then in
general a non-sql based data store may be
In my experience, if you foresee needing to do a lot of updates where a
"master" record would need to propagate its changes to other
records, then in general a non-sql based data store may be the wrong fit
for your data.
If you have a lot of data that doesn't really change or is not linked in
some
I don't have a current use-case. I was just curious how applications
handle and how to think when modelling, since I guess denormalization
might increase the complexity of the application.
Fredrik
2013/1/27 Hiller, Dean :
> There is a really a mix of denormalization and normalization. It really
There is a really a mix of denormalization and normalization. It really
depends on specific use-cases. To get better help on the email list, a
more specific use case may be appropriate.
Dean
On 1/27/13 2:03 PM, "Fredrik Stigbäck"
wrote:
>Hi.
>Since denormalized data is first-class citizen in
13 matches
Mail list logo
