中国語の Bing は良くないみたい。。。

中国の 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/

HP のコンテナ･データセンター

Google の第一世代と比較して、格段の進歩が！

1ラックあたり、27kWと言っています。 2U で 25段重ねとすると、1ラックで 50サーバーになります。 その計算だと、1U あたり 500W 強になるので、そんなものなのでしょう。3500 台／コンテナとも言っていますので、70 ラックくらいになるのでしょうか。。。 20000 HDDs とも言っていますが、全体の容量はどれくらいなんでしょうかね？

 

Google のコンテナ･データセンターは 1Uコンフィグレーションらしく、1000台／コンテナです。そして、フィールド･メンテナンスはしにくい構造のように思えます。 その点、この HP のコンテナは、冷却装置を天井に持っていって、メンテナンス要員が冷却ホースを蹴飛ばさないようにしているんでしょうね。。。 ラックが占める床面積も減って、メンテのための空間が確保できるのでしょう。

どこの展示会なのか分かりませんが、トナリには Rachable のコンテナが見えたりして、多大盛況のようですね。。。 見てみたいものだなぁ。。。

Database Sharding _5

Database Sharding とは、"Shared-Nothing" のアプローチである

When Database Sharding is Appropriate

Database Sharding は、汎用的なデータベース要件を持つビジネス･アプリケーションに、適切にフィットする。さらに、Data Warehousing アプリケーションに対して効果的に利用することも可能である。また、それを達成するために利用可能な、数多くのプロダクトとテクノロジーがするとき、ここでフォーカスしている要素について、考える必要もなくなるだろう。

Sharding にフィットする、汎用目的のデータベース用件は、以下の項目を含む：

• 高度なトランザクションを持つデータベース･アプリケーション
• 複数のワークロードを組み合わせたデータベース利用
  • 複雑なクエリーと結合を取り込んだ、頻繁な Read
  • Write に集約されるトランザクション（INSERT, UPDATE, DELETE を含むCRUDステートメント）
  • 共通のTableおよびRowに関する競合
• 汎用のビジネス･アプリケーション
  • 典型的な"repeating segment" のレポート生成
  • 何らかのデータ分析（他のワークロードとの組み合わせ）

特定のアプリケーションや環境に、Database Sharding が適用するかどうかを判断するために、評価すべき最も重要なことは、そのデータベース･スキーマが sharding に対して、適切な結果をもたらすことである。 本質的に、Database Sharding は “horizontal” なパーティショニングのための手法である。 つまり、シングル･スキーマ･テーブルのためのデータベース Row（Column の対極）が、多数の shard をまたいで配布されることを意味している。 前提となる状況に対して、上手くフィットする sharding の特徴を理解するために、決定すべき重要なポイントを以下にまとめる：

• スキーマ内の、すべてのトランザクション集約型のテーブルを識別する
• その時点でデータベースが操作している（操作すると思われる）トランザクション･ボリュームを判断する。
• すべての共有 SQLステートメント（SELECT, INSERT, UPDATE, DELETE）と、それぞれに組み合わされる量を識別する。
• スキーマ内に含まれる"table hierarchy" への理解を発展させる。言い換えれば、主要なparent-child の関係のことである。
• 大ボリューム Table上のトランザクションへ向けた、"key distribution" を判断する。つまり、広範囲へのムラのない配布なのか、狭い範囲に集中した配布なのか、その点を判断する。

上記の情報を用いることで、アプリケーションに対する 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