Great overview Alex, that summary is right on the money.
I'll be hitting these topics and more in the upcoming Distributed Cache
Webcast coming next week, Wed. Sept 12.
Here are some more points I will be talking about:
* Greedy locks means reads perform at memory speeds - TC notifies
when changes are made so local VMs don't have to check with
everyone else to make sure they have the most up to date copy
* Fine grained changes to objects means you don't need to use the
typical get/set/put strategy. Instead, just get/set and you are
done. This can be an enormous savings since the put stage
re-serializes your entire object graph and sends the replicas out
* Copy only where resident - this allows the automatic partitioning
to happen so updates aren't broadcast to other nodes unless those
other nodes actually need the update
* The durability means any and all components in the architecture
can fail, and on restart the heap memory will be intact. For a
write-back cache this is enormous, because you don't need
transactions to guarantee consistency with the database. Since
the heap memory is durable, the application can pick and choose
when it needs to flush changes, there is no requirement to
actually commit heap writes to the db for durable and reliable
storage, since Terracotta provides the same ACID guarantees with
significant improvements in performance (Terracotta deals with
objects, Databases deal with relational data)
Alex Miller wrote:
Hi Jim, I'm not an expert on any of the caching stuff but I think I can answer from general principles and Geert can tell you why I'm wrong... :)
Terracotta ultimately stores the distributed heap on disk, so it can manage a fairly large heap, certainly much much larger than your typical JVM in-memory heap. Each client will have some portion of the distributed heap in JVM heap, based on their usage pattern. Objects are faulted in and out of each VM as necessary, so no client (or server) must hold all of the cache values in memory.
I believe that most of the Terracotta-enabled caches (TC Cache, ehcache, etc) do require that cache *keys* are all in memory, so there are some constraints there, although keys are generally a smallish portion of the cache.
Additionally, I do not believe there is a way to intentionally stripe/partition/shard the data in any of the Terracotta-enabled caches. Rather, the in-memory portion is based on usage and you can somewhat drive that by applying partitioning above the cache level. For instance by using some kind of load balancing or partitioning scheme to force requests A-L to Server 1 and requests M-Z to Server 2. In this setup, the servers would naturally partition the data based on usage. The nice thing would be that both servers could serve all of the cache for failover - it's just that the data isn't in client memory in both.
Alex
----- Original Message -----
From: "Jim Bethancourt" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, September 7, 2007 2:21:32 PM (GMT-0600) America/Chicago
Subject: Re: [tc-dev] Please elaborate on distributed architecture of TC Cache
I apologize for not mentioning that I meant RAID 5 configuration, where each VM
has a piece of the cache, and another VM has a backup of the data.
Thanks,
Jim
On 9/7/07, Jim Bethancourt <[EMAIL PROTECTED]> wrote:
Hi Geert,
Could you possibly elaborate on the distributed architecture of the TC
Cache? I've come across a number of distributed caches before, but they only
attempt to maintain replicas of the same data in each of the distributed caches
and do not scale in the amount of data you can have in the entire cache. Does
the TC Cache work in this way, or does it work like more of a RAID style
software cache, where the more VMs you have, the more data you can hold in the
cache federation?
Thanks,
Jim
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
