Agile Cat — in the cloud

LitwareHR on SSDS – Part III

Posted in Microsoft by Agile Cat on June 6, 2009

Eugenio Pace – Software as a Service Architecture Guidance

Published Monday, March 24, 2008 4:50 PM by eugeniop

From <http://blogs.msdn.com/eugeniop/archive/2008/03/24/litwarehr-on-ssds-part-iii-data-access-enhancements-1-caching.aspx>

LitwareHR on SSDS – Part III – Data access enhancements 1: caching

In most applications, the distance (in terms of bandwidth and latency) between the store (the database) and the application logic (like the web servers and web services) is usually very small. The connectivity between these two components is usually very reliable and with very high throughput. But because SSDS is on the other side of the cloud, latency and unreliability of the network could hurt the application performance and availability. Not to mention that in a production application, an ISV will very likely pay for each operation submitted against SSDS in addition to the storage he’s using.

大半のアプリケーションにおいて、ストア(データベース)とアプリケーション・ロジック(Web サーバーや Web サービスなど)の間の距離は、通常では極めて(バンド幅と遅延に関して)短い。これらの2つのコンポーネント間の接続性は、通常では極めて信頼性が高く、とても高いスループットを持つ。しかし、SSDS はクラウドの向こう側に存在するため、ネットワークの遅延と信頼性の欠如が、アプリケーションの性能と可用性に悪影響をおよぼす可能性がある。プロダクション環境における、アプリケーションについて言及するわけではないが、ISV が使用しているストレージのほかに、SSDS に対してサブミットされる個々のオペレーションためのコストが生じるだろう。

For all these reasons it is important to consider technical options that would minimize the degree of "chattiness" of the application (for decreased latency) and the total amount of calls made (for latency & for cost).

これら全ての理由に対して、検討すべき重要なテクニカル・オプションは、アプリケーションにおける「チャット性」を(遅延の低減のために)最小化し、発生するコールの総量(遅延とコストのために)を最小化することになるだろう。

With this in mind, it is highly likely your app will have a spectrum of information that it deals with, with different levels of longevity and volatility.

それを意識すると、アプリケーションが取り込む情報の種類に応じて、永続性と揮発性の異なるレベルを取り扱う可能性が、きわめて高くなると思われる。

If the data is immutable (e.g. reference information, read only, historic records, etc.) then there is a great chance you can aggressively cache it on the client side to avoid further calls. (Notice that "client side" is a relative term: in LitwareHR, the client side for SSDS is the web services layer).

もし、そのデータが不変(たとえば、リファレンス情報/リード・オンリー/ヒストリー記録)である場合には、必要以上のコールを回避するために、クライアント側で積極的にキャッシュを行えるという、大きな可能性が開ける。 (注意: LitwareHR の「クライアント・サイド」は相対的な用語であり、SSDS 用のクライアント・サイドは、Web サービス・レイヤとなる)

In LitwareHR, for example, Resumes cannot be modified. Someone can submit multiple resumes, but once it is submitted, it is immutable. A perfect candidate then for caching.

LitwareHR において、たとえば Resumes は、修正できない。 誰もが多数の Resumes をサブミットできるが、一度サブミットされると、不変となる。 そのときには、キャッシュのための、完ぺきな候補となる。

To demonstrate this scenario, we included caching capabilities into LitwareHR’s data access that can be enabled either programmatically and/or by configuration:

このシナリオを証明するために、LitwareHR のデータ・アクセスにキャッシュ機能を取り込んだ。 それは、コンフィグレーションによりプログラム的に and/or を切り替えることが可能なものである:

Eugenio 3 09_04_08

The CacheManager is simply using underneath Enterprise Library’s caching block that gives us nice backing store capabilities and some advanced expiration policies.

この CacheManager は、Enterprise Library のキャッシュ・ブロックにおける、下部構造を単に使っているだけである。それにより、適切なバッキング・ストア機能と、いくつかの先進的なエクスパイヤー・ポリシーが提供される。

The Repository will transparently get and store items (entities & full query results). To give the developer extra flexibility and control, entities only marked as "cacheable" (which is done through an interface implementation) are processed with the cache (if one is available). That means of course, that if an entity is not marked as "cacheable", then it will always go against the store, regardless of the existence and availability of a cache.

この Repository は、アイテム (entities & full query results) を透過的に取得し、ストアするだろう。デベロッパーに対して、さらなる柔軟性と盛業を提供するために、単に「cacheable(インターフェイス実装を介して処理される)」とだけマークされたエンティティが、キャッシュ(利用可能な場合に)を用いて処理される。もちろん、エンティティに「cacheable」のマークが無い場合には、キャッシュが存在し、その利用が可能であっても、ストアに対して処理が行われることになる。

As an example of how this works, here’s a small test. The class Book is an (extensible) entity and is also cacheable. 

その処理を確認するサンプルとして、以下に小規模なテストを示す。 クラス Book は(拡張可能な)エンティティであり、また、cacheable である。

public class Book : ExtensibleEntity, ICacheableEntity
{
public string Title { set; get; }
public string ISBN { set; get; }
public bool IsCached { set; get;} //This is ICacheableEntity implementation
}

We want to test a Repository for this class and caching behavior:

私たちは、このクラスの Repository と、キャッシュの振る舞いについてテストしたかった:

[TestMethod]
public void ShouldInsertBookGetByIdDelete()
{
using (Repository<Book> rp = new Repository<Book>(tenantId,
new RepositoryCacheManager( "CacheManager",
new SlidingTime( TimeSpan.FromMilliseconds( 3000 )),
true,
false )) )
{
Book bk = new Book { Id = Guid.NewGuid(), Title = "The Aleph", ISBN = "4374834" };
bk.Fields.Add("Author", "J.L.Borges" );
rp.Insert(bk);
Book rbk = rp.GetById(bk.Id);
Assert.IsNotNull(rbk);
Assert.IsTrue(rbk.IsCached);
Assert.AreEqual(bk.Title, rbk.Title);
Assert.AreEqual(bk.Fields["Author"].Value, rbk.Fields["Author"].Value);
Thread.Sleep(3500);
rbk = rp.GetById(bk.Id);
Assert.IsNotNull(rbk);
Assert.IsFalse(rbk.IsCached);
rp.Delete(bk.Id);
Assert.IsNull(rp.GetById(bk.Id));
}
}

Let’s see piece by piece how this works:

ここに含まれるのは、以下のとおりだ:

1- We create a new Repository for Book, using a constructor that takes the tenantid and a CacheManager implementation. This CacheManager takes this arguments:

  • The name of the EntLib’s cache to use (this translates into the configuration section to use)
  • The expiration policy (In the sample, it would be a sliding time of 3 seconds: items in the cache will be invalid after 3 seconds and discarded)
  • A boolean for caching entities (true in the example)
  • A boolean for caching queries (false in the example)

2- We create a new Book and add some fields, both explicit fields (as defined in the Book class) and an extension field (Author).

3- We insert the Book instance and then retrieve it immediately

4- Because the retrieval (hopefully :-)) will happen before 3 seconds, it should come from the cache (flagged with the IsCached field)

5- We then wait for slightly more than the expiration period (3.5 seconds to be precise) and then retrieve it again. This time, it should come fresh from SSDS, therefore IsCached should be false.

6- We clean up by deleting it

EntLib’s underlying implementation has some interesting features we didn’t use. For example, you can subscribe to expiration notifications and handle them. You could, for instance, proactively request a a renewal when an item expires proactively keeping your cache up to date.

EntLib の基礎をなす実装は、いくつかの興味深い特徴を持っているが、ここでは、それらは使われていない。たとえば、エクスパイヤーの通知をサブスクライブし、それらを制御することができる。実際に、キャッシュを最新レベルに保つために、アイテムを積極的にエクスパイヤーさせるリクエストを、積極的に発行することができるだろう。

Tagged with: ,
%d bloggers like this: