Agile Cat — in the cloud

Facebook で Office ドキュメントを共有する Docs.com を触ってみた

Posted in Facebook by Agile Cat on June 20, 2010

ベータ版が使えるようになっていました

fb docs_1

Facebook のF8 デベロッパカンファレンス(4月21日)で発表された Docs.comですが、すでにベータが使えるようになっています。このアプリケーションは、Microsoft の FUSE Labs が開発したものであり、Microsoft Officeのドキュメントの共有を実現していきます。 これらのドキュメントは、Web とデスクトップの間を行き来できて、Docs.com を Facebook のフレンドと共有することも可能とのことです。

ご存じのように、Microsoft 自身も Office をオンライン化を進めています。エンタープライズ向けには SharePoint で、コンシューマ向けには Windows Live でという事なのでしょうが、Facebook と連携する この Docs の方が、立ち上がりが早そうですね。

fb docs_2

Microsoft は Facebook と提携して Docs.com を作り、Facebook の新しい Open Graph APIと Social Plugins の使い方の例を見せてくれています。たとえば、auto-login を使うことで、Facebook Connect のボタンをクリックしなくても、この Docs をスタートできます。

Agile_Cat も試しにと思い、PPT ファイルを放り込んでみましたが、Web ビューでの編集(テキストのみ)が可能であることを確認できました。

___space

ドキュメントの共有で、Google Docs に遅れをとった Microsoftが、Facebook と組んで巻き返しに出てきたということなのでしょう。 それにしても、Windows Live の立場って、いったい どうなるのでしょうかね? それと、ドキュメントの最終型が、紙から離れて Web や eBook へと移行していることを、どのように Microsoft は捉えるのか、、、という視点も重要になると思います。 EVERNOTE という成功事例があるだけに。 ーーー A.C.

<関連>
Microsoft TownHall : Windows Azure と Facebook の連携が始まった!
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか?

Tagged with: , , ,

HDFS のスケーラビリティを考察する _1

Posted in Big Data, HDFS by Agile Cat on June 20, 2010

Scalability of the Hadoop Distributed File System _1 

Yahoo! Developer Network Blog
May 5, 2010
http://developer.yahoo.net/blogs/hadoop/2010/05/scalability_of_the_hadoop_dist.html?

image

image

In his fictional story "The Library of Babel", Jorge Luis Borges describes a vast storage universe composed of all possible manuscripts uniformly formatted as 410-page books. Most are random meaningless sequences of symbols. But the rest excitingly forms a complete and an indestructible knowledge system, which stores any text written in the past or to be written in the future, thus providing solutions to all problems in the world. Just find the right book.

ホルヘ・ルイス・ボルヘス (Jorge Luis Borges) の作である「バベルの図書館」では、410ページの本として共通のフォーマットを持つ書籍で構成された、巨大なストレージの世界を表現している。そして、その 大部分が、無意味なシンボルの羅列となる。 しかし、残りの部分は完全で破壊されることのない知識システムを形成し、過去に記述され将来に記述されるあらゆるテキストをストアする。 したがって、世界におけるすべての問題に対するソリューションを提供する。 まさに、必要な本を探し出せる。

The same characteristic fascinates us in modern storage growth: The aggregation of information directly leads to proportional growth of new knowledge discovered out of it. A skeptic may doubt that further reward in knowledge mining will not justify the effort in information aggregation. What if by building sophisticated storage systems we are chasing the 19th century’s horse manure problem, when at the dawn of the automobile era the scientific world was preoccupied with the growth of the horse population that threatened to bury the streets of London nine feet deep in manure?

近代的なストレージが成長してきたいま、それと同じ特質が私たちを魅惑する。 つまり、情報のアグリゲーションから発見される、均衡のとれた新しい知識のダイレクトな成長が導かれることになる。 懐疑的な人々は、ナレッジ・マイニングにおける更なる報いは、正当な情報アグリゲーションを破壊すると言うだろう。しかし、洗練されたストレージ・システムを構築することで、19世紀における馬糞の問題を取り除けるなら、どうなるかと考えるべきだろう。 つまり、自動車の時代が始まろうとしているのに、London の街が 9フィートの深さまで馬糞で埋まると脅す馬喰たちに、科学の世界は屈してはならないのだ。

The historical judgment will turn one way or another. In the meantime, we want to know how far we can go with existing systems even if only out of pure curiosity. In my USENIX ;login: article “HDFS Scalability: the Limits to Growth,” I studied scalability and performance limitations imposed on a distributed file system by the single-node namespace server architecture. The study is based on experience with largest deployments of the Hadoop Distributed File System (HDFS) currently in production at Yahoo!.

歴史における審判は、一様なものではなく、揺れ動く。 そうこうしている間に、たとえ純粋な好奇心を失うにしても、既存システムを用いて、どこまで行けるかを知りたがる。 私は USENIX ; login: article “HDFS Scalability: the Limits to Growth” において、シングル・ノードの名前空間サーバー・アーキテクチャにより、何らかの分散ファイル・システムを割り当てられた際の、スケーラビリティとパフォーマンス限界を調査した。 この調査は、Yahoo! で運用中の Hadoop Distributed File System(HDFS)における、最も大規模なディプロイメント・エクスペリエンスに基づいている。

The first part of the study focuses on how the single name-server architecture limits the number of namespace objects (files and blocks) and how this translates to the limitation of the physical storage capacity growth.

この研究における最初のパートでは、単一のネームサーバー・アーキテクチャが名前空間オブジェクト(ファイルとブロック)の数を制限する様子と、それにより、物理ストレージの容量的な成長が妨げられる点にフォーカスする。

The second part explores the limits for linear performance growth of HDFS clusters bound by natural performance restrictions of a single namespace server. As the cluster grows, the linear increase in the demand for processing resources puts a higher workload on the single namespace server. When the workload exceeds a certain threshold, it saturates the server, turning it into a single-node bottleneck for linear scaling of the entire cluster.

2番目のパートでは、単一の名前空間サーバーにおける自然なパフォーマンス制約により、HDFS クラスタのリニアなパフォーマンス向上が妨げられる限界を探究する。 クラスタが成長するにつれて、リソース処理の要求に関するリニアな増加が、単一の名前空間サーバー上のワークロードを押し上げる。 ワークロードが一定の閾値を超えるとき、そのサーバーは飽和することになり、クラスタ全体のリニアなスケーリングに対する、シングル・ノード・ボトルネックへと変様する。

In 2006, the Hadoop group at Yahoo! formulated long-term target requirements for HDFS and outlined a list of projects intended to bring the requirements to life. Table 1 summarizes the targets and compares them with the current achievements:

Yahoo! の Hadoop グループは 2006年に、 HDFS に対する長期的な目標の要件を規定し、それらの要件を活性化する意図を持つ、いくつかのプロジェクトのリストをまとめた。 それらのターゲットを Table 1 に要約し、現時点の到達点と比較する:

image

The bottom line is that we achieved the target in Petabytes and got close to the target in the number of files. But this is done with a smaller number of nodes and the need to support a workload close to 100,000 clients has not yet materialized. The question now is whether the goals are feasible with the current system architecture.

結論として、私たちは Petabytes オーダーの目標を達成し、ファイル数においても目標に近づいたといえる。 しかし、これらの結果は少数のノードを用いて達成されており、100,000 クライアントに近いワークロードを、サポートしていくという必要性は、まだ実現していない。 そして、私たちのゴールが、現在のシステム・アーキテクチャを用いて実現できるのかという疑問が残っている。

Namespace Limitations

HDFS is based on an architecture where the namespace is decoupled from the data. The namespace forms the file system metadata, which is maintained by a dedicated server called the name-node. The data itself resides on other servers called data-nodes.

HDFS は、名前空間がデータから分離されるアーキテクチャに基づいている。 この名前空間は、Name-Node という専用サーバーにより維持される、ファイル・システムのメタデータを形成する。 そして、データ自身は、Data-Node という他のサーバー上に配置される。

The namespace consists of files and directories. Files are divided into large (128 MB) blocks. To provide data reliability, HDFS uses block replication. Each block by default is replicated to three data-nodes. Once the block is created its replication is maintained by the system automatically. The block copies are called replicas.

この名前空間は、ファイルとディレクトリで構成される。 そして、それらのファイルは、大きなブロック(128MB)に分けられる。 データの信頼性を確保するために、 HDFS はブロック・リプリケーションを使用する。 それぞれのディフォルト・ブロックは、3 つのデータノードにリプリケートされる。 それらのブロックが作成された後に、システムにより自動的に、リプリケーションの管理が行われる。 このブロックされたコピーのことを、レプリカと呼ぶ。

The name-node keeps the entire namespace in RAM. This architecture has a natural limiting factor: the memory size; that is, the number of namespace objects (files and blocks) the single namespace server can handle.

そして、Name-Node により、すべての名前空間が RAM 上に保持される。 当然のこととして、このアーキテクチャは制約の要因を伴う。 つまり、メモリのサイズであり、単一の名前空間サーバーが取り扱う、名前空間オブジェクト(ファイルとブロック)の数が制限されることになる。

Estimates show that the name-node uses less than 200 bytes to store a single metadata object (a file inode or a block). According to statistics on Y! clusters, a file on average consists of 1.5 blocks. Which means that it takes 600 bytes (1 file object + 2 block objects) to store an average file in name-node’s RAM

シングル・メタデータ・オブジェクト(a file inode or a block)をストアするために、200 Bytes 以下を使用する Name-Node を見積もってみよう。 Yahoo! クラスタにおける統計値では、ファイルの平均サイズは 1.5 ブロックに相当する。 つまり、Name-Node の RAM 内に、平均的なサイズのファイルをストアするために、600 Bytes(1 file object + 2 block objects)が必要となる。

To store 100 million files (referencing 200 million blocks), a name-node should have at least 60 GB of RAM.

1億のファイルをストアするためには、Name-Node は最低でも 60GB の RAM を必要とする。

<続く>

おそらく、3回くらいに分けてのポストになると思います。 ーーー A.C.

<関連>
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
ーーーーー
Hadoop DFS _ Introduction
NoSQL Ecosystem とは? _1

 

Tagged with: , , , ,
%d bloggers like this: