Agile Cat — in the cloud

LitwareHR on SSDS – Part I

Posted in Microsoft by Agile Cat on June 12, 2009

Eugenio Pace – Software as a Service Architecture Guidance

Published Friday, March 14, 2008 3:52 PM by eugeniop

Pasted from <> 

LitwareHR on SSDS – Part I – Multi-tenancy & Flexibility

SSDS’s application model and features map quite nicely to our customization and multi-tenancy requirements in LitwareHR.

SSDSのアプリケーション・モデルと機能は、私たちのカスタマイズとマルチ・テナントの要件を、きわめて適切に LitwareHR にマップする。

A significant amount of code in LitwareHR is in the generic, multi-tenant, extensible data access. Our multi-tenant database performance guide, compares different extensibility approaches (XML datatypes, extended tables, fixed columns), their advantages and disadvantages, etc.

LitwareHR における相当量のコードは、汎用的であり、また、マルチ・テナント対応であり、拡張可能なデー・タアクセスを持つ。私たちのマルチ・テナント・データベースに関するパフォーマンス・ガイドでは、いくつかの拡張のためのアプローチ(XML データタイプ/拡張テーブル、固定カラム)が比較され、その利点と弱点を明らかにしている。

All of that is greatly simplified in the version of LitwareHR that uses SSDS because of the built-in support for extensibility and tenant isolation in the service.

それらの全てが、SSDS を用いる LitwareHR のバージョンでは、きわめて単純化される。 なぜなら、サービスにおける拡張性とテナントの分離が、ビルトインでサポートされるからだ。

The ACE Model:

SSDS model is quite simple actually, it is referred to as the ACE model and it is basically a 3 level containment architecture:

実際に、SSDSモデルは、きわめてシンプルである。 ACEモデルと呼ばれる、3レベルの階層型アーキテクチャを持つ:

Eugenio 090208a2

Authority (the top level container) contains zero or more Containers which in turn contain sets of Entities. Entities have properties: intrinsic (like Id, Kind & Version are present in any entity) and custom properties which are user defined. Properties have a type (string, dates, numbers).

Authority(コンテナのトップレベル)は、ゼロ個から複数個の Container を内包し、それぞれの Container が、Entity のセットを順番に取り込んでいる。 Entity には、本質的なプロパティ(Id/Kind/Version といった、あらゆるエンティティに存在するもの)と、ユーザーが定義するカスタムなプロパティを持つ。そしてプロパティは、タイプ(string/dates/numbers)も持つ。

This model maps very nicely to LitwareHR requirements:

以下のモデルは、LitwareHR 要件に対して、きわめて適切にマップされる:

Authorities & Containers give us out-of-the-box tenant isolation for storage.

Authorities & Containers は、ストレージに対して直ちに利用できるテナント分離を提供する。

Entities give us exactly what we need to provide each tenant a different data shape for positions and resumes.

Entities は、 positions とresumesのための異なるデータ shape を、個々のコンテナに提供するために必要とする、まさに適切なものをもたらす。

In our current implementation of LitwareHR, there’s a single Authority (owned by Litware for LitwareHR) with multiple containers: one for LitwareHR itself where all application metadata is stored (this is the equivalent of the old TenantMetadataStore), and one Container for each tenant that is provisioned. Here’s a subset of this model:

現時点における LitwareHR の実装では、単一の Authority(LitwareHR 用の Litware により所有される)と、複数の Container が含まれる。 ひとつは LitwareHR 自身のための、つまり、すべてのアプリケーション・メタデータをストアする Container であり(従来の TenantMetadataStore に等しい)、もうひとつは、プロビジョニングされる個々のテナントのための Container である。以下は、このモデルのサブ・セットである:

Eugenio 090208b2 

Because LitwareHR allows each tenant to change the shape of the Position entity, instances of this type are all different between tenants.

LitwareHR により、Position エンティティの shape を変更する、個々のテナントが実現されるため、このタイプのインスタンスは、テナントごとに、すべて異なるものとなる。

Notice that SDSS is actually more flexible than how it is used in LitwareHR. SSDS allows instances of any entity to have any set of properties and there’s no schema forced into any particular instance. LitwareHR restricts flexibility at the tenant level, so all positions of a given tenant will have the same schema, but each tenant can have any schema they want.

SDSS は LitwareHR での用法よりも、はるかな柔軟性を持つことに注意すべきだ。 SSDS は、あらゆるプロパティ・セットを持つ、あらゆるエンティティのインスタンスであっても許可し、いかなる固有インスタンスに対しても、フォーカスするスキーマは存在しない。 LitwareHR は、テナント・レベルにおいて、その柔軟性を制約する。そのため、所定のテナントにおける全ての position は、同一のスキーマを持つことになるだろうが、それぞれのテナントは、そこで必要となる、あらゆるスキーマを持つことができる。

LitwareHR Metadata Container

Entities stored in LitwareHR’s metadata container will be used to drive the application: tenant information, UI, menus, views, entities schema for the tenant, etc.

LitwareHR のメタデータ・コンテナにストアされるエンティティは、アプリケーションを駆動するるために使用される。 それらは、テナント情報、UI、メニュー、ビュー、テナントのためのエンティティ・スキーマなどとなる。

Here’s the result of a query against the demo LitwareHR container. You can see various entities stored there, including a serialized recruiting workflow definition:   

デモ用の LitwareHR コンテナに対してクエリーを実行した結果は、以下のとおりである。 そこにストアされた各種のエンティティを、シリアライズされたリクルーティング・ワークフローの定義も含めて確認できるだろう。

Eugenio 090208c2

The URI for this query is which essentially means: "bring me all the contents of container LitwareHR in litwarehr authority" (note the format of the URI:">">">">">">">">http://<AuthorityId><ContainerId>?q=).

このクエリーのURIは以下のとおりであり、本質的に「litwarehr Authority に、LitwareHR の全てのコンテナ・コンテンツを受け渡す」という意味を持つ。


SSDS query language (SLINQ) is a subset of LINQ syntax. For example, the query for retrieving all instances of particular entity type (e.g. "Tenant") would be:

"from e in entities where e.Kind==’Tenant’ select e"

SSDS query language(SLINQ)は、LINQ シンタックスのサブ・セットである。 たとえば、特定のエンティティ・タイプ(例えば "Tenant")における、すべてのインスタンスを取り出すためのクエリーは、以下のとおりになるだろう:「from e in entities where e.Kind == ‘Tenant’ select e」

SLINQ is a subset and there are many features not available quite yet: projections, grouping, etc.

SLINQ はサブ・セットであり、projections や grouping といった多くの機能が、まだ利用できない。

Currently, SSDS will return the whole entity, even if you just need a part of it. Of course you can still use LINQ on the client side to group, filter, etc. but over the wire the whole thing will be transported. 

現在時点では、たとえ一部が必要であっても、 SSDS はエンティティ全体をリターンするだろう。 もちろん、クライアント・サイドでは LINQ の group や filter などを使うことができが、全体が転送されるだろう。

Quid Pro Quo:

Nothing valuable is free, isn’t it? SSDS gives you unlimited storage, tremendous flexibility, geo-aware location. You don’t have to worry about backups, operations, disk failures, power, air conditioning, machines, etc. You just use it. But all this goodness comes at a cost: you don’t "own" the database any more, you can’t assume the database is "close" to you (too chatty interactions with it, will lead into latency issues) and the programming model you were used to is different: there are no tables, stored procedures, views, joins, etc.

価値が無ければタダであるが、SSDS はどうだろうか? SSDS が提供するものは、無制限のストレージと、途方もない柔軟性、そして、地理的要因を考えた配置である。 バックアップ/オペレーション/ディスクの故障/空調施設/マシンのことなど、心配しなくてもよい。 ただ、それを使うだけだ。 すべての利点はコストに跳ね返るが、もうデータベースは「所有」しなくて構わなくなる。データベースが、すぐ「近く」にあるなんて、想像できなくなる(つまり、チャットのようなインタラクションが、遅延の問題を導くわけだ)。そして、慣れ親しんできたプログラミング・モデルも、別のものに変わる。つまり、tables/stored procedures/views/joins などは無くなる。

You will have to decide whether these cons, out-weight the benefits in your particular scenario, and hopefully some of the lessons learnt in Litware, although impossible to extrapolate to every scenario, will help you make that decision.
As Nigel mentioned in MIX though, it is highly likely that many more features will be added to SSDS in the upcoming months.

発想の転換、そして 固有のシナリオにおいて重石から開放されるメリット、さらに Litware で望まれる若干のレッスン。すべてのシナリオは推定できないが、あなたの判断に、それらの要因は役立つだろう。 いずれにせよ、決めなければならなくなる。 Nigel が MIX で言及したように、この何ヶ月のうちに、さらに多くの機能が SSDS に加えられる可能性がある。

In the next chapters, I will go deeper into LitwareHR on SSDS architecture, the challenges we faced and how we solved them.

次のチャプタでは、SSDS アーキテクチャにおける LitwareHR  を掘り進める。 私たちが直面した課題と、それらを解決した方式について述べる。

Tagged with:
%d bloggers like this: