No, I haven’t “thought why people don’t use Cassandra as a cache”, that’s why
I’m asking this here. I’m asking the community for their POV when it might
make sense to front Cassandra with Hazelcast. This is even mentioned as a use
case in the Hazelcast documentation (“As a front layer for a Cassandra
back-end”), and I’m aware of at least one large private enterprise that does
this.
From: Dorian Hoxha [mailto:dorian.ho...@gmail.com]
Sent: Friday, October 07, 2016 3:48 AM
To: user@cassandra.apache.org
Subject: Re: Rationale for using Hazelcast in front of Cassandra?
Primary-key select is pretty fast in rdbms too and they also have caches. By
"close to" you mean in latency ?
Have you thought why people don't use cassandra as a cache ? While it doesn't
have LRU, it has TTL,replicatio,sharding.
On Fri, Oct 7, 2016 at 12:00 AM, KARR, DAVID
mailto:dk0...@att.com>> wrote:
Clearly, with “traditional” RDBMSs, you tend to put a cache “close to” the
client. However, I was under the impression that Cassandra nodes could be
positioned “close to” their clients, and Cassandra has its own cache (I
believe), so how effective would it be to put a cache in front of a cache?
From: Dorian Hoxha
[mailto:dorian.ho...@gmail.com<mailto:dorian.ho...@gmail.com>]
Sent: Thursday, October 06, 2016 2:52 PM
To: user@cassandra.apache.org<mailto:user@cassandra.apache.org>
Subject: Re: Rationale for using Hazelcast in front of Cassandra?
Maybe when you can have very hot keys that can give trouble to your
3(replication) cassandra nodes ?
Example: why does facebook use memcache ? They certainly have things
distributed on thousands of servers.
On Thu, Oct 6, 2016 at 11:40 PM, KARR, DAVID
mailto:dk0...@att.com>> wrote:
I've seen use cases that briefly describe using Hazelcast as a "front-end" for
Cassandra, perhaps as a cache. This seems counterintuitive to me. Can someone
describe to me when this kind of architecture might make sense?