Agile Cat — in the cloud

Facebook Timeline に集まった、12種類の メディア・アプリとは?

Posted in Entertainment, Facebook by Agile Cat on February 19, 2012

Facebook is Getting Crowded: 12 Media Apps Join Timeline
Alicia Eler / February 16, 2012

_ Read Write

Today Facebook launched 12 media apps for Timeline, joining social news apps such as Yahoo!, Washington Post Social Reader, Digg Social Reader and The Guardian’s social news app.

今日(2/16)、Facebook は Timeline 上で、12種類のメディア・アプリケーションを 立ち上げたが、その中には、Yahoo! および、Washington Post Social ReaderDigg Social Reader、The Guardian といった、ソーシャル・ニュース・アプリケーションも含まれる。

clip_image001[5]Facebook users, do you "like" this? ⇒   

This announcement comes shortly after Facebook launched 60 social apps that focused mostly on cooking, eating, travel, running and reviewing movies. With this bevy of now 80+ social apps, Facebook hopes that its users will think about the platform more as a space for lifestreaming everything rather than just a place for connecting with friends and family members.

このアナウンスメントは、Facebook 上で料理/食事/旅行/運動/映画などにフォーカスする、60 種類のソーシャル・アプリケーションが説明された直後に、手短に発表されている。 こうして、80 種類以上になったソーシャル・アプリケーションを利用することで、単に友人たちや家族といったメンバーとの連絡場所というより、すべてを Life Streaming する空間として、このプラットフォームを捉えてもらいたいと、Facebook は希望している。

Of course, try asking Facebook what it thinks Facebook should be used for, it will not give an answer. Use it for whatever you want. Install these apps if you feel like it. It’s Facebook’s world, sure, but users do have the ability to shape it, or opt-out completely.

もちろん、そのために Facebook が使われる理由について、Facebook に尋ねるべきだが、その答えは得られないだろう。 あなたの望みを実現するためには、何でも利用すべきだ。 つまり、気が向いたなら、それらのアプリケーションをインストールしてみよう。 たしかに Facebook の世界であるが、それを形づくるか、見合わせるかは、ユーザーの判断に委ねられる。

clip_image001One of the apps is viral content site Buzzfeed, which is a shoe in for Facebook. Content from Buzzfeed does remarkably well on Facebook. Especially if it involves adorable pups like this lovely collection of smiling Corgis.

それらのアプリケーションには、伝搬性の高いコンテント・サイトとしての Buzzfeed があるが、それは、まさに、Facebook を歩きまわるためのクツのようなものである。 Buzzfeed から提供されるコンテントなどは、Facebook 上で目立つ存在となるだろう。たとえば、笑う Corgi のコレクションのような、可愛らしい動物を取り込む場合などは、なおさらである。

Two other obvious apps: The Daily Show and MTV News, which both produce short videos that share quite easily on the social network. There are also a few more traditional media sites, such as CBS Local (Los Angeles and New York), and the TODAY Show.

また、The Daily Show MTV News といった、ソーシャル・ネットワーク上で短いビデオを作成し、簡単に共有させていくアプリケーションも出てきた。さらに、CBS Local(Los Angeles and New York)や、 MSNBC.comTODAY Show といった、いくつかの伝統的なメディア・サイトもある。

Social entertainment app GetGlue joins Facebook as well. Already users of GetGlue have the ability to share content to Facebook, so this integration will only strengthen the relationship between the two social platforms.

ソーシャル・エンターテイメント・アプリケーションである GetGlue も、Facebook に参加している。 すでに GetGlue ユーザーは、Facebook にコンテントを共有する能力を持っている。 したがって、このインテグレーションにより、2つのソーシャル・プラットフォームの関係が強化されていくだろう。

Photo sharing site Pixable and CMT (Country Music Television) are also placing bets on Facebook, in the hope that it will make content go even more social.

写真共有サイトである Pixable や、CMT(Country Music Television)なども、コンテントをソーシャル・メディアに提供するために、Facebook に賭けているようだ。

AOL’s SportingNews app will join Facebook in March.

そして、AOL の SportingNews アプリケーションも、3月には Facebook に参加する予定だ。

See Also


TAG index昨年の秋に、Washington Post アプリを動かしたとき、ナルホド便利だと、感心した覚えがあります。 Agile_Cat のページには、この Read Write Web も含めて、いくつかのページが Feed されており、なかなか便利に使っていますが、これからはメディア・アプリとして提供されるものが、多様化していくのですね。 ーーー  __AC Stamp 2



Facebook のブランド・ページは、たった 1% のファンに愛される
Facebook が Timeline をデザインしていく発想は、何処から湧き上がってくるのか?
Facebook Timeline は、データの非正規化という破壊力で誘う
かなり マッド な、Facebook の アケオメ 対策とは?

Cassandra の 2010 年を、Digg への反論も含めて振り返る by Jonathan Ellis

Posted in NoSQL by Agile Cat on March 1, 2011

Apache Cassandra: 2010 in review
Tuesday, January 04, 2011
Posted by Jonathan Ellis at
11:53 AM


Riptano の立ち上げで忙しかったのか、すっかりと更新の途絶えてしまった Spyced ですが、1月に久々のポストがあったことを知りました。 もちろん Jonathan Ellis さんからで、お元気そうで何よりという感じです。 Code、Community、Controversy という三部構成になってますが、3つ目の Controversy は、議論とか物議という意味で、Digg での問題について解説しています。 あの件は、とても大きなダメージなったはずですが、少なくとも Cassandra は、そこから回復しているように思えます。 ーーー __AC Stamp 2


My Photo

In 2010, Apache Cassandra increased its momentum as the leading scalable database. Here is a summary of the notable activity in three areas: code, community and controversy. As always, comments are welcome.

2010年において、Apache Cassandra はスケーラブルなデータベースをリードする存在として勢いを増してきた。 ここでは、注目すべきアクティビティについて、3つのエリアである Code/Community/Controversy に整理しながら概説していく。 いつもの通り、コメントは大歓迎だ。


2010 started with the release of Cassandra 0.5, followed by 0.6 and graduation from the ASF incubator a few months later. Seven more stable releases of 0.6 proceeded, adding many features to improve operations in response to feedback from production users.

2010 年は Cassandra 0.5 のリリースから始まったが、それに 0.6 が続き、また、その数カ月後に ASF インキュベータから卒業することになった。 0.6 のリリースでは、安定化のために 7つのポイントが進化し、運用環境のユーザーからのフィードバックに応えるかたちで、数多くの機能が追加され、オペレーションが改善された。

0.7 adds highly anticipated features like column value indexes, live schema updates, more efficient cluster expansion, and more control over replication, but didn’t quite make it into 2010, with rc4 released on new year’s 2011.

0.7 では、 column value indexeslive schema updates/efficient cluster expansion/more control over replication といった期待どおりの機能が加えられたが、2010年には完了せず、2011年に入ってから、rc4 というかたちでリリースされた

We also committed the distributed counters patchset, begun at Digg and enhanced by Twitter for their real-time analytics product. Notable as the most-involved feature discussion to date, distributed counters started with a vector clock approach, but switched to a new design by Kelvin Kakugawa after we realized vector clocks were a dead end for anything but the trivial case of monotonic-increments-by-one.

さらに、私たちは、Digg で始まり、Twitter のリアルタイム分析プロダクトで拡張された、distributed counters patchset にも責任を持つことになった。現時点において、もっとも時間を費やして議論されたものとして、vector clock approach を用いて開始される distributed counters に注目すべきだが、vector clock が自身で単調にインクリメントすることを除いて、すでに手詰まりとなっていることに気づいた後、Kelvin Kakugawa新たにデザインすることになった。

One of the biggest trends was increasing activity around Cassandra as well as in the core database itself. 2010 saw Hadoop map/reduce integration, as well as Pig support and apatch for Hive.

Cassandra に関連するアクティビティを増やすだけではなく、そのコア・データベース自身のアクティビティも増やしていくことが、最も大きな流れとなった。 2010 年に行われた Hadoop Map/Rerduce とのインテグレーションと同様に、Pig のサポートと、Hive へのパッチが推進された。

We also saw Lucandra, which implements a Cassandra back end for Lucene and is used in several high volume production sites, grow up into Solandra, embedding Solr and Cassandra in the same JVM for even more performance.

さらに、Lucene のバックエンドとして Cassandra を実装する、Lucandra にも注目した。それは、Solandra で成長する、いくつかのハイ・ボリューム実運用サイトで用いられ、さらなるパフォーマンスのために、 Solr と Cassandra を同一の JVM にエンベッドするものである。



Cassandra hit its stride in 2010, starting with graduation from the ASF incubator in April. 2010 saw 1025 tickets resolved, nearly twice as many compared to 2009 (565).

2010年 4月に、Cassandra は ASF インキュベーションから卒業し、その歩みを始めた。 また、2010 年には 1025 枚のチケットが解決されたが、それは、2009年(565)の 約 2倍近に匹敵するものだ。

Like many Apache projects, Cassandra has a relatively small set of committers, but a much larger group of contributors. In 2010 Cassandra passed over 100 people who have contributed at least one patch. Release manager Eric Evans put together a great way to visual this with a Code Swarm video of Cassandra development.

数多くの Apache プロジェクトと同様に、Cassandra のグループは、少数のコミッターと多数のコントリビューターにより構成されている。 2010年に Cassandra は、少なくとも 1つのパッチをコントリビュートした、100名以上の人々の手を通過した。 リリース・マネージャーである Eric Evans は、Cassandra 開発に関する Code Swarm ビデオを用いて、そのプロセスをビジュアライズするという、素晴らしい方式を作り上げた。

I started Riptano with Matt Pfeil in April to provide professional products and services around Cassandra. In October, we announced funding from Lightspeed and Sequoia. From May to December, we conducted eleven Cassandra training events in eight months, and twice that many private classes on-site with customers.

私に関しては、Cassandra に関連するプロフェッショナルなプロダクトとサービスを提供するために、Matt Pfeil と一緒になって、4月に Riptano を立ち上げた。 10月には、Lightspeed と Sequoia からのファンドについて発表した。 5月から 12月までの 8ヶ月間において、11回の Cassandra のトレーニング・イベントを開催し、また、顧客のオンサイトでは、その 2倍のプライベート・クラスを開催した。

Riptano is now up to 25 employees, with offices in the San Francisco bay area, Austin, and New York, and engineers working remotely in San Antonio, France, and Belarus.

いまでは、Riptano は、San Francisco Bay Area と、 Austin、New York にオフィスを構え、25人の従業員を有している。そして、エンジニアたちは、San Antonio と、France、Belarus においてリモートで作業している。

In August, Riptano and Rackspace organized a very successful inaugural Cassandra Summit, with about 200 attendees (videos available), followed by almost a full track at ApacheCon in November. Cassandra was also represented at many other conferences onmultiple subjects, for several languages, and continents.

8月には、Riptano と Rackspace は共同で Cassandra Summit(ビデオ)を開催し、200名の参加者を集めるという大成功をおさめた。それに続いて、11月の ApacheCon では、Summit のほぼフル・トラックを再演した。 さらに Cassandra は、いくつかの国々に置いて、数多くのテーマを提供するカンファレンスを開催した。


Cassandra got a lot of negative publicity when Kevin Rose blamed Cassandra for Digg v4’s teething problems. However, there was no deluge of bug reports coming out of Digg’s Cassandra team, and Digg engineers Arin Sarkissian and Chris Goffinet (now working on Cassandra for Twitter) got on Quora to refute the idea that Cassandra was at fault:

Digg v4 の初期問題について Kevin Rose が Cassandra の責を追求したときには、多くのネガティブ効果が生じてしまった。 しかし、Digg の Cassandra チームから、大量のバグ・レポートが送られることはなかった。そして、Digg のエンジニアである Arin Sarkissian と Chris Goffinet(Cassandra for Twitter チーム)が Quora 上にで、Cassandra が間違っていたという考え方に対して反論している

The whole "Cassandra to blame" thing is 100% a result of folks clinging on to the NoSQL vs SQL thing. It’s a red herring.

その「 Cassandra への批判 」は、「 NoSQL 対 SQL 」 に執着する人々の視点で、100% が埋め尽くされている。 つまり、目を逸らすためのオトリにされたわけだ。

The new version of Digg has a whole new architecture with a bunch of technologies involved. Problem is, over the last few months or so the only technological change we mentioned (blogged about etc) was Cassandra. That made it pretty easy for folks to cling on to it as the "problem".

この Digg の新しいバージョンは、いくつかのテクノロジーを組み合わせた、まったく新しいアーキテクチャを持っている。 問題なのは、この数カ月にわたって、私たちが(ブログなどで)言及した唯一の技術的な変更点が、Cassandra であったことだ。そのことが、「問題」として指摘しやすい状況を作ってしまった。

Meanwhile, Digg competitor Reddit has continued migrating to Cassandra, crediting it with enabling their 3x traffic growth in 2010.

その一方で、Digg 競争相手である Reddit は、Cassandra への移行を継続しており、2010年に 3倍のトラフィックに成長したサービスで、Cassandra が機能していることを認めている。

More importantly, 2010 saw dozens of new Cassandra deployments, including a new contender for the largest-cluster crown when Digital Reasoning announced a 400-node cluster for the US government.

それより重要なことは、2010年に、いくつかの新規 Cassandra ディプロイメントが実現したことだ。そこには、Digital Reasoning が米国政府用の 400ノード・クラスタを発表したとき、その最大クラスタの新しい候補として、選ばれたことも含まれる。

We look forward to another great year in 2011!


先日に、『 Cassandra の Riptano は、DataStax に買収されてしまったの? 』というタイトルでポストしましたが、今回 ご紹介する Spyced のポストの直後に、DataStax に社名変更されたということなのでしょうね。ーーー __AC Stamp 2


Cassandra はアメリカ政府に食い込み、Amazon EC2 でも利用できる
Cassandra Summit 2010 でのスライドとビデオが公開
Real World NoSQL シリーズ – Openwave における Cassandra
NoSQL のユースケースを一般論と具体論で整理する
Windows Azure チームは、どのような興味を Cassandra に持っているのか?

Digg は Cassandra を、あきらめていないようだが・・・

Posted in Big Data, NoSQL by Agile Cat on September 10, 2010

Digg Not Likely to Give Up on Cassandra
Stacey Higginbotham
Sep. 8, 2010, 12:01am PDT


Cassandra was a tragic figure in Greek myth — she could hear the future and thus was able to foretell what was coming next (usually death and destruction). It’s no surprise that no one wanted her hanging around. It’s ironic that an open source NoSQL software of the same name has often found itself amidst controversy. Today, Cassandra was blamed for scaling (and availability) problems at Digg, which led to the yet-unconfirmed departure of Digg VP of Engineering John Quinn, who was a big champion of Cassandra at Digg.

Cassandra は、ギリシャの神話で悲劇の主人公である。彼女は、予知能力を持ち、次に来るものを(通常は死と破壊)を予言できた。 したがって、彼女が誰にも好まれなかったとこは、驚きではない。 同じ名前のオープンソース NoSQL ソフトウェアが、それ自身をめぐる論争の中に、しばしば見出されるのは皮肉である。 現時点において、Digg での Cassandra はスケール(と可用性)の問題を追求されている。それは、Digg で Cassandra を推進していた、VP of Engineering である John Quinn の、離脱をも導くのかも知れない。


This is not the first time Cassandra — which was created inside Facebook and later open sourced — is taking a beating. Back in July, Twitter reversed its plans to move from MySQL to Cassandra for storing its tweets. Comments by Digg founder Kevin Rose as he tries to explain some problems on Digg’s new site aren’t helping either. But a call to Matt Pfeil, CEO of Riptano — an Austin, Texas-based startup — put thing in perspective. Riptano is building its business providing service and eventually an easy-to-implement version of Cassandra for companies (see my video interview with Pfeil here.) Pfeil said that Riptano is working with Digg and noted that he would be “shocked” if Digg abandoned Cassandra.

Cassandra (Facebook で開発された後にオープンソース化された)が批判されるのは、これが始めてではない。 Twitter は 7月に、そのツイートのストアを MySQL からCassandra へと移行する計画を変更した。 Digg の創設者である Kevin Rose は、Digg の新しいサイトにおける若干の問題を説明したときも、Cassandra を助けるようなコメントは発していない。 しかし、Riptano( Austin, Texas のスタートアップ)の CEO である Matt Pfeil は、全体的な視野で見ている。 Riptano は、サービス提供を推進しており、最終的には実装の容易なバージョンの Cassandra を、企業向けに提供する。Pfeil とのビデオ・インタビューを参照して欲しい)。 Pfeil は、Riptano が Digg と協調しているとし、もし Digg がCassandra を捨てるなら、「ショックを受ける」を発言している。

When asked if the problems Digg has had with its upgrade stemmed from Cassandra, Pfeil said, “We’ve reached out to Digg to ID what those problems are. I don’t know the full extent of them, and am learning more from them about their situation. We know Cassandra can scale to levels that are equal to or greater than a Digg is putting on it and I have full faith in Cassandra, but there are these little knobs that need to be tuned and you have to know where they are.”

Digg における問題が、Cassandra のアップグレードから生じているのかと尋ねられたとき、それらの問題を識別するために Digg に手を差し伸べた。 私には全容を掴むことは不可能であり、彼等の状況を理解するほかにない。 私たちの認識では、Digg が必要とするレベルのスケールを、Cassandra は有している。そして、Cassandra を完全に信頼している。 しかし、いくつかの調整が必要なポイントがあり、その場所を知らなくてはならない 」と、Pfeil は発言している。

For Pfeil this could be an opportunity simply because helping find and turn “those little knobs” are what Riptano was formed to do. He said Riptano has been involved with Digg since around April, which was soon after Digg announced its plans to use Cassandra. And while Digg may be able to blame Cassandra for some glitches, the database technology still seems to be on the upswing. Today, Quest — an enterprise software-database support company — decided to support Cassandra through a partnership with Riptano, and companies such as Cisco, Ooyala and Rackspace are also using it.

Pfeil にとって、「それらの小さなおポイント」を見いだし、調整を支援していくことは、シンプルなチャンスであり、Riptano が構成された理由でもある。 彼が言うには、Riptano が 4月ごろから Digg と連携しているが、それは Digg が Cassandra を使用するという計画を、発表した直後にあたる。 そして Digg における若干の問題について、Cassandra が責任を追求されるかもしてない状況においても、このデータベース・テクノロジーは、依然として急上昇の途にある。 今日のことだが、エンタープライズ向けにデータベースをサポートしている Quest が、Riptano との協力により Cassandra をサポートすると決定した。さらに、Cisco/Ooyala/Rackspace といった企業も、Cassandra を使用している。

As Pfeil points out, Cassandra is still new, having been open sourced in 2008. “Cassandra has come a long way, especially in the last year or so … there is a lot to be done before it is close to where it will compare in production environments to something like MySQL, but we’re getting close.” So maybe unlike the Greek prophetess, the database technology will be able to rehabilitate its reputation.

Pfeil は、Cassandra は 2008年にオープン化され、まだ新しいと指摘する。 「とりわけ昨年は、Cassandra にとって大きな進展の年であった。そして、MySQL のようなプロダクション環境と比較できるようになるために、多くのことが行われてきた。そして、私たちは、そこに近づいている」 おそらく、ギリシャ神話の預言者と異なり、このデータベーステ・クノロジーは、自信の評判を回復していくだろう。

Related GigaOM Pro research (sub req’d): Report: NoSQL Databases – Providing Extreme Scale and Flexibility


なにかと不安視されていた Cassandra ですが、Riptano が機能することで、さまざまな問題が改善されていくと、とてもイイですね! ーーー A.C.


Cassandra Summit 2010 でのスライドとビデオが公開
Facebook、Twitter、Digg などでの Cassandra の状況について
yoshiyuki kanno さんの Apache Cassandra 用語集(日本語版)
Cassandra をサポートする Riptano が始動
Digg が Cassandra を採用する理由 by John Quinn

Facebook、Twitter、Digg などでの Cassandra の状況について

Posted in Facebook, NoSQL, Twitter by Agile Cat on July 9, 2010

Cassandra Status Inside Facebook, Twitter, Digg, and More
Posted on
July 7th, 201014:19 by Alex Popescu


As everyone probably knows by now, Cassandra was originated at Facebook as a solution for inbox search and then open sourced under the ASF umbrella and an Apache license. Since then, Twitter, Digg, Reddit and quite a few others started using it, but not much have been heard from Facebook.

おそらく、すべての人々が認識しているように、Cassandra は Facebook において Inbox サーチのために作り出され、その後に ASF と Apache ライセンスのもとでオープンソース化されている。 そして、Twitter や、Digg、Reddit などの、いくつかの企業が利用を開始しているが、Facebook からの情報は聞こえてこない。

So, in case you are wondering ☞ what’s up with Cassandra here’s a very concise update:

何のことだろうと思うなら、この簡潔なアップデートを参照して欲しい: ☞ what’s up with Cassandra

  1. Twitter and Digg are not planning to fork the project. In fact there are clear plans to contribute back their work on Cassandra (see this for more details)

    Twitter と Digg は、このプロジェクトの枝分かれを望んでいるわけではない。 実際に、Cassandra における彼らの作業を、コントリビューションとして戻す計画が明らかにされている(参照 this for more details)。

  2. Facebook is still using Cassandra internally for the inbox search, but they are using their own version

    Facebook は依然として、Inbox サーチのために Cassandra を内部利用しているが、彼らの独自のバージョンを使用している。

  3. even if except the initial code share Facebook has stopped contributing to the Cassandra project, the community on ASF is doing well (read growing)

    Facebook が Cassandra ブロジェクトに対して、最初のコード・シェアを停止しているという状況を別にしても、ASF のコミュニティは、上手く成長していくだろう。

  4. Riptano, the company founded by Cassandra project lead Jonathan Ellis and Matt Pfeil, is offering technical support, professional services, and training for Cassandra

    Jonathan Ellis と Matt Pfeil が主導する Cassandra プロジェクトとして、資金調達した Riptano 社は、テクニカル・サポートおよび、プロフェッショナル・サービス、トレーニングを提供している。

Reading List:


Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
わずか四半期の間に、サーバー数が倍増した Facebook の事情
Facebook の HDFS クラスターは 21 PB !!!
Facebook のスケール感覚に驚愕!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
Twitter が Cassandra を選んだ理由 — MyNoSQL
yoshiyuki kanno さんの Apache Cassandra 用語集(日本語版)
Digg が Cassandra を採用する理由 by John Quinn
Cassandra をサポートする Riptano が始動


Cassandra:6つの迷信と 6つの真実

Posted in NoSQL by Agile Cat on April 13, 2010

Cassandra: Fact vs fiction
Jonathan Ellis
Wednesday, April 07, 2010

imageCassandra has seen some impressive adoption success  over the past months, leading some to conclude that Cassandra is the frontrunner  in the highly scalable databases space (a subset of the hot NoSQL category ). Among all the attention, some misunderstandings have been propagated, which I’d like to clear up.

この数カ月の間に、Cassandra 運用における成功を印象付ける事例が紹介され、ハイ・スケーラブルなデータベース領域(ホットな  NoSQL category  のサブセット)では、Cassandra が最先端であるという、いくつかの結論がもたらされた。こうした注目は喜ぶべきものだが、いくつかの誤解が広まっているので、以下に修正する。


Fiction_1: "Cassandra relies on high-speed fiber between datacenters" and can’t reliably replicate between datacenters with more than a few ms of latency between them.

Fiction_1: ”Cassandra はデータセンター間をつなぐ、高速のファイバーに依存する"。 そして、データセンター間を数ミリ秒レベルのレイテンシー接続し、信頼性のあるリプリケーションを行うことは不可能である。

Fact_1: Cassandra’s multi-datacenter replication is one of its earliest features and is by far the most battle-tested in the NoSQL space. Facebook had Cassandra deployed on east and west coast datacenters since before open sourcing it. SimpleGeo’s Cassandra cluster spans 3 EC2 availability zones , and Digg is also deployed on both coasts. Claims that this can’t possibly work are an excellent sign that you’re reading an article by someone who doesn’t know what he’s talking about.

Fact_1: Cassandra のマルチ・データセンター・リプリケーションは、その初期からの特徴の1つであり、NoSQL スペースでのバトルにより検証されている。 Facebook は Cassandra をオープンソースかする以前から、東海岸と西海岸のデータセンター間にディプロイしている。 SimpleGeo の Cassandra クラスタは、EC2 における 3つの利用ゾーンをまたぎ、また、Digg も東西の海岸にディプロイしている。 それが上手くいかないという主張は、意味のわからない記事を書く、筆者を探し出すための、便利なサインとなる。

Fiction_2: "It’s impossible to tell when [Cassandra] replicas will be up-to-date."

Fiction_2: Cassandra レプリカがアップデートされるタイミングを、知らせることができない。

Fact_2: Cassandra provides consistency when R + W > N (read replica count + write replica count > replication factor), to use the Dynamo vocabulary . If you do writes and reads both with QUORUM, for one example, you can expect data consistency as soon as there are enough reachable nodes for a quorum. Cassandra also provides read repair  and anti-entropy , so that even reads at ConsistencyLevel.ONE  will be consistent after either of these events.

Fact_2: Cassandra は Dynamo 用語を用いて、 R + W > N (read replica count + write replica count > replication factor) のときにコンシステンシーを提供する。たとえば、QUORUM を用いて write/read を行うとき、その最小数に到達する充分なノードがある場合には直ちに、データのコンシステンシーが可能になる。 さらに Cassandra では read repairanti-entropy を提供することで、ConsistencyLevel.ONE におけるread であっても、それらのイベントの後にコンシステンシーが行われる。

Fiction_3: Cassandra has a small community

Fiction_3: Cassandra は小規模なコミュニティを有している。

Fact_3: Although popularity has never been a good metric for determining correctness, it’s true that when using bleeding edge technology, it’s good to have company. As I write this late at night (in the USA), there are 175 people in the Cassandra irc channel, 60 in the HBase one, 32 in Riak’s, and 15 in Voldemort’s. (Six months ago, the numbers were 90, 45, and 12 for Cassandra, HBase, and Voldemort. I did not hang out in #riak yet then.) Mailing list participation tells a similar story. It’s also interesting that the creators of Thrudb   and dynomite   are both using Cassandra now, indicating that the predicted NoSQL consolidation is beginning.

Fact_3: 人気に応じて正当性を決定することは、適切な基準といえないが、最先端のテクノロジーを用いるときに、仲間を持つことが有益だというのは真実だ。 このポストを夜中に(USA 時間) に書いているときに、 Cassandra irc channel には 175人、そして HBase には 60人、Voldemort には 15人が居る。 (6カ月前には、Cassandra が 90人、HBase が 45人、Voldemort には 12人だった。 そのときには、#riak は使っていなかった) メーリング・リストへの参加も、類似のストーリーを物語っている。また、Thrudb  と dynomite のクリエーターが Cassandra を使用しており、予測されていた NoSQL コンソリデーションの、始まりを示している点も興味深い。

Fiction_4: "Cassandra only supports one [keyspace] per install."

Fiction_4: "Cassandra は、インストールごとに 1つの [keyspace] だけをサポートする"。

Fact_4: This has not been true for almost a year (June of 2009 ).

Fact_4: それは真実ではない  (June of 2009 )。

Fiction_5: Cassandra cannot support Hadoop, or supporting tools such as Pig.

Fiction_5: Cassandra は、Hadoop および、Pig などのサポーティング・ツールに対応できない。

Fact_5: It has always been straightforward to send the output of Hadoop jobs to Cassandra, and Facebook, Digg, and others have been using Hadoop like this as a Cassandra bulk-loader for over a year. For 0.6, I contributed a Hadoop InputFormat and related code to let Hadoop jobs process data from Cassandra  as well, while cooperating with Hadoop to keep processing on the nodes that actually hold the data. Stu Hood then contributed a Pig LoadFunc, also in 0.6.

Fact_5: Hadoop ジョブ出力の Cassandra への送信は簡単であり、Facebook や Digg などは、この一年の間に、 Cassandra bulk-loader のようなかたちで、Hadoop を使用している。Cassandra の 0.6 に関して、そのデータを Hadoop ジョブに処理させるために、私は Hadoop InputFormat と関連するコードをコントリビュートしている。 それらは、実際にデータを保持しているノード上で、Hadoop による処理を、協調して行わせるためのものである。0.6 において、Stu Hood も Pig LoadFunc をコントリビュートしている。

Fiction_6: Cassandra achieves its high performance by sacrificing reliability (alternately phrased: Cassandra is only good for data you can afford to lose)

Fiction_6: Cassandra は、その信頼性を犠牲にすることで、ハイ・パフォーマンスを得ている(言い換えれば:Cassandra は、失っても構わないデータに適している)。

Fact_6: unlike some NoSQL databases (notably MongoDB  and HBase ), Cassandra offers full single-server durability . Relying on replication is not sufficient for can’t-afford-to-lose-data scenarios; if your data center loses power, you are highly likely to lose data if you are not syncing to disk no matter how many replicas you have, and if you run large systems in production long enough, you will realize that power outages through some combination of equipment failure and human error are not occurrences you can ignore. But with its fsync ‘d commitlog  design, Cassandra can protect you against that scenario too. What to do after your data is saved, e.g. backups and snapshots, is outside of my scope here but covered in the operations wiki page .

Fact_6: いくつかの NoSQL データベース(とりわけ MongoDBHBase )とは異なり、Cassandra は  full single-server durability を提供する。リプリケーションへの依存は、can’t-afford-to-lose-data シナリオを完全に充たすものではない。 つまり、データセンターが停電してしまった際に、どれだけのレプリカを持っていようとも、ディスクとの同期をとっておかなければ、データを失う可能性が高い。そして、大規模システムを、きわめて長い期間で運用する場合には、いくつかの装置の故障や、人為的なミスの組み合わせによる停電が、無視できない事象だと理解するだろう。しかし、Cassandra では、その fsync ‘d commitlog デザインにより、そのようなシナリオにおいても、データを保護することができる。たとえば、backup や snapshot によりデータを保存した後に行うべきことは、ここでのスコープから外れたものとなるが、operations wiki page においてカバーされている。


かなり気になる、NoSQL 関連のポスト : Cassandra や CAP Theorem など
Cassandra ライブ情報がテンコ盛り – Jonathan Ellis @ Rackspace
Twitter が Cassandra を選んだ理由 — MyNoSQL
Digg が Cassandra を採用する理由 by John Quinn
High Scalability のホット・リンク集 : Cassandra@Twitter インタビューもあるよ!
Cassandra 分散データベースでの削除とは?
Cassandra プロジェクトと Rackspace
イベンチュアル・コンシステンシーはお好き? by James Hamilton

Cassandra ライブ情報がテンコ盛り – Jonathan Ellis @ Rackspace

Posted in NoSQL by Agile Cat on March 26, 2010

Cassandra in action
Jonathan Ellis
Wednesday, March 24, 2010


There’s been a lot of new articles about Cassandra deployments in the past month, enough that I thought it would be useful to summarize in a post.

この 1ヶ月の間に、Cassandra のディプロイメントについて、このポストで要約するに値する、数多くの記事があった。

Ryan King explained in an interview with Alex Popescu why Twitter is moving to Cassandra for tweet storage, and why they selected Cassandra over the alternatives. My experience is that the more someone understands large systems and the problems you can run into with them from an operational standpoint, the more likely they are to choose Cassandra when doing this kind of evaluation. Ryan’s list of criteria is worth checking out.

この 1ヶ月の間に、Cassandra のディプロイメントについて、このポストで要約するに値する、数多くの記事があった。 Ryan King は Alex Popescu のインタビューにおいて、Twitter が tweet ストレージのために、Cassandra へ移行したわけと、その選択理由を説明している。 大規模なシステムや問題を、より多くの人々が運用面での視点から理解すると、この種のテクノロジーを評価をする際に、Cassandra を選ぶ可能性が高まるといのが、私の経験である。Ryan が提供する、基準に関するチェック・リストには価値がある。

Digg followed up their earlier announcement that they had taken part of their site live on Cassandra with another saying that they’ve now "reimplemented most of Digg’s functionality using Cassandra as our primary datastore." Digg engineer Ian Eure also gave some more details on Digg’s cassandra data model in a Hacker News thread.

Digg は、Cassandra に関する以前のアナウンスメントをフォローアップした。それは、彼らのサイトで Cassandra などが運用されているというものだ。言い方を変えると、Digg における大半の機能を、Cassandra を主要なデータストアとして用いる方式へ向けて、再実装していることになる。 Digg のエンジニアイアンである Ian Eure は、Hacker News スレッドで、Digg の Cassandra データ・モデルについて詳細を提供している。

Om Malik quoted extensively from the Digg announcement and from Rackspace engineer Stu Hood, who explained Cassandra’s appeal: "Over the Bigtable clones, Cassandra has huge high-availability advantages, and no single point of failure. When compared to the Dynamo adherents, Cassandra has the advantage of a more advanced datamodel, allowing for a single row to contain billions of column/value pairs: enough to fill a machine. You also get efficient range queries for the top level key, and even within your values."

Om Malik は、この Digg の発表と、Rackspace のエンジニア Stu Hood のコメントを基に、Chassandra の周辺についてまとめている。そして、Cassandra は Bigtable クローン上に構築されるものであるが、高可用性とシングル・フェイル・ポイントの排除というアドバンテージを持つと説明している。また、 Dynamo との比較において、Cassandra は、さらに進歩したデータモデルというアドバンテージを持ち、マシンを埋め尽くすほどの何十億という column/value ペアの、シングル Row への取り込みを実現する。 そして、トップレベルのキーから、個別の値にいたるまで、効果的なレンジでのクエリーを取得すると説明している。

The Twitter and Digg news kicked off a lot of publicity, including a lot of "me too" articles but some interesting ones, including a highscalability post wondering if this was the end of the mysql + memcached era. If not quite yet the end, then the beginning of it. As Ian Eure from Digg said, "If you’re deploying memcache on top of your database, you’re inventing your own ad-hoc, difficult to maintain NoSQL system. Possibly the best commentary on this idea is Dare Obasanjo’s, who explained "Digg’s usage of Cassandra actually serves as a rebuttal to [an article claiming SQL scales just fine] since they couldn’t feasibly get what they want with either horizontal or vertical scaling of their relational database-based solution."

Twitter と Digg ニュースは、多数の Me Too を含む、大規模なパブリシティを生み出した。しかし、Highscalability を含む、いくつかの興味深いポストには、mysql+memcached 時代の終わりを匂わすものもあった。 それが、終わりを示すものでないなら、新しい始まりを示すのだろう。 Digg の Ian Eure は、データベース上に memcache を実装しているなら、独自のアドホックを考案しているのであり、NoSQL システムで維持していくことは困難だと言っている。 また、この件については、Dare Obasanjo のコメントが最適だとも発言している。そこでは、Digg における Cassandra の用法は、「SQL のスケールがちょうど良いと主張する記事」 への反論としての、現実的なサービスだと、Dare は発言していると言う。なぜなら、Digg においては、水平であろうが垂直であろうが、リレーショナル・データベースに基づくソリューションでは、現実的な答にならないからだ。

Reddit also migrated to Cassandra from memcachedb, in only 10 days, the fastest migration to Cassandra I’ve seen. More comments from the engineer doing the migration, ketralnis, in the reddit discussion thread.

Reddit においても、memcachedb から Cassandra への移行があった。それを 10日間で完了するのは、私が見た限りでは最速である。 この、Reddit のディスカッション・スレッドには、ketralnis たちを含むエンジニアからのコメントが掲載されている。

CloudKick blogged about how they use Cassandra for time series data, including a sketch of their data model. CloudKick migrated from PostgreSQL, skewering the theory you will sometimes see proffered that "only MySQL users are migrating to NoSQL, not people who use [my favorite vendor’s relational database]."

CloudKick は、自身のデータ・モデルのスケッチも含めて、時系列データに対して Cassandra を用いる方法をブログで説明している。 CloudKick は PostgreSQL から移行しており、MySQL ユーザーだけが NoSQL へ移行できるのであり、ベンダー系のリレーショナル・データベースからは不可能だという、ときおり目にするセオリーを酷評している。

Jake Luciani wrote about how Lucandra, the Cassandra Lucene back-end works, and how he’s using it to power the Twitter search app IMO, Lucandra is one of Cassandra’s killer apps.

Jake Luciani は Lucandra での事例に触れている。Cassandra は Lucene のバックエンドを担当しており、Twitter のサーチ・アプリケーションである にパワーを与えているという。 私の意見では、 Lucandra は Cassandra におけるキラー・ソフトウェアの 1つとなる。

The FightMyMonster team switched from HBase to Cassandra after concluding that "HBase is more suitable for data warehousing, and large scale data processing and analysis… and Cassandra is more suitable for real time transaction processing and the serving of interactive data." Dominic covers CAP, architecture considerations, benchmarks, map/reduce, and durability in explaining his conclusion.

FightMyMonster チームは、「HBase がデータウエア・ハウジングおよび、大規模データの処理と分析に最適であり、Cassandra はリアルタイム・トランザクションとインタラクティブ・データのサポートに最適」と結論付けた後に、 HBase から Cassandra へと移行している。Dominic の説明では、CAP および 、アーキテクチャの考察、ベンチマーク、Map/Reduce、耐久性がカバーされると結論づけられている。

Eric Peters gave a talk on Cassandra use at his company, Frugal Mechanic, at the Seattle Tech Startups Meetup. This was interesting not because Frugal Mechanic is a big name but because it’s not. I haven’t seen Eric’s name on the Cassandra mailing lists at all, but there he was deploying it and giving a talk on it, showing that Cassandra is starting to move beyond early adopters. (And, just maybe, that our documentation is improving. :)

Eric Peters は Seattle Tech Startups Meetup において、彼の Frugal Mechanic での Cassandra の利用について発言している。 興味深いのは、Frugal Mechanic が有名ではなく無名だからだ。 Cassandra びメーリング・リストで Eric の名前を見かけたことが無かったが、そのときには Cassandra をディプロイし、説明したのだ。 Cassandra がアーリー・アダプタの範囲を超え始めたのだ。 (そして、おそらく、私たちのドキュメントも改善されていはず、、、:)

Finally, Eric Florenzano has a live demo up now of Cassandra running a Twitter clone at, with source at github, as an example of how to use Cassandra’s data model. If you’re interested in the nuts and bolts of how to build an app on Cassandra, you should check it out.

最後になるが、Eric Florenzano の Twitter クローンである、 を紹介したい。 そのソースは github にあり、Cassandra でのデータ・モデルの使い方を示している。 もし、Cassandra 上でアプリケーションを作成する基本に興味があるなら、それをチェックするべきだ。


なんか、ブレークしちゃった感じですね、Cassandra は ーーー A.C.

Twitter が Cassandra を選んだ理由 — MyNoSQL (← これが、そもそもの発端です)
Digg が Cassandra を採用する理由 by John Quinn
High Scalability のホット・リンク集 : Cassandra@Twitter インタビューもあるよ!
Cassandra 分散データベースでの削除とは?
Cassandra プロジェクトと Rackspace
イベンチュアル・コンシステンシーはお好き? by James Hamilton

Digg が Cassandra を採用する理由 by John Quinn

Posted in NoSQL, Parallel by Agile Cat on March 14, 2010

Saying Yes to NoSQL; Going Steady with Cassandra


clip_image002 by John Quinn on March 9, 2010 – 3:42am

The last six months have been exciting for Digg’s engineering team. We’re working on a soup-to-nuts rewrite. Not only are we rewriting all our application code, but we’re also rolling out a new client and server architecture. And if that doesn’t sound like a big enough challenge, we’re replacing most of our infrastructure components and moving away from LAMP.

この 6ヶ月は、Diggのエンジニアリング・チームにとって刺激的な期間だった。 私たちは、何から何までリライトする方針で突き進んでいる。すべてのアプリケーション・コードをリライトするだけではなく、新しいクライアント/サーバー型のアーキテクチャという大きな改善もある。さらに、それが大きなチャレンジに値しないなら、私たちは LAMP から離れて、大半のインフラストラクチャ・コンポーネントを置き換える。

Perhaps our most significant infrastructure change is abandoning MySQL in favor of a NoSQL alternative. To someone like me who’s been building systems almost exclusively on relational databases for almost 20 years, this feels like a bold move.

おそらく、最も重要なインフラストラクチャの変更とは、MySQL を断念する替りに、NoSQLへの取り組みを推進することだ。20年間にわたって、ほとんどのシステム構築をリレーショナル・データベースで行ってきた人々にとって、それは大きな転換に感じるだろう。

What’s Wrong with MySQL?

Our primary motivation for moving away from MySQL is the increasing difficulty of building a high performance, write intensive, application on a data set that is growing quickly, with no end in sight. This growth has forced us into horizontal and vertical partitioning strategies that have eliminated most of the value of a relational database, while still incurring all the overhead.


Relational database technology can be a blunt instrument and we’re motivated to find a tool that matches our specific needs closely. Our domain area, news, doesn’t exact strict consistency requirements, so (according to Brewer’s theorem) relaxing this allows gains in availability and partition tolerance (i.e. operations completing, even in degraded system states). We’re confident that our engineers can implement application level consistency controls much more efficiently than MySQL does generically.

リレーショナル・データベースのテクノロジーが、最先端のものではなくなるのかもしれない。そして、私たちは、ニーズに合ったツールを探す必要性が生じた。私たちのドメインであるニュースは、厳密なコンシステンシーを必要としない。そのため、(ブラウザの定理にしたがって)コンシステンシーを緩和することで、可用性とパーティションの許容範囲が広がることになる(たとえば、システム・ステートの縮小においても操作を完了)。一般的な MySQL よりも効果的な、アプリケーション・レベルでのコンシステンシー制御を実装できると、私たちは確信している。

As our system grows, it’s important for us to span multiple data centers for redundancy and network performance and to add capacity or replace failed nodes with no downtime. We plan to continue using commodity hardware, and to continue assuming that it will fail regularly. All of this is increasingly difficult with MySQL.

このシステムが成長するにつれて、複数のデータセンターをまたいだ冗長性とネットワーク・パフォーマンスと、ダウンタイムを排除したキャパシティの拡張と、障害ノードの置換えが重要になる。私たちは、コモディティ・ハードウェアを使用し続け、それらが故障することを前提にして、システムの構築を計画している。 それらすべてが、MySQLの場合だと、困難さが増大していく。

Choosing an Alternative

Digg is committed to the use and development of open source software and we’re keen to avoid the cost of proprietary large-scale storage solutions. We were inspired by Google and Amazon’s broad use of their non-relational BigTable and Dynamo systems. We evaluated all the usual open source NoSQL suspects. After considerable debate, we decided to go with Cassandra.

Diggではオープンソース・ソフトウェアの利用と開発が約束されており、大規模ストレージにおけるプロプライエタリなソリューションを避けることに、私たちは鋭敏である。 そして、 Google と Amazon におけるBigTable と Dynamo が、ノン・リレーショナルなシステムとして、幅広く使用されていることに触発されている。また、すべてのオープンソースNoSQLの候補を評価した。 その結果として、充分なディスカッションを経て、Cassandraを選ぶことにした。

Simplistically, Cassandra is a distributed database with a BigTable data model running on a Dynamo like infrastructure. It is column-oriented and allows for the storage of relatively structured data. It has a fully decentralized model; every node is identical and there is no single point of failure. It’s also extremely fault tolerant; data is replicated to multiple nodes and across data centers. Cassandra is also very elastic; read and write throughput increase linearly as new machines are added.

Cassandraを簡単に説明すると、Dynamo に似たインフラストラクチャ上で稼働する、BigTableデータ。モデルを用いた分散型データベースとなる。そして、カラム指向の、相対的に構造化されたデータ・ストアを実現する。さらに、完全な非センタライズ化されたモデルを有し、あらゆるノードは同一レベルにあり、シングル・フェイル・ポイントが無い。また、マルチ・ノードで複製され、データセンターをまたぐデータにより、きわめて高度なフォールト・トレランスが実現される。それに加えて、Cassandraはきわめてエラスティックであり、Read/Write のスループットはリニアに向上し、新しいマシンの追加も容易である。

We experimented on our live site, replacing a relatively high scale MySQL component with a Cassandra alernative. These tests went well. You can read more about these experiments here.

私たちの実運用環境での実験において、比較的に高いスケールを持つ MySQL を Cassandraで置き換えてみた。その結果は良好であり、詳細については ココ で参照できる。

Where We Are

At the time of writing, we’ve reimplemented most of Digg’s functionality using Cassandra as our primary datastore. We’ve supplemented Cassandra-based indexing using full text, relational and graph indexing systems. We’re getting used to dealing with eventual consistency.

この現稿を執筆しているときに、私たちはプライマリのデータ・ストアとしての大半の Digg の機能を、Cassandraを用いて再実装している。そして、フル・テキストおよび、リレーショナル、グラフ・インデックス・システムを用いて、Cassandraベースのインデックスを補完している。

We’ve been working on Cassandra itself too. We’ve made massive performance improvements: increased comparitor speed, added better compaction threading, reduced logging overhead, added row-level caching and implemented multi-get capability. We’ve also implemented native atomic counters using Zookeeper (you can probably guess why were motivated to add that feature :)

つまり、Cassandra自身に対する取り組みも継続してきた。それにより、comparitor 速度の向上および、より適切なcompaction スレッドの追加、 ログ・オーバーヘッド の低減、低レベル・キャッシュの追加、multi-get キャパシティの実装といった、大きな改善を達成してきた。さらに、Zookeeper を用いた、ネイティブの atomic counter も実装した ( それらの機能を追加した理由は推測してもらえるだろう)。

We’ve tested and improved the operational capabilities of Cassandra, upgrading its Rackaware capability, added slow query logging, improved the bulk import functionality and implemented Scribe support for improved logging. We’ve also done a ton of operational testing.

さらに、Rackaware機能の改善と、ログに関するスロー・クエリーの追加、バルク・インポート機能の改善、進化したログに対する Scribe サポートの実装など、Cassandraにおける運用面での機能も、改善しテストしてきた。つまり、膨大な量の運用面でのテストを行ってきたわけだ。

We’re open sourcing all our work on Cassandra.


What’s Next?

Currently our main focus is getting Digg’s latest release into general availability, but we’ll continue to lead the way in championing Cassandra’s development and adoption.

現時点における私たちのメインのフォーカスは、Digg における最新リリースの、全体的な可用性を向上させることであるが、Cassandraの開発と適用を推進してていく上で、その方式を広めていきたいと考えている。

If you’re interested in joining a world-class team using cutting edge, NoSQL technology at scale, check out

もし、あなたが、NoSQL レベルのスケールにおいて、世界でも最先端のチームに加わりたいなら、以下の URL をクリックしてほしい:

Take it easy,
John Quinn. VP Engineering. (Digg:
doofdoofsf, Twitter: doofdoofsf)


Twitter に続いて、Digg も Cassandra ですね。 このスケールの世界では、開発だけではなく運用に関するノウハウが、きわめて重要になるのでしょうね。 そこも含めて、Digg みたいはプロバイダーが情報をオープンにしていくことで、ペタの世界が加速していくのでしょうね。 ーーー A.C.

イベンチュアル・コンシステンシーはお好き? by James Hamilton
Twitter が Cassandra を選んだ理由 — MyNoSQL
High Scalability のホット・リンク集 : Cassandra@Twitter インタビューもあるよ!
Cassandra 分散データベースでの削除とは?
Cassandra プロジェクトと Rackspace

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