中国の Bing は、Biying になったとか？
Hongkong とか Beijing とか、中国語では ○○ng っていう英語発音表記が結構ありますよね。 そこで、Bing にも何か意味があるのかと思ったら、さにあらず、Bing は Bing と発音されないらしく、読みは （?）Biying に変更されるとか、されないとか。。。
また、Bing の意味は、病気とか、兵隊とか、クレープの皮とか、あまり検索エンジンに相応しくないものらしいです。
名前って、決めるのが大変ですよね。
http://digitizor.com/2009/06/13/microsoft-launches-biying-bing-for-china/
http://www.brandinfection.com/2009/05/29/bing-means-disease-in-chinese/
Google の第一世代と比較して、格段の進歩が！
1ラックあたり、27kWと言っています。 2U で 25段重ねとすると、1ラックで 50サーバーになります。 その計算だと、1U あたり 500W 強になるので、そんなものなのでしょう。3500 台／コンテナとも言っていますので、70 ラックくらいになるのでしょうか。。。 20000 HDDs とも言っていますが、全体の容量はどれくらいなんでしょうかね？
Google のコンテナ･データセンターは 1Uコンフィグレーションらしく、1000台／コンテナです。そして、フィールド･メンテナンスはしにくい構造のように思えます。 その点、この HP のコンテナは、冷却装置を天井に持っていって、メンテナンス要員が冷却ホースを蹴飛ばさないようにしているんでしょうね。。。 ラックが占める床面積も減って、メンテのための空間が確保できるのでしょう。
どこの展示会なのか分かりませんが、トナリには Rachable のコンテナが見えたりして、多大盛況のようですね。。。 見てみたいものだなぁ。。。
Database Sharding とは、"Shared-Nothing" のアプローチである
When Database Sharding is Appropriate
Database Sharding は、汎用的なデータベース要件を持つビジネス･アプリケーションに、適切にフィットする。さらに、Data Warehousing アプリケーションに対して効果的に利用することも可能である。また、それを達成するために利用可能な、数多くのプロダクトとテクノロジーがするとき、ここでフォーカスしている要素について、考える必要もなくなるだろう。
Sharding にフィットする、汎用目的のデータベース用件は、以下の項目を含む：
特定のアプリケーションや環境に、Database Sharding が適用するかどうかを判断するために、評価すべき最も重要なことは、そのデータベース･スキーマが sharding に対して、適切な結果をもたらすことである。 本質的に、Database Sharding は “horizontal” なパーティショニングのための手法である。 つまり、シングル･スキーマ･テーブルのためのデータベース Row（Column の対極）が、多数の shard をまたいで配布されることを意味している。 前提となる状況に対して、上手くフィットする sharding の特徴を理解するために、決定すべき重要なポイントを以下にまとめる：
上記の情報を用いることで、アプリケーションに対する sharding における、価値と適用性の査定を速やかに得ることができる。 以下の例では、シンプルな Bookstore スキーマにおいて、データが shard される様子を示す：
Figure 3. Example Bookstore schema showing how data is sharded.
この Bookstore の例では、Primary Shard Table が ‘customer’ のエンティティである。 それが、対象となるデータを shard するために用いられるテーブルである。この ‘customer’ テーブルは、’customer_order’ エンティティと ‘order_item’ エンティティを子テーブルとして持つ、shard 階層の親である。対象となるデータは ‘customer.id’ の属性によりsharded され、’customer.id’ と関連する子テーブル内の、すべての関連する Row も同様に shard される。 Global Tables は、共通の参照テーブルであり、そのアクティビティは相対的に低い。そして、これらのテーブルは、cross-shard 結合を回避するために、すべての shard に対してリプリケートされる。
この例は、きわめて基本的なものであるが、前提となるデータベース･アプリケーションを shard する方式を、決定するために必要な考察点を提供している。 この、評価のためのアプローチを用いることで、特定の環境に対して sharding が適用できるのかどうか、その点を判断できる。 そして、Database Sharding を実装することで、どのようなメリットがもたらされるのかについても判断できるだろう。
＜終わり＞
Database Sharding _1
Database Sharding _2
Database Sharding _3
Database Sharding _4
Database Sharding _5
SQL Server Data Services – SSDS – New version of LitwareHR
Eugenio Pace – Software as a Service Architecture Guidance
Published Wednesday, March 05, 2008 9:32 PM by eugeniop
http://blogs.msdn.com/eugeniop/archive/2008/03/05/sql-server-data-services-sdss-new-version-of-litwarehr.aspx
Today, in his keynote, Ray Ozzie announced a new "cloud service" available from Microsoft: SQL Server Data Services (code name: Stika). It’s a good that he announced it, because now I’m out of quarantine and I can talk about it 
.
今日（MIX 08）の Ray Ozzie によるアナウンスの要旨には、Microsoft から提供される新しい「クラウドサービス」： SQL Server Data Services (code name: Stika) があった。 彼のアナウンスがあって良かった。 なぜなら、もう口をつぐむ必要もなく、それにつて話ができるからだ
For the last 2 months I’ve been working very closely with the SSDS team, understanding and exploring how their technology can be applied in the context of the work we do: (business) software delivered as a service. I’ve been playing the role of an ISV designing and creating solutions using SSDS. My playground has been, of course, LitwareHR: our reference application for and S+S app.
これまでの2カ月において、とても緊密に SSDS チームと作業してきた。その結果、（ビジネス）ソフトウェアをサービスとして配信するという、私たちが推し進めているコンテキストにしたがって、このチームのテクノロジーを適用するための方式を、理解し探求することができた。 いま私は、SSDS を用いてソリューションの設計／開発を行う、ISV の役割を演じている。 私の活動の場は、もちろん LitwareHR である。 それは、私たちのリファレンス･アプリケーションであり、S ＋ S アプリケーションでもある。
LitwareHR today looks like this:
現在の LitwareHR は、以下のような感じである：
LitwareHR on SSDS, looks like this:
そして、SSDS 上の LitwareHR は、以下のような感じである：
Same client experiences (Web Client, Rich Client, APIs), same business logic exposed through WCF, completely new storage.
同一のクライアント･エクスペリエンス（Web Client／Rich Client／API）と、WCF を介してエクスポーズされる同一のビジネスロジック、そして、完全に刷新されたストレージ。
My team’s job was to redesign Litware’s (multi-tenant) data access layer to use SSDS, adapting it to the new application model. It’s been a great and fun exercise, with lots of learning.
私のチームのジョブは、SSDS を活用するために、Litware の（マルチ･テナント）データ･アクセス･レイヤのデザインを変更し、新しいアプリケーション･モデルに適合させることだ。 それは、重要で面白いエクササイズであるが、たくさんの学習も必要だ。
Eugenio Pace – Software as a Service Architecture Guidance
Published Friday, March 14, 2008 3:52 PM by eugeniop
Pasted from <http://blogs.msdn.com/eugeniop/archive/2008/03/14/litwarehr-on-ssds-part-i-multi-tenancy-flexibility.aspx>
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レベルの階層型アーキテクチャを持つ：
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 である。以下は、このモデルのサブ･セットである：
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 コンテナに対してクエリーを実行した結果は、以下のとおりである。 そこにストアされた各種のエンティティを、シリアライズされたリクルーティング･ワークフローの定義も含めて確認できるだろう。
The URI for this query is http://litwarehr.data.sitka.microsoft.com/v1/LitwareHR?q= which essentially means: "bring me all the contents of container LitwareHR in litwarehr authority" (note the format of the URI: .data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">.data.sitka.microsoft.com/?q">http://<AuthorityId>.data.sitka.microsoft.com/<ContainerId>?q=).
このクエリーのURIは以下のとおりであり、本質的に「litwarehr Authority に、LitwareHR の全てのコンテナ･コンテンツを受け渡す」という意味を持つ。
http://litwarehr.data.sitka.microsoft.com/v1/LitwareHR?q=
なお、このURIの書式は、以下のとおりである：
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 を掘り進める。 私たちが直面した課題と、それらを解決した方式について述べる。
 |
 |
 |
 |
 |
 |
|  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Agile_Cat Tumblr
Theme: Rubric. Blog at WordPress.com.
