floater
Java Jedi
总版主
发贴: 3233
|
于 2008-07-29 02:17
No intention to throw flares. Just a discussion: The central point of this post is to use a composite key(user id + range) to increase the hit rate. I don't see the discussion on 分布式解决方案.
If I understand the distributed cache correctly, the following are the key points on a distributed cache solution: 1. clusted: all different JVMs carry the same content, replicated. 2. fault tolerant: >1 copies in the cache. Normally this feature and #1 are implemented as one, i.e., users can specify how many copies they want in the entire cache. 3. scalable: meaning, increase machines/JVMs to expand memory, not copies. Whether this is transparent to the users, i.e., whether users need to change code for new cache servers. 4. network protocols: UDP/TCP 5. transactions 6. backup to files/databases asynchronously. 7. API for other languages, JDBC/ODBC drivers 8. SQL language manipulations. 9. near cache/far cache memory management. 10. locking 11. distributed event handling, such as JMS. This is essential for intersystem updates.
Another term is data grid.
Another thought is that a cache component should be a reusable component. On the user API side, there should be only a handful methods, such as get/set, getAllkeys, lock, unlock, etc. On the config side, network, backup copies, memory size, etc.
From users' perspective, a cache should be just a large memory chunk, doesn't matter where it sits.
The composite key idea has been around for more than 15 years. The credit card number has 19 digits internally, they have to use this technique to decompose the huge table to many small tables so that they can quickly locate your record in millis. It's working well.
In my experience, the best solution so far, based on the above conditions, is still Tangosol, of course, this doesn't mean it has all the listed features, but it's close enough, some of the features can be added from outside. I've been using >30 fields composite key to locate data. From what I heard, this has been the case in most big financial firms since the data is huge - size does matter and it gets ugly very quickly.
Just some of experience to share.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Refactoring - Improving the Design of Existing Code
|