Agile Cat — in the cloud

Google が OSS NoSQL として発表した、LevelDB の狙いは Chrome にあるのか?

Posted in Google, HTML5, NoSQL by Agile Cat on August 1, 2011

Google Open-Sources NoSQL Database Called LevelDB
By
Klint Finley / July 30, 2011 10:30 AM
http://www.readwriteweb.com/hack/2011/07/google-open-sources-nosql-data.php

_ Read Write

_ googleIn May Google open-sourced a BigTable-inspired key-value database library called LevelDB under a BSD license. It was created by Jeff Dean and Sanjay Ghemawat of the BigTable project at Google. It’s available for Unix based systems, Mac OS X, Windows, and Android.

この 5月に Google は、LevelDB という名の、BigTable を彷彿とさせる key-value データベース・ライブラリを、BSD 許可証の下でオープン化した。 それは、Google の BigTable プロジェクトに属する、Jeff Dean と Sanjay Ghemawat により作られたものである。そして、Unix ベースのシステムおよび、Mac OS X、Windows、Android で利用できる。

Although it first appeared in Google Code months ago, a blog post from Google earlier this week made the project more widely known.

それは、数カ月前に Google Code に登場したが、今週(7/30)に Google がブログにポストしたことで、プロジェクトの存在が広く知れわたった。

imageLevelDB is not a database server like other other key-value stores like Redis or Membase. Instead, it would most likely be used as an embedded database for other applications, much the way SQLite or Berkley DB are used. The technical advantage to using LevelDB instead of other key-value stores is its support for ordered data. Also, its BSD license is more liberal than the GPL Sleepycat license of Berkley DB.

LevelDB は、Redis や Membase といった、key-value ストアのデータベース・サーバーではない。それは、他のアプリケーションにエンベッドされるデータベースとして、使用される見込みが高い。つまり、SQLite やBerkley DB の用法に近いものとなる。他の key-value ストアに換えて、LevelDB を利用する際のテクニカルなアドバンテージは、ソートされたデータのサポートとなる。それに加えて、BSD ライセンスは、Berkley DB に適用される Sleepycat ライセンスよりも自由度が高い。

According to the announcement:

以下は、アナウンスメントからの抜粋である:

For example, LevelDB may be used by a web browser to store a cache of recently accessed web pages, or by an operating system to store the list of installed packages and package dependencies, or by an application to store user preference settings. We designed LevelDB to also be useful as a building block for higher-level storage systems. Upcoming versions of the Chrome browser include an implementation of the IndexedDB HTML5 API that is built on top of LevelDB. Google’s Bigtable manages millions of tablets where the contents of a particular tablet are represented by a precursor to LevelDB.

たとえば LevelDB は、最近にアクセスされた Web ページをキャッシュする Web ブラウザにより、あるいは、インストール済みのパッケージや依存性をリストする OS により、そして、ユーザー・プリファレンスをストアするアプリケーションなどにより利用されるだろう。さらに、私たちは、ハイ・レベルなストレージ・システムのための、有益なビルディング・ブロックとして、LevelDB をデザインしてきた。 これから登場してくる、将来の Chrome ブラウザ・バージョンは、この LevelDB 上に構築され、IndexedDB HTML5 API の実装を取り込むことになる。 Google の Bigtable は、何百万というタブレットを管理するが、その場所において、特定タブレットのコンテンツが前処理されることで、LevelDB へ向けて表示されていく。

LevelDB isn’t limited to just being used as an embedded database, however. Basho is already exploring the possibility of using LevelDB with Riak as an alternative to Bitcask or InnoDB. The company conducted some benchmarks, which you can find in this blog post.

しかし、 LevelDB の用途は、エンベッドされたデータベースだけに限定されるものではない。 すでに Basho は、Bitcask や InnoDB に代わる選択肢として、LevelDB と Riak を組み合わせて利用する、可能性について研究している。 そして、いくつかのベンチマークが行われたが、その結果を、このブログ・ポストで確認することが可能だ。

Google also released its own set of benchmarks here.

さらに Google は、それらのベンチマークで用いたセットを、ココ で公表している。

According to the project site the key features are:

  • Keys and values are arbitrary byte arrays.
  • Data is stored sorted by key.
  • Callers can provide a custom comparison function to override the sort order.
  • The basic operations are Put(key,value), Get(key), Delete(key).
  • Multiple changes can be made in one atomic batch.
  • Users can create a transient snapshot to get a consistent view of data.
  • Forward and backward iteration is supported over the data.
  • Data is automatically compressed using the Snappy compression library.
  • External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions.
  • Detailed documentation about how to use the library is included with the source code.

And the limitations are:

  • This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes.
  • Only a single process (possibly multi-threaded) can access a particular database at a time.
  • There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library.

See Also

ーーーーー

NoSQL も、まずは利用シナリオありきで、考えられるようになってきなのですね。IndexedDB HTML5 API って、どれほどのパーフォーマンスを見せてくれるのでしょう。 :) とても楽しみですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

NoSQL Database で 認識しておくべき 9つのポイント
NoSQL のユースケースを一般論と具体論で整理する
NoSQL の CouchDB が Android に搭載されるという話
Big Data を 美味しくいただくための、クッキング・ブックを作ろう
http://www.quora.com/LevelDB

Google のソフトウェア・インフラは時代遅れだと、元 Wave エンジニアが語る

Posted in .Chronicle, .Selected, Google by Agile Cat on June 8, 2011

Ex-Google Engineer Says the Company’s Software Infrastructure is Obsolete
By
Klint Finley / June 7, 2011 10:45 AM
http://www.readwriteweb.com/cloud/2011/06/google-infrastructure-obsolete.php

_ Read Write

Yesterday former Google Wave engineer Dhanji R. Prasanna wrote on his blog about why he is leaving the company. It’s an interesting look at Google’s company culture, but there’s also an interesting technical nugget in there. “Google’s vaunted scalable software infrastructure is obsolete,” Prasanna wrote. He emphasizes that the hardware infrastructure is still state of the art, “But the software stack on top of it is 10 years old, aging and designed for building search engines and crawlers.”

昨日のことだが、Google Wave のエンジニアだった Dhanji R. Prasanna が、その退職の理由を自身のブログに綴った。 それは、Google のカンパニー・カルチャーに関する興味深い視点を提供するが、テクニカルな側面も見落とせない。 「Google が自慢するスケーラブルなソフトウェア・インフラストラクチャは、すでに時代遅れである」と、Prasanna は書いている。 彼は、ハードウェア・インフラストラクチャについては最高水準であると強調するが、「 その上に展開されるソフトウェア・スタックは、10年前にサーチエンジンとクローラーを構築するために考案され、老朽化している」とも言う。

imagePrasanna says software like BigTable and MapReduce are “ancient, creaking dinosaurs” compared to open source alternatives like Apache Hadoop.

Prasanna の発言によると、Apache Hadoop などのオープンソースとの比較において、BigTable や MapReduce といったソフトウェアは「 年老いて弱った恐竜」となる。

Prasanna blames the state of Google’s software stack on it being designed by “engineers in a vacuum, rather than by developers who have need of tools.”

Prasanna は「ツールを必要とするデベロッパーではなく、孤立したエンジニア」によりデザインされた、Google ソフトウェア・スタックの状況に問題があると考えている。

If true, this speaks to the strength of open source – or at least of well maintained open source projects. Open source software can be improved by a wide variety of stake holders, but proprietary software will always be shielded from outside improvements. The open source alternatives have surpassed the proprietary versions that Google kept under lock and key, and Google isn’t in a position to take advantage of the improvements made by the open source community without making some major infrastructural changes.

それが事実であるなら、適切に維持されていることが前提となるが、オープンソース・プロジェクトの強さを論じることになる。 オープンソース・ソフトウェアは、多様なステークホルダーたちにより、その価値を高めることができるが、プロプライエタリなソフトウェアは、外の世界における改善から常に隔絶されている。 結果的に、それらのオープンソースは、Google が厳重に管理してきたプロプライエタリなバージョンをしのいだ。そして Google は、主要なインフラストラクチャを変更することなく、それらのオープンソース・コミュニティからの成果を利用できる立場にはない。

Also, if Prasanna’s assessment is correct, it would support RedMonk’s Stephen O’Grady’s thesis that software infrastructure is no longer a competitive advantage. This is particularly relevant as Google markets its App Engine platform-as-a-service. The Register’s Cade Metz recently wrote a long piece on Google App Engine as a means of accessing Google’s infrastructure. Although the platform has made improvements in the past year, many developers have been unhappy with its restrictions.

そして更に、Prasanna の評価が正しいなら、すでにソフトウェ・インフラストラクチャは競合におけるアドバンテージにはならないという、RedMonk の Stephen O’Grady の命題をサポートするものになる。 Google の App Engine が、PaaS として市場に提供されるにつれて、この命題は正当性を有してくる。 最近、The Register の Cade Metz は、Google のインフラストラクチャにアクセスする手段としての、Google App Engine に関する長い記事を書いた。 このプラットフォームは 1年間を費やして改善されてきたが、数多くのデベロッパーは、その制約に対して不平を漏らしている。

Developers have been willing to accept the proprietary nature of the PaaS and its restrictions to access Google’s infrastructure. But what if Google’s infrastructure really isn’t special? Cloud services powered by open services would then be even more desirable.

これまで、それらのデベロッパーたちは、Google の PaaS における特質を得るために、また、インフラストラクチャにアクセスするために、それらの制約を受け入れることを厭わなかった。 しかし、Google のインフラストラクチャが、本当の意味においてスペシャルなものでなければ、どうなうのだろう? つまり、オープンなサービスからパワー供給されるクラウド・サービスが、さらに望ましいものとして浮上してくる。

We’ve written before that “open” has won against proprietary, at least in rhetoric if not in practice. Thus far App Engine has bucked that trend. But for how much longer?

私たちは以前に、現実というより、少なくとも理論において、「オープン」がプロプライエタリに勝っているという記事をと書いた。 そして、これまでのところ、このトレンドに App Engine が反してきた。 しかし、それは、いつまで続くのだろうか?

ーーーーー

Google 自身が、Android の勢いを分析すれば、おのずと方向性が見えてくるのでしょうが、組織として俊敏に動けるかとなると、そこには、また 別の問題があるのでしょうね。 プロプライエタリの旗手である Apple が、iCloud を発表しましたが、冷静に観察していきたいと思います。 ーーー __AC Stamp 2

ーーーーー

<関連>

Apache Libcloud によるクラウド・スタンダードとは?
オープンソースはクラウドに適合するのか?
OpenStack の検証プロジェクトが日本で始まる – Bit-Isle / TERRAS / Midokura
Hadoop ビジネスで、EMC が仕掛ける大勝負とは?
VMware を分析すると、OS を持たない 新しい Microsoft に見えてくる

 

Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase

Posted in Big Data, Hadoop, NoSQL by Agile Cat on February 3, 2011

Real World NoSQL: HBase at Trend Micro
By Guy Harrison
Jan. 27, 2011, 8:30am PDT
http://gigaom.com/cloud/real-world-nosql-hbase-at-trend-micro/

Edit Note: This is the first on a multi-part series of posts exploring the use cases for NoSQL deployments in the real world.

_ Gigaom

With all the excitement surrounding the relatively recent wave of non-relational – otherwise known as “NoSQL” – databases, it can be hard to separate the hype from the reality. There’s a lot of talk, but how much NoSQL action is there in the real world? In this series, we’ll take a look at some real-world NoSQL deployments.

ノン・リレーショナル、さもなければ「NoSQL」 データベースとして認識されている大きなウネリが、このところ様々な憶測をもたらしているが、そこから真実と虚構を切り分けるのは、難しい作業となる。 数多くの話題が提供されているが、現実の世界において、NoSQL への取り組みは、どれぐらいの件数になっているのか? このシリーズでは、現実の世界における、いくつかの NoSQL ディプロイメントについて注目していく。

alt

Trend Micro provides corporate computer security products, and maintains web reputation databases that allow intelligent detection of spam, phishing, or suspicious web sites. Maintenance of these databases requires processing massive amounts of log data from DNS and other Internet servers, accumulating at the rate of about four petabytes per year. New product offerings for Trend Micro required real-time analysis of exponentially growing data volumes. After evaluating a number of database alternatives – including Hypertable and Cassandra – Trend Micro settled on Apache Hbase as the core database of new elastic infrastructure.

Trend Micro は企業向けのセキュリティ・プロダクトを提供し、また、スパムやフィッシングなどの、不審な Web サイトをインテリジェントに検出するための、Web 評価データベースを維持している。 これらのデータベースを維持していくためには、DNS や各種インターネット・サーバーから得られる、大容量ログ・データの処理が必要となり、また、年間に 4ペタ・バイトのレートで蓄積することになる。 急激に増大してきたデータ量に対応するために、Trend Micro の新しいプロダクトは、リアルタイム解析を必要とする。 Hypertable や Cassandra を含む、数多くのデータベースにおける選択肢を評価した後に、Trend Micro が決定したいのは、新しく柔軟なインフラストラクチャのコア・データベースとして Apache HBase を使用することである。

hbase

Several years ago, Trend Micro adopted Hadoop – the increasingly ubiquitous, open-source implementation of Google’s MapReduce framework – to store and perform bulk processing of these data sets. However, Hadoop on its own doesn’t provide a data store that can support individually updatable data items; you can’t change a single data item within a raw Hadoop dataset without having to reprocess the entire set.

数年前のことだが、それらのデータセットをストアし、バルクでの処理を行なうために、Trend Micro は Hadoop を採用した。言うまでもなく、Hadoop とは、Google MapReduce フレームワークのオープンソース実装であり、また、各所で利用されているものでもある。しかし Hadoop は、それぞれのデータ・アイテムを、個別にアップデートすようなデータストアを提供していない。つまり、生の Hadoop データセット内において、1つのデータ・アイテムを変更する場合にも、データセット全体を再処理しなければならない。

HBase, a NoSQL database modelled from Google’s BigTable system, offers the row level access required by Trend Micro and – since it is part of the Hadoop ecosystem already established at Trend Micro – may seem a natural choice. However, Trend Micro evaluated other non-relational databases, including Cassandra and HyperTable. HBase was eventually chosen because it demonstrated an ability to handle the transaction rates required and because of its active development community. Trend Micro’s HBase solution is scheduled to go live in the first half of 2011.

HBase は、 Google の BigTable システムをモデルとして設計された NoSQL データベースであり、また、Trend Micro が必要とする Row レベルでのアクセスを提供する。そして、すでに Trend Micro 社内で確立されている Hadoop エコシステムの一部であるため、その選択は当然のことだと思われるだろう。 しかし、Trend Micro は、Cassandra や HyperTable を含む、その他のノン・リレーショナル・データベースを評価した。 そして HBase が、最終的に選択されたわけであるが、その理由としては、要求されるトランザクション・レートでの処理能力と、活発な開発コミュニティが挙げられる。Trens Micro における HBase ソリューションは、2011年の前半には実運用を開始する予定である。

As well as the index of web sites that forms the core of the reputation database, the system accepts event traces and activity logs from customer desktops accumulating at the rate of 5 billion items every day. According to Andy Purtell, senior architect at Trend Micro, a traditional relational system would have been hundreds of times more expensive than HBase – if it could have handled the load at all. As well as the massive insert rate, HBase’s flexible schema, which allows new attributes to be added without reorganizing the database, and its tight Hadoop integration were compelling.

評価データベースのコアを形成する、Web サイト・インデックスのケースと同様に、このシステムは、顧客のデスクトップから得られるイベント・トレースと、アクティビティ・ログを受け入れる。そして、1日あたり 50億アイテムのレートで、それらを蓄積していく。 Trend Micro のシニア・アーキテクトである Andy Purtell によると、従来からのリレーショナル・システムで、こうした負荷を処理できると想定しても、HBase と比較して数百倍の費用がかかるという。 HBase では、大量のインサートが可能になるだけではなく、その柔軟なスキーマにより、データベースを再編成することなく、新しい属性を付加できる。 そして更に、Hadoop との緊密なインテグレーションという、説得力のあるメリットが実現される。

Because HBase is part of the Hadoop ecosystem, Trend Micro programmers have a variety of tools available that are tightly integrated with HBase. Currently, developers at Trend Micro write data access routines directly in Java, but they are considering PIG – a scripting language for Hadoop – and the SQL-like HIVE system for more ad-hoc access.

HBase は、Hadoop エコ・システムの一部であるため、 Trend Micro のプログラマーたちは、HBase と緊密にインテグレートするための、各種ツールを持っている。 現時点において、Trend Micro のデベロッパーたちは、データ・アクセス・ルーチンを、Java を用いてダイレクトに記述している。 しかし、Hadoop 用のスクリプト言語である PIG と、アドホックなアクセスを実現するための、SQL ライクな Hive の利用が検討されている。

“I’m not that interested in the NoSQL vs. RDBMS debate,” Purtell says. “I’m more interested in finding the best tools to build a solution. For our application, HBase is faster and cheaper than the relational alternative.”

『 NoSQL 対 RDBMS という図式には興味が無い。 つまり、ソリューションを構築するための、最適なツールに興味があるだけだ。 私たちのアプリケーションにとって、HBase は、リレーショナルな選択肢よりも高速であり、また、安価である 』と、 Purtell は発言している。

Guy Harrison is a director of research and development at Quest Software, and has over 20 years of experience in database design, development, administration, and optimization. He can be found on the internet at www.guyharrison.net, on e-mail at guy.harrison@quest.com and is@guyharrison on twitter.

Related content from GigaOM Pro (sub req’d):

ーーーーー

Purtell さんの発言からは、現実的なツールとしての HBase への評価が読み取れます。 NoSQL も、ここまで来たのですね :)  Hadoop がスタンダードとなり、そのパートナーとしての HBase の評判が高まっていますが、たとえば Cassandra の方が適しているというケースもあるはずです。 そんなコンテンツも読めるとイイなぁと、この 『Real World NoSQL シリーズ 』には期待してしまいますね。 ーーー __AC Stamp 2

ーーーーー

<関連>
HBase 0.90.0 の正式リリースについて ・・・ 河野達也
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!

Cosmos + Scope で Google を追撃か?

Posted in MS-MapReduce by Agile Cat on May 24, 2009

Cosmos と Scope と MapReduce と Hadoop と ・・・

Ray Ozzie から Cosmos というアナウンスがあったので、あっ そうそう、と思い出したのが Scope です。長いホワイトペーパーなので放っておいたのですが、あらためて眺めてみると、ここに Cosmos が居ましたよ。 以下の図に示されるように、Scope が言語処理系で、Cosmos がファイル・システムという組み合わせのようです。(Axum は、パラレルといっても計算機能のためのもののようです ・・・)

ーーーーーーーーーーー

SCOPE: Easy and Efficient Parallel Processing of Massive Data Sets

・・・より抜粋

ーーーーーーーーーーー

1. INTRODUCTION

Microsoft は、膨大なデータ・セットのストアと分析のために、Cosmos という分散コンピューティング・プラットフォームを開発している。 Cosmos は、無数の普及品サーバーにより構成される、大規模なクラスタ上で動作するようにデザインされている。 つまり、それらのサーバーにアタッチされたディスクにより、このストレージは分散されることになる。 Cosmos プラットフォームのためにデザインされた高次元での目的としては、以下の項目が含まれる:

1. Availability: Cosmos は、多数のハードウェア障害に対する弾力性を持つことで、システム全体の停止を回避する。ファイル・データは、このシステム全体に何度もリプリケートされる。また、2f+1 台のサーバーによる選択されたグループにより、ファイル・メタデータを管理することで、f 回の障害に対する弾性を持つ。

2. Reliability: Cosmos のアーキテクチャは、システムの機能低下を回避するために、一時的なハードウェア・コーディネーションを見分ける。 システム・コンポーネントは、End-to-End でチェックされ、障害を持つコンポーネントを停止するためのメカニズムを適用する。

3. Scalability: Cosmos のデザインは、ペタ・バイト・オーダーのデータをストアし処理する能力を持つ、スケーラブルなシステムを実現するために、ゼロからデザインされている。 そのクラスタにサーバーを追加していくことで、ストレージとコンピューティングのためのキャパシティを、容易に拡張できる。

4. Performance: Cosmos を実行するクラスタは、無数の独立したサーバーで構成される。 データは、3台のサーバー上に分散される。ひとつの Job は、小さなコンピューティングの単位に分解され、大量の CPU とストレージ・デバイスに分散される。 それにより、Job を完了する時間が、大幅に短縮される。

5. Cost: Cosmos は、同様の問題に対する従来からのアプローチと比較して、安価な構築と、運用と、拡張を実現する。 そこでは、費用対効果を高めるために、低価格サーバーを大量に利用するが、この考え方は、少数の高額サーバーによるアプローチの対極にある。

Cosmos -1

Figure 1 が示すのは、Cosmos platform の主要な構成要素である。

1. Cosmos storage: きわめて膨大なシーケンシャル・ファイルを、信頼性と効率に基づいてストアするためにデザインされた、分散ストレージ・サブ・システムである。

2. Cosmos execution environment: 分散アプリケーションを、ディプロイし、実行し、デバッグするための環境である。

3. SCOPE: データ分析ジョブを記述するための、ハイレベルなスクリプティング言語。 この、SCOPE のコンパイラとオプティマイザにより、スクリプトを効果的なパラレル実行プランへと展開。

このドキュメントでは、SCOPE とコンポーネントにフォーカスしており、Cosmos については簡潔に説明するだけである。 Cosmos platform の詳細は、このドキュメントの対象外となる。

ーーーーーーーーーーー

ここまで読んでみて、Hadoop に かなり近いぞ、、、というか、同一のベクトルとコンセプトに思えます。 そして、6章ですが ・・・

ーーーーーーーーーーー

6. RELATED WORK

SCOPE is heavily influenced by SQL but its target applications and execution environment differ from traditional database systems. SCOPE is designed for easy and efficient processing of massive amounts of data stored in distributed, sequential files. It provides efficient query processing functionality. The execution strategies used owe much to earlier work on query processing in parallel and distributed database systems [9].

All companies operating internet-scale services have the need to store and process massive data sets and have developed their own system for this purpose. Google popularized the mapreduce programming model. Based on what has been published in the open literature, their software stack consists of Google File System [8] and Bigtable [3] for storage, the MapReduce execution environment [5] with users writing MapReduce applications in C++ or Sawzall [11].

A MapReduce application written in C++ takes many more lines of code than the corresponding application expressed in SCOPE. For example, the word count application used as an example in [5] requires about 70 lines of C++ code but only five or six lines of SCOPE code.

Yahoo! also has a software stack designed for distributed processing of massive data sets. Users write applications in a language called Pig Latin [10] [1]. A Pig Latin program is compiled by the Pig system into a sequence of MapReduce operators that are executed using Hadoop [1], an open-source implementation of MapReduce. Pig Latin is a dataflow language using a nested data model. Each step in a program specifies a single, high-level data transformation. A complex computation is expressed as a series of such transformations. Yahoo! also has a more powerful Map-Reduce-Merge execution environment but it is apparently not the execution environment used by the Pig system. Both Google and Yahoo! use a MapReduce execution environment. MapReduce is very rigid, forcing every computation to be structured as a sequence of mapreduce pairs. The Cosmos execution environment is significantly more flexible, handling execution of any computation that can be expressed as an acyclic dataflow graph.

ーーーーーーーーーーー

おおっ! これは Map-Reduce と Hadoop への挑戦状ではないですか! Azure の説明に欠けていた、とてつもなく大きな領域が、これで埋まることになるのだと思います。

ーーーーーーーーーーー

Tagged with: , ,
%d bloggers like this: