Eugenio Pace – Cloud Computing Guidance
Windows Azure のセールス･ポイントとして注目される New SDS ですが、Eugenio さんのブログで新しいポストを見つけました。 それと、以前の Eugenio さんの LitwareHR ですが、カテゴリ Eugenio Tracker に整理しましたので、そちらもご覧ください。 －－－ A.C.
Clouds: one thing we really know about here in Redmond, WA, USA
Published Friday, June 12, 2009 12:03 PM by eugeniop
Pasted from <http://blogs.msdn.com/eugeniop/archive/2009/06/12/first-experiments-with-new-sql-data-services.aspx>
First experiments with (new) SQL Data Services
Last week I got my new login to the new SQL Data Services. As a reminder for all readers:
SDS accelerates its plans to offer relational capabilities
May 11, 2009 – Based on customer feedback, SDS has accelerated its plans and will be offering true relational capabilities through SQL Server’s existing network protocol, Tabular Data Stream (TDS) and existing query language Transact-SQL (T-SQL). This will provide customers direct access to the familiar relational model, T-SQL programming language and the existing development and management tools, while continuing to deliver on our key value props of fault tolerance, high availability, friction free provisioning and pay as you grow scaling. For more information, see the SDS product site and the MSDN Library.
May 11, 2009 – カスタマー･フィードバックに基づき、SQL Server における既存のネットワーク･プロトコルである Tabular Data Stream（TDS）を介して、また、既存のクエリー言語である Transact-SQL（T-SQL）を介して、SDS の計画を加速し、本当のリレーショナル機能を実現していく。 そこで顧客に提供されるのは、T-SQL プログラミング言語と、開発と管理のための既存のツールで構成される、親しみのあるリレーショナル･モデルへのダイレクトなアクセスであるが、フォールト･トレランスと、高可用性、スケールの成長に応じたプロビジョニングと支払いなどへの、支援に関する提供は継続される。 詳細な情報については、SDS プロダクト･サイトと MSDN Library を見てほしい。
————————-
What I’ve done? After some initial “hello world-ish” tests, I wanted to try something more interesting so I decided to port IssueTracker into SDS.
私がしたことについて、説明しよう。 最初に行った何パターンかの “hello world-ish” テストの後に、もっと面白いことをやりたいと思った。 そして、SDS で IssueTracker をポートすることに決めた。
As you know, IssueTracker was originally designed for SDS’ previous ACE model (Authority, Container, Entity), so my first task was to re-write the data access layer to use SQL Server.
皆が知っているように、IssueTracker は以前の SDS が提供していた、ACE モデル（Authority、Container、Entit）のためにデザインされたため、最初の作業は SQL Server をように、そのデータ･アクセスレイヤをリライトすることだった。
One of my goals in this experiment was to test SDS “impedance match” with on-premises SQL Server. Also, I wanted to develop independently of the availability of SDS. Not that SDS is unreliable, but currently it is available only inside Microsoft’s corporate network. I didn’t want to VPN into corpnet for this when working from home.
この実験における目的にひとつは、オンプレミスの SQL Server を用いた、SDS の “impedance match”をテストすることにあった。また、SDS の可用性とは切り離されたところで、開発を行いたいと望んだ。 SDS が信頼できないということではないが、現時点においては、Microsoft のコーポレート･ネットワークの中だけで利用できるというものである。 そして、コーポレート･ネットワークに依存したくなかったのは、家でも仕事をするからだ。
So I chose to develop exclusively against my local SQL Express instance first and then make a switch to the real SDS.
そこで私が選んだのは、ローカルな SQL Express インスタンスで最初に作業した後に、本物の SDS にスイッチする形態である。
Fortunately, the app was designed with a couple of layers that isolated the persistence details, so writing the new data tier was a fairly mechanical process.
幸いなことに、このアプリケーションは永続的に分離される、2 つの層の組み合わせを用いてデザインされていたため、新しいデータ層の記述は、機械的なプロセスで進んだ。
This diagram roughly captures the architecture:
そのアーキテクチャについて、以下の図に示す：
The repository classes implement a common interface the app uses, the Model is just a collection of rather simple C# objects with no knowledge of the database being used. The Mappers are responsible for the transformations between the application model and the entities that do have knowledge of the database.
そのリポジトリ･クラスはアプリケーションが使う普通のインターフェイスを実装する。そして、この Model は単純な C# オブジェクトというより、単なるコレクションであり、データベースの知識は必要ない。 また、Mappers に課せられた責任は、アプリケーション･モデルと、データベースの知識を持つエンティティの間での変換となる。
In the diagram, classes marked with * are new, the numbers indicate variability points in the implementation, meaning that I can switch between one implementation and the other. Because I used LINQ to SQL, the types in the box labeled as “SQL Model” were generated automatically by the LINQ to SQL designer.
この図で、* マークが付いているのは新しいクラスであり、また、数が記されているのは、実装を切り替えられる可変のポイントである。 SQL に対して LINQ を使用したため、ボックス内に記された “SQL Model” であるというラベルは、LINQ to SQL デザイナーにより自動的に生成された。
When my unit tests compiled again, I switched the connection string to point from the “.\SQLEXPRESS” to the SDS instance in our network and…it worked! First attempt!
単体テストのために再コンパイルしたとき、接続文字列のポイントを、 “.\SQLEXPRESS” から、ネットワーク上の SDS インスタンスに切り替えた。それが、そのまま動いた。 それが、最初のトライである！
Overall, it was a rather painless and pleasant experience. Of course the data model in the app is simple and I’m not using any advanced queries or any sophisticated features in SQL yet.
もちろん、アプリケーションのデータモデルはシンプルであり、また、SQL の洗練されたクエリーや、先進的なキューは使っていない。
Things missing and Possible next steps:
The original implementation had 2 requirements that leveraged features in SDS previous ACE model:
1- Multi-tenant isolation: achieved through containers. Each tenant got its own container.
2- Schema flexibility: tenants could customize the application, extending the schema of some core entities. Flexible entities made this very easy, because they are essentially property bags.
このオリジナルの実装は、以前の SDS ACE モデルにおける 2つの機能を活用するという用件を持っていた：
1- Multi-tenant isolation: コンテナを介して達成されるものであり、それぞれのテナントが自身のコンテナを持つ。
2- Schema flexibility: いくつかのコア･エンティティを拡張することで、テナントによるアプリケーションのカスタマイズを実現する。柔軟なエンティティにより実現可能な理由は、それらが、本質的にプロパティ･バッグだからである。
For #1, I considered two options:
1- Partitioning by tenant
2- Do not partition at all and have all tenants on the same database (single-instance, multi-tenant)
#1 については、2つのオプションを検討した：
1- テナントによるパーティショニング
2- パーティショニングは全く行わずに、すべてのテナントを同一のデータベース上に持つ（single-instance, multi-tenant） The first option is fairly straight forward. Each tenant gets its own database that is created at provisioning time. The “tenant id” is part of the calling context in the application, so I dynamically connect to each database as needed. Two advantages of this approach: there’s high isolation between tenants (no data from one can leak into another), and the application code is simpler, because from the data perspective, the application is “single-tenant”.
最初のオプションは、かなり単刀直入なものである。 それぞれのテナントが、プロビジョニング時に作成される。自身のデータベースを取得する。 その “tenant id” が、アプリケーションにおけるコール･コンテキストの一部となるため、個々のデータベースとの動的な接続が、必要に応じて実現される。 このアプローチにおける のアドバンテージは、テナント間の分離が強化されることである。 また、アプリケーション･コードもシンプルになる。 その理由は、データの視点から見ると、対象となるアプリケーションが “single-tenant” になる点にある。
I haven’t implemented the extensibility feature yet, but I’m planning on reusing some techniques we did some research on in the past, probably through extension tables.
拡張された機能については、まだ実装していないが、いくつかのテクニックを再利用したいと考えている。それは、おそらく、過去において研究してきた、拡張テーブルを介したものとなるだろう。
There’re other interesting areas for research such as:
そのほかの、研究すべき領域としては、以下のような面白い分野がある：
1- Strategies for partitioning: in discussions with Ryan, he suggested I should consider more sophisticated ways of partitioning the information: by tenant, by tenant + project, etc. and I agree this would be interesting .
1- Strategies for partitioning: Ryan とのディスカッションにおいて、情報のパーティショニングについて、もっと洗練された方式を考えるべきだとの示唆があった。それは、 by tenant や by tenant + project などであり、それらが興味深いものであることに、私は同意している。
2- Unit of Work: currently I’m simply reusing the original ACE implicit UoW that comes with each interaction. This is, each time you called Create, Delete or Update on SDS, the operation was completed in the context of a unit of work. You could not logically group multiple operation (say, 2 creates and 1 delete). This is suboptimal with the SQL implementation, because the new SDS supports transactions and I would like to leverage that.
2- Unit of Work: 現時点では、それぞれの相互作用に伴って生じる、オリジナルの ACE における暗黙の UoW を再利用しているだけである。 それは、SDS 上で Create／Delete／Update がコールされるたびに、unit of work のコンテキストの中で、オペレーションが完了するというものだ。 多数のオペレーションを、論理的にまとめることはできない（たとえば、2つの create と、1つの delete）。 それが、SQL 実装における次善である。なぜなら、新しい SDS がサポートするトランザクションを、活用したいと思っているからだ。
3- Performance and scalability issues: I haven’t spent any time looking at the application’s “chattiness” with the database that might lead to degraded performance, or any other data access optimizations. This is a whole area in itself, but not very different from “regular” application development. The only exception perhaps is that, in theory at least, the app and the database can be hosted in different datacenters (say the app in Amazon and the data in SDS). I’m not sure that would be a good idea anyway, probably not for this scenario. If the app was hosted in Windows Azure and used SDS, then they would be close in terms of network distance (low latency & high bandwidth).
3- Performance and scalability issues: このアプリケーションとデータベースの間での “chattiness” については、時間を割いてこなかった。そのため、パフォーマンスの低下を招いているかもしれないし、データアクセスの最適化が必要かもしれない。 それは、アプリケーションの全域におよぶものであるが、“regular” なアプリケーション開発と、そう変わるものでもない。 唯一の例外と思われるのは、少なくとも理論上において、アプリケーションとデータベースが別のデータセンターにホストされる可能性があることだ（たとえば、アプリケーションは Amazonで、データは SDS）。 それが適切な考え方だとは、確信していない。そして、このシナリオのためのものでもない。 このアプリケーションが Windows Azure 上にホストされ SDS を使うなら、ネットワーク･ディスタンスの観点から、両者の距離は近いものとなる（low latency & high bandwidth）。
Published Friday, June 12, 2009 12:03 PM by eugeniop
Pasted from <http://blogs.msdn.com/eugeniop/archive/2009/06/12/first-experiments-with-new-sql-data-services.aspx>
