Microsoft Project Code Named "Velocity" - Followup

Thoughts for the Velocity Team « Tales from a Trading Desk

Thoughts for the Velocity Team « Tales from a Trading Desk — Wed, 04 Jun 2008 01:40:19 GMT

PingBack from http://mdavey.wordpress.com/2008/06/03/thoughts-for-the-velocity-team/

re: Microsoft Project Code Named "Velocity" - Followup

sdonovan_uk — Wed, 04 Jun 2008 03:11:40 GMT

Firstly, congratulations on the CTP. We had a chat with some folks in Redmond about this last year and it's very proactive. :-) The API is simple, yet appears powerful and promising. I can imagine that the clustered approach is somewhat a challenge.

To add to the previous comments (I'm also in the financial derivatives IT business):

- When using a grid, caches are useful. But, a LOT of legacy pricing models are native C++. You should consider a unmanaged C++ API version of the cache-client.

- Yes, **please** implement PUSH notifications. We can envisgage using a cache as a messaging-system in it's own right, so it's a hard requirement (unless we getting into tedious polling). Obviously, need to examine latency, concurrent updates, etc.

. . . . with PUSH, can we have a Tag-based filter?

When PUSHing, a cache-entry would probably be (also) tagged with a Sequence #, or a TimeStamp. That would queried against.

API specific:

- CreateRegion(..). If you create an existing region, it exceptions with the generic CacheException. Wouldn't it be better to have an additional call to check to region existance? Or, is the preferred approach to check the errcode on the Exception?

- CacheItemVersion; there's no public/get/property to get the Version #. That would be useful.

- Tags (performance); the fact that it has a queryable interface is fantastically useful. But, what's practical performance like? If I have 10,000s to 100,000s (across different regions) of cache entries, each with 20-30 tags, what happens?

- Tags (vs. Keys). In our case, the CacheItem's Key would be built up of subkeys (e.g. HEDGE/HEDGE1/TRADE001). Effectively each part of the key is really, also, a Tag. It would seem too confusing to make them interchangeable, but please bear this in mind.

- Have you thought about security implications? As it stands, you're assuming that the cache-servers are all behind a firewall -- that's fair. But, it could be considered unsafe to allow any access, to any data.

- Perhaps I missed it, I didn't see any notes on the cache distribution policy. Are all cached keys/objects sent to all cache servers? If so, the cache-process looks Win32, isn't that restriction? How will you handle this?

Sean

re: Microsoft Project Code Named "Velocity" - Followup

joewood — Wed, 04 Jun 2008 03:20:24 GMT

Like many other comments:

Push distribution support. Something scalable like a PGM (NACK) based solution would be ideal - that downgrades to unicast if the network doesn't support multicast.

Full integration with astoria and the Entity framework's interfaces for CUD (i.e. IUpdatable etc)

When you have push support make the protocol open so that it can be consumed on the client side for Rich clients based on a server executed live query.

Use cases - other than traditional web session state:

Useful for aggregation of real-time data. Could be market data, monitoring metrics (think aggregated WMI/PerfMon metrics).

Avoid read/write conflicts in high through-put transactional systems. Read/write contention can be better managed using a cached version of a data store - as long as provision is made for some propagation delays in the app logic.

Useful for increasing capacity of transaction systems. A disperate distributed cache can reduce the risk of failure and the need to persist to storage for each transaction. This reduces exposure to failure without the need to commit to disk on each transaction.

Interesting Finds: 2008.06.04

gOODiDEA.NET — Wed, 04 Jun 2008 03:32:01 GMT

Web Facebook Open Platform 25 Excellent Ajax Techniques and Examples Profiling your AJAX Applications

re: Microsoft Project Code Named "Velocity" - Followup

velocityteam — Thu, 05 Jun 2008 15:05:11 GMT

Thanks for the feedback, Sean. Some responses

Unmanaged client access to Velocity: Yes, this is definitely something we're considering

Notifications: we're still in the design phase for this. And we know that this is a fairly tricky problem to solve. What we're trying to build is a set of simple building blocks, that can then be composed in many interesting ways. We'll have more updates on this soon

API questions

Adding an accessor for version: Sounds pretty reasonable. We'll look at adding this to future versions

CreateRegion: I tend to favor the current model (gives you an "atomic" create-or-error mechanism); Would having a more specific exception help ?

Tags performance: Currently tag-search is restricted to a "region" (which must reside in its entirety on a single node). That allows us to bound the processing time for a tag-search. We're looking at cross-region/cross-node tag searches, but like you say, this gets pretty expensive pretty soon

Tags vs Keys: I look at tags as alternate keys (partial keys) for a cached item

Security: We're looking into how we can have better support

Distribution policy: In the current CTP, we support only a "partitioned" cache (ie) each node contains only a (disjoint) subset of the overall data. In other words, for each cached object, there is a single node that "owns" the object. We maintain a partition map that allows to identify what objects (more specifically, what keys) live on what nodes, and this controls the distribution policy

Thanks

S Muralidhar (MSFT)

Architect

re: Microsoft Project Code Named "Velocity" - Followup

velocityteam — Thu, 05 Jun 2008 15:09:43 GMT

Thanks for the feedback, Joe.

>> Push distribution support. Something scalable like a PGM

We're still in the design phase for this functionality, and we'll definitely take this into account.

>> Full integration with astoria and the Entity framework's

>> interfaces for CUD (i.e. IUpdatable etc)

Can you share some more information on how you'd expect to use these together?

>> When you have push support make the protocol open so that it >> can be consumed on the client side for Rich clients based on a >> server executed live query.

Agreed. We'll keep this in mind as we design this capability.

Thanks for the suggestions on the other use cases. We've been thinking on very similar lines, and all of these are ideal scenarios for a caching solution (especially for applications that can tolerate a bit of staleness)

Thanks

S Muralidhar (MSFT)

Architect

(转)Velocity：微软的分布式内存缓存

gby630 — Mon, 16 Jun 2008 06:22:33 GMT

作者JonathanAllen译者胡键发布于2008年6月11日上午5时8分社区

Architecture,

.NET,

SOA

主题

.NET框架,

企业架构

标...

re: Microsoft Project Code Named "Velocity" - Followup

pkellner — Tue, 17 Jun 2008 05:09:44 GMT

Is the CTP posted someplace? where? How about the current api doc?

Velocity：微软的分布式内存缓存

HeroBeast — Fri, 28 Nov 2008 17:52:30 GMT

在过去几年里，从主流的Java应用到象Erlang这样的边缘语言，分布式内存缓存的应用相当流行。为了继续疯狂赶超开源世界中处于支配地位的技术，微软也引入了它的分布式缓存。Velocity是专门针...