On Sun, 2011-02-20 at 09:04 -0500, Benson Margulies wrote: > There are two parts to the data footprint, one growing more rapidly > than the other. The faster growing part has a natural 'redis-friendly' > data model (keys map to values); but it would map to EHCache as well.
If you're coming into the non-relational world with the perspective that
the main consideration is your "data model," you're approaching the
problem from the wrong direction. The non-relational world isn't about
BCNF or foreign keys. Storing and retrieving individual items is the
easy part; we need to understand how you intend to *use* the data to
help you understand if Cassandra is a good fit.
* How do you add new data?
* Other than accessing individual items by their primary key (or
equivalent), how do you read it?
* What needs to be real-time? Asynchronous?
* What correctness or consistency constraints can you relax?
* What availability needs do you have?
* What programming languages are you working in?
> However, the initial redis/jredis implementation used redis, rather
> than local ordinary JVM objects, for the slower growing part. The
> lpush/ltrim usage was in here.
It's not clear just from your use of lpush/ltrim what you're doing. Some
uses can map to Cassandra's APIs with some creative reinterpretation;
others can't.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
signature.asc
Description: This is a digitally signed message part
