Agile Cat — in the cloud

February 18, 2011

Mollom アーキテクチャは、毎秒 100回のリクエストを発行し、3億 7300万のスパムを退治する

Filed under: Big Data,NoSQL — Agile Cat @ 8:22 am
Tags: , , , , , , ,

Mollom Architecture – Killing Over 373 Million Spams At 100 Requests Per Second
transparentTUESDAY, FEBRUARY 8, 2011 AT 12:18PM
http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html 

_highscalability

Mollom is one of those cool SaaS companies every developer dreams of creating when they wrack their brains looking for a viable software-as-a-service startup. Mollom profitably runs a useful service—spam filtering—with a small group of geographically distributed developers. Mollom helps protect nearly 40,000 websites from spam, including one of mine, which is where I first learned about Mollom. In a desperate attempt to stop spam on a Drupal site, where every other form of CAPTCHA had failed miserably, I installed Mollom in about 10 minutes and it immediately started working. That’s the out of the box experience I was looking for.

成長していく SaaS スタートアップについて熟考するとき、すべてのデベロッパーが夢見るようなクールな企業が Mollomある。 Mollom は、有用なスパム・フィルタリング を、地理的に分配されたデベロッパーによる小規模なグループと共に、有益性のあるサービスとして実現している。 Mollom から最初に学んだことは、約 40,000 の Web サイトをスパムから守り、その中に私のサイトも含まれていることであった。私は Drupal サイトでスパムを退治しようと、他の CAPTCHA フォームを用いたが、その全てが惨敗した。 しかし、Mollom 10分でインストールすると、直ちに機能し始めた。 私が探していたのは、この、直ちに機能するエクスペリエンスだった。

5426183775_6b4d1eb673_m

From the time Mollom opened it’s digital inspection system they’ve rejected over 373 million spams and in the process they’ve learned that a stunning 90% of all messages are spam. This spam torrent is handled by only two geographically distributed machines that handle 100 requests/ second, each running a Java application server and Cassandra. So few resources are necessary because they’ve created a very efficient machine learning system. Isn’t that cool? So, how do they do it?

Mollom のデジタル走査システムをオープンしたときから、3 億 7300 万以上のスパムが除去されたが、そのプロセスにおいて、全メッセージの 90% がスパムであるという、衝撃的な事実が学習された。 このスパムの奔流は、地理的に分散され、秒間で 100 リクエストを処理する、たった 2台マシンにより処理される。 そして、それらのマシンでは、Java アプリケーション・サーバーと、Cassandra が運用されている。 彼らは、その程度のリソースしか要求しない、きわめて効率的な機械学習システムを開発している。 とてもクールでしょう? そして、その方式を探ってみたくないか?

To find out I interviewed Benjamin Schrauwen, cofounder of Mollom, and Johan Vos, Glassfish and Java enterprise expert. Proving software knows no national boundaries, Mollom HQ is located in Belgium  (other good things from Belgium: Hercule Poirot, chocolate, waffles).

そのために、Mollom の創業者である Benjamin Schrauwen と、 Glassfish および Java Enterprise のエキスパートである Johan Vos に、インタビューを試みた。 Mollom HQ は Belgiumエルキュール・ポアロチョコレートワッフルが有名)に所在し、ソフトウェアには国境が存在しないことを証明している。

Statistics

  • Serving 40,000 active websites, many of which are very large customers like Sony Music, Warner Brothers, Fox News, and The Economist. A lot of big brands, with big websites, and a lot of comments.
  • Find 1/2 million spam messages each day.
  • Handle 100 API calls/second.
  • A spam check is low latency, taking between 30-50msecs. The slowest connection would be 500msec. The 95th percentile of latency is 250msecs. It’s really optimized for speed. 
  • Spam classification efficiency is at 99.95%. This means that only 5 in 10,000 spam messages were not caught by Mollom.
  • Netlog, which is a social networking site in Europe, has their own Mollom setup in their own datacenter. Netlog handles about 4 million messages a day on custom classifiers that are trained on their data.
  • 40,000 のアクティブな Webサイトに対して、サービスを提供する。そこには、Sony Music や、Warner Brothers、Fox News、The Economist といったビッグ・ブランドがいる。それぞれが、大規模な Web サイトであり、膨大なコメント抱える。
  • 毎日、500,000 のスパム・メッセージが発見される。
  • 秒間で、100 回の API コールを処理する。
  • スパム・チェックは、30-50 msec という、きわめて低いレイテンシーで処理される。 最も遅いコネクションで、500 msec となる。レイテンシーの 95 パーセンタイルは、250 msec となる。 つまり、スピードに対して最適化される。
  • スパムの分類効率は、99.95% である。 つまり、Mollom にり検知できないスパムは、5/10,000 となる。
  • ヨーロッパのソーシャル・ネットワークである Netlog は、自身のデータセンター内で、自身で設定した Mollom を用いる。そして、自身のデータに合わせたカスタムな  classifiers を用いて、1日あたり 400 万メッセージを処理する。

Platform

  • Two production servers run in two different datacenters for failover. 
    • One server is on the East coast and one is on the West coast. 
    • Each server is an Intel Xeon Quad core, 2.8GHz, 16GB RAM, 4 disks of 300 GB, RAID 10.
  • SoftLayer – the machines are hosted by SoftLayer.
  • Cassandra – a NoSQL database selected for it’s write performance and ability to operate across multiple datacenters. 
  • Glassfish – open source application server for the Java EE platform. They picked Glassfish for it’s enterprise ready features like replication and failover.
  • Hudson – provides for continuous testing and deployment of the backend across all their servers.
  • Java – From the start Mollom was written in Java.
  • Munin – used to measure and plot metrics concerning server health.
  • MySQL – JPA (The Java Persistence API) is used for regular data sets and Cassandra is used for large data sets.
  • Pingdom – used for uptime monitoring.
  • Zendesk – used for support.
  • Drupal – used for the main website with a custom E-commerce module.
  • Unfuddle  – Subversion hosting used for source code control by their distributed development team.
  • 2 台の運用サーバーが、フェイルオーバーのために、2つのデータセンターで稼働する。 
    • 1 台のサーバーが東海岸で、もう1台が西海岸に配置される。
    • それぞれのサーバーのスペックは、Intel Xeon Quad/2.8GHz/16GB RAM/4 disks of 300 GB/RAID 10 である。
  • SoftLayer – それらのサーバーをホストするデータセンター。
  • Cassandra – 書込みの性能と、マルチ・データセンターのために選択された NoSQL。
  • Glassfish – Java EE プラットフォーム用の OSS アプリケーション・サーバー。りプリケーションやフェイルオーバーといった、エンタープライズ用の機能が、その選択の理由。
  • Hudson – すべてのサーバーを横断するかたちで、継続的なテストとデプロイメントを実現。
  • Java – 当初から、Mollom は Java で記述されている。
  • Munin – サーバーに関する、measure and plot metrics に使用。
  • MySQL – 一般的なデータセットのために JPA (The Java Persistence API) を使用し、また、大規模データセットには Cassandra を使用。
  • Pingdom – アップ・タイムのモニタリングのために使用。
  • Zendesk – サポートのために利用。
  • Drupal – メインの Web サイトと、カスタムな E-commerce モジュールとして利用。
  • Unfuddle  – 地理的に分散された開発チームにより、ソースコードを管理するために用いられる、サブバージョン・ホスティング。

What Is Mollom?

Mollom is a web service for filtering out various types of spam from user generated content: comments, forum posts, blog posts, polls, contact forms, registration forms, and password request forms. Spam determination is not only based on the posted content, but also on the past activity and reputation of the poster. Mollom’s machine learning algorithms act as your 24×7 digital moderator, so you don’t have to.

Mollom は、ユーザーが生成する各種のコンテンツから、スパムを除外するための Web サービスである。 それらのコンテンツには、コメントおよび、フォーラム・ポスト、ブログ・ポスト、ポール、コンタクト・フォーム、レジストレーション・フォーム、パスワード・リクエスト・フォームなどがある。 スパムの認定は、ポストされたコンテントだけではなく、ポストした人物の過去のアクティビティや頻度などに基づく。 Mollom の機械学習アルゴリズムは、デジタル仲介者の役割を 24×7 で務め、その処理からユーザーを解放する。

ーーーーー

なんというか、Mollom ってすごくカッコ良いですね。 また、ITの ビジネスが急速に様変わりするという予測が、すでに現実のものとなっている状況が分かります。 Cassandra も上手く使われているみたいで、ともても面白い話ですね。ーーー __AC Stamp 2

ーーーーー

<関連>
Google Megastore – 1日で 30億 Write/200億 Read のトランザクションを実現
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!
Web デベロッパーが知っておくべき、15種類の オープンソース・プロジェクト

プロジェクト Piccolo は、スピードで Hadoop を凌駕する

Filed under: Big Data,Hadoop,Parallel — Agile Cat @ 7:56 am
Tags: , , , , ,

Piccolo Project Tries to Speed Past Hadoop
By
Derrick Harris Feb. 3, 2011, 11:30am PST
http://gigaom.com/cloud/piccolo-project-tries-to-do-parallel-processing-faster/

_ Gigaom

Few would argue that Hadoop doesn’t have a bright future as a foundational element of big data stacks, but Piccolo, a new project out of New York University, is moving data storage into machines’ memory in an attempt to improve parallel-processing performance beyond what Hadoop and/or MapReduce can do. Todd Hoff at High Scalability profiles the project, and I’d suggest going there for the details. At a high level, the difference between Hadoop and Piccolo might be explained as the difference between digging for one vegetable at a time and spreading the cleaning and peeling duties to a team of workers, versus having those workers each grab and process their own vegetables simultaneously, from a prearranged pile above the ground.

ビッグ・データ・スタックの基本的な要素として、Hadoop の明るい未来を否定する人は、ほとんどいないだろう。しかし、New York University で生まれた新規のプロジェクトである Piccolo は、マシン・メモリ内へのデータ・ストレージの移行により、並列処理パフォーマンスの改善を試み、Hadoop や MapReduce の能力をしのぐ領域を目指す。 このプロジェクトの概要については、High Scalability の Todd Hoff が記しているため、詳細については、その参照をお勧めする。 高い抽象レベルにおいて、 Hadoop と Piccolo の相違を以下のように例えることができる。 つまり、一度に1つの野菜を掘り出し、洗って、皮を剥く、農夫の仕事が Hadoop に相当するなら、あらかじめ定められた区画から複数の農夫が、それぞれが担当する野菜を同時に収穫し、その後の処理も行うのが Piccole である。

A more technical explanation is that Piccolo uses an in-memory, key-value store and a “global table interface” — as opposed to Hadoop, which utilizes a distributed file system contained within the disk drives of the machines in the cluster — that lets the CPUs access all the data simultaneously, and at high speeds only possible by pulling data straight from RAM. In this fairly long, but genuinely interesting presentation at the OSDI 10 conference, lead developer Russell Power explains how Piccolo works, how it differs from Hadoop and how it has tested far faster than Hadoop on certain workloads. Power compares Piccolo to the Chevy El Camino, which was both efficient and easy to use while also delivering high performance. Here’s a screenshot of Power illustrating Piccolo’s scalability on an Amazon EC2 cluster:

よりテクニカルに説明すると、Piccolo はイン・メモリーと Key-Value ストアだけではなく、Hadoop の対極にある 『 グローバル・テーブル・インターフェイス 』を用いることが、大きな相違点として挙げられる。そこでは、クラスタを構成するマシンに配備されたディスク・ドライブ内に含まれる、分散型のファイル・システムを活用する。 つまり、RAM から直接データを引き出すことで可能となる、きわめて高速のデータ・アクセスを、CPU に提供することになる。OSDI 10 カンファレンスにおける、長時間におよぶが、きわめて興味深いプレゼンテーションで、中心となるデベロッパーである Russell Power が、どのように Piccolo が動くのか説明した。また、特定のワークロードにおいて、Hadoop との差異が状況と、Hadoop を上回るテスト結果について説明した。 Power は、Piccolo と Chevy El Camino と比較し、どちらが使いやすく、また、効率的で、高性能をもたらすかという点を指摘した。Amazon EC2 クラスタ上で、Piccolo のスケーラビリティを証明する、Power のスクリーンショットは以下のとおりである:

クリックで拡大 ⇒

I’m not suggesting Piccolo is going to replace Hadoop, or MapReduce, generally, anytime soon or ever — Hadoop vendor Cloudera today received a strategic investment from U.S. intelligence sector consultant In-Q-Tel, which should hammer home the fact that Hadoop is for real — but Piccolo is worth watching. It certainly wouldn’t be the first academic project in recent memory to make it big; the Marten-Mickos-led cloud-software provider Eucalyptus Systems was a research project from the University of California Santa Barbara when it caught on, and then struck it big with VCs and early adopters.

一般論として、近々あるいは特定の時期に、Hadoop や MapReduce に対して、Piccolo が取って代わると示唆しているわけではない。今日(2/3)のことだが、Hadoop ベンダーである Cloudera は、US 政府情報部門のコンサルタントである In-Q-Tel から戦略的投資を受けた。それは、Hadoop が本物であるという現実を裏付けるものだ。 しかし、Piccolo は注視し続けるだけの価値を持つ。アカデミック・プロジェクトに関する最近の記憶では、この件が最初の成功例というわけでもない。Marten Mickos が率いるクラウド・ソフトウェア・プロバイダーである Eucalyptus Systems は、University of California Santa Barbara の研究プロジェクトとして始まった。そして、広まるにつれてアーリー・アダプタを得て、VC からの資金も調達するようになった

To learn even more about the future of big data processing and analysis, make sure to attend out Structure Big Data conference March 23 in New York City. You won’t likely hear about the seedling Piccolo project, but you’ll hear plenty about cutting-edge use cases and tactics for the current generation of big data tools.

3月23日に NYC で開催される、私たちの Big Data conference に参加して欲しい。 Piccolo については聞くことができないが、最先端のデータベースを含めて、ビッグ・データを取り扱う際の要因について、また、それを解決するための最適化された戦略を学べる。

Related Content From GigaOM Pro (subscription required)

ーーーーー

いろいろと出てきて、ほんとうに面白いですね! それと、Chevy El Camino は、Todd Hoff さんサイトにあるように、いわゆるデカいアメ車のことなのでしょう。 なんで黄色いのかという、意味もあるのですね。 この人の茶目っ気が大好きです :) ーーー __AC Stamp 2

ーーーーー

<関連>
Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase
Yahoo!は、独自の Hadoop Distribution を止めて、Apache コミュニティに協力する
Hadoop に似た Dryad は、Microsoft の Big Data スターになれるのか

 

February 17, 2011

バルセロナの MWC での買収話を、あらためて否定する Twitter

Filed under: Twitter — Agile Cat @ 1:05 pm
Tags: , , ,

ACQUISITIONS: Facebook and Google fight for admitted “not worth $10 Billion dollars” Twitter
Wednesday, February 16th, 2011 at 10:47 am
http://www.wealthvest.com/blog/sean-browne/acquisitions-facebook-and-google-fight-for-admitted-not-worth-10-billion-dollars-twitter/

image

Yesterday, Twitter CEO Dick Costolo dismissed the company’s $10 billion acquisition rumors during a speech at the Mobile World Congress in Barcelona. Now, Twitter co-founder and inventive director Biz Stone told NPR that “We’re not valued at $10 billion dollars.”

昨日、Barcelona での Mobile World Congress で、Twitter CEO Dick Costolo は スピーチの間に、同社が $10 billion  で買収されるというウワサを否定した。 そしていま、 Twitter Co-Founder であり、また、切れ者ディレクターである Biz Stone は NPR に対して、『 私たちに $10 billion は不釣合だ 』 と発言した。

new-twitter-rollout

The Wall Street Journal recently reported that Twitter is within low-level acquisition talks with Facebookand Google for any deal that would place the network at a $8 to $10 billion valuation. Stone tells Fresh Air’s Terry Gross, “We’re not valued at $10 billion dollars. That’s precisely what people are writing within the newspapers, which unfortunately has the negative impact of my friends thinking I have to have $10 billion dollars.”

先日の Wall Street Journal のレポートによると、Twitter は Facebook および Google との買収話において、$8 to $10 billion に価格を定めた、具体的な交渉に入っているとされた。 Stone が Fresh Air の Terry Gross に対して、『 私たちは $10 billion の価値はない。 正確に言うと、それは新聞に書かれているだけのことであり、さらに残念なことに、$10 billion をかき集めなければならないという、ネガティブなインパクトを関係者に与える 』と、発言している。

Obviously, the $8 billion to $10 billion are just numbers being thrown out there (perhaps by overeager bankers?). Twitter’s valuation wouldn’t change until a deal is really done. Just last December, the organization was reportedly valued at $3.7 billion during its most recent funding round.

明らかなことは、$8 billion to $10 billion は、(加熱した銀行家により)取りざたされているだけの数字である。 何らかの取引が実施されるまで、Twitter の評価は変化しないだろう。 昨年の 12月行われた、直近のファンドのラウンドでは、Twitter の価値は $3.7 billion と評価されている。

However when Gross asked him about the acquisition rumors he responded “Twitter isn’t for sale. We don’t have a shingle out on our front saying ‘Twitter. Available.’ We’re not available and we haven’t been. We’re very, very thinking about building a completely independent company. “

しかし、Gross が Twitter の買収について Stone に尋ねたとき、彼は 『 Twitter は売り物ではない。 Twitter を売りますと言えるような財産を、私たちは持っていない。それは、不可能なことであり、いまも変わらない。私たちは、 完全に独立した企業を築くことに、一生懸命なのだ 』 と答えている。

ーーーーー

Twitter が、どこかの傘下に入ってしまったら、ほんとうにツマンナイから ガンバレ ~~~ __AC Stamp 2

ーーーーー

<関連>
Google が Twitter 買収を画策しているという ウワサ
たとえ $5B を積まれても、Google なんかに売りません!

Real World NoSQL シリーズ – Netflix における Amazon SimpleDB

Filed under: Amazon,Big Data,Entertainment,NoSQL — Agile Cat @ 6:59 am
Tags: , , , , ,

Real World NoSQL: Amazon SimpleDB at Netflix
By Guy Harrison Feb. 4, 2011, 11:45am PST
http://gigaom.com/cloud/real-world-nosql-amazon-simpledb-at-netflix/

_ Gigaom

Edit Note: This is the fourth of a multi-part series of posts exploring the use cases for NoSQL deployments in the real world. So far, the series has covered case studies on MongoDB,Cassandra and Hbase.

ーーーーー

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 ディプロイメントについて注目していく。

Amazon

Netflix provides rent-by-mail and streaming movies in the United States. The shift from mail-order to streaming video had fairly significant implications for Netflix’s application infrastructure. Netflix realized that it would need multiple geographically dispersed data centers and far more processing capacity. Rather than build these new data centers, Netflix decided to migrate its applications to Amazon’s AWS cloud. This allowed the company to concentrate its intellectual efforts on building customer value rather than nationwide data centers.

Netflix は、US における映画マーケットにおいて、メールによる貸し出しとストリーミングを介して、それらのコンテンツを提供している。 そのメール・オーダーから、ストリーミング・ビデオへのシフトは、Netflix のアプリケーション。インフラストラクチャに対して、きわめて大きな影響をおよぼした。 そのためには、マルチ・ロケーションに分散されたデータセンターと、さらなるプロセシング・キャパシティが必要になると、Netflix は理解した。 そして Netflix は、そのための新しいデータセンターを構築するよりも、Amazon AWS クラウドへアプリケーションを移行する方針を定めた。それにより同社は、全国的規模でのマルチ・データセンターの構築ではなく、顧客にとっての価値を構築するという、より知的な作業に集中することを可能にした。

As a part of this bold move, Netflix migrated core parts of its database from Oracle to Amazon’s SimpleDB data store. This migration is one of the biggest migrations to the cloud yet undertaken, with the Netflix system serving the needs of more than 16 million subscribers and hosting over 100,000 DVD titles.

この思い切った手段の一部として、Netflix はデータベースのコア部分を、Oracle から Amazon SimpleDB データ・ストアへと移行させた。 それは、Netflix のシステムにおける、1600万人以上のサブスクライバーにサービスを提供し、100,000以上の DVD タイトルをホストするものである。 つまり、すでに着手された、クラウドにおける最大級の移行である。

SimpleDB is a key-value store that runs within the Amazon Web Services (AWS) cloud, and promises reliable and transparently scalable storage together with a flexible schema that supports either immediate or eventual consistency. SimpleDB is a virtually zero-administration service: there is no database administration involved in scaling the system – storage and computer power is assigned dynamically and automatically by Amazon as the database grows.

SimpleDB は、Amazon Web Services(AWS)クラウド上で稼働する Key-Value ストアであり、イミディエイトあるいはイベンチュアルのコンシステンシーをサポートする柔軟なスキーマを組み合わせた、信頼性と透過性を持つスケーラブルなストレージを保証する。 SimpleDB は、アドミニストレーションが実質的に不要なサービスである。 つまり、システムのスケーリングに関与する、データベース・アドミニストレーションが存在しない。そして、対象となるデータベースが成長するにつれて、ストレージつコンピューティングのパワーは動的かつ自動的に、 Amazon により割り当てられる。

Netflix needed to make significant compromises in exchange for the scalability provided by Amazon AWS and SimpleDB. Complex SQL operations such as joins between tables or aggregate “group by” operations which would normally be executed within the database were moved to the application layer. In some cases this required that the data model be de-normalized; data that would be stored in multiple tables in Oracle was flattened into a single SimpleDB structure so that joins could be avoided.

Amazon AWS と SimpleDB が提供するスケーラビリティと引き換えに、Netflix は大幅な妥協を強いられた。 通常はデータベース内で実行されるテーブル間の join や、“group by” によるアグリゲーションといった、複雑な SQL オペレーションがアプリケーション・レイヤに移動した。 いくつかのケースでは、これらのデータ・モデルを de-normalize する必要があった。つまり、Oracle ではマルチ・テーブルにストアされるデータを、シングル SimpleDB 構造内にフラットに展開し、join を回避する必要があった。

Relational database transactions were depreciated in favour of SimpleDB’s optimistic concurrency mechanism, which allows modifications to proceed only if an item is unchanged since it was last accessed. For instance, an attempt to increment a counter (number of rentals for a video for instance) would be rejected if the counter was simultaneously modified by another transaction. Even so application developers needed to be aware that certain operations (reading a value immediately after modifying it, for instance) might incorrect or at least unexpected results.

リレーショナル・データベース・トランザクションは、SimpleDB の楽観的コンカレント・メカニズムを導入するために軽視され、最後にアクセスされたときから、アイテムが変化していない場合に限り、処理を進めるように修正された。 たとえば、カウンターが別のトランザクションにより同時に修正された場合は、カウンターをインクリメント(レンタルされたビデオの本数など)させる試みは拒絶されるであろう。 それにしても、アプリケーション・デベロッパーは、特定のオペレーション(たとえば 修正直後の値の読み出し)が不正確なケースを知る必要がある。また、少なくとも、想定外の結果がもたらされるのであれば、それも知らなければならない。

Netflix doesn’t use SimpleDB for all storage; Oracle, MySQL and the Amazon S3 service all form significant parts of the Netflix architecture. Nevertheless, with more than 16 million customers, Netflix has made a significant commitment to a non-relational alternative and one which, it says, allows them to better meet customer and shareholder needs. Netflix has been generous in sharing their experiences in articles such as this one.

Netflix では、すべてのストレージに対して、SimpleDB を用いるわけではない。つまり、Oracle/MySQL/Amazon S3 の全てのサービスにより、Netflix アーキテクチャの重要なパートが構成される。それにもかかわらず、1600万人以上の顧客を前提として、 Netflix はノン・リレーショナルという選択肢をコミットした。 その点において、顧客と関係者の要件を充たすものと評価できる。このような記事において、そのエクスペリエンスを共有することに関して、Netflix は寛大である。

To learn more about the factors driving big data and optimal strategies for solving it, including from Hadoop, NoSQL and MPP database leaders, come to our Big Data conference held on March 23 in NYC.

Hadoop から、NoSQL、そして MPP といった、最先端のデータベースを含めて、ビッグ・データを取り扱う際の要因について、また、それを解決するための最適化された戦略を学ぶために、 3月23日に NYC で開催される、私たちの Big Data conference に参加して欲しい。

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):

ーーーーー

まぁ、日本でいえば TAUTAYA とか DeNA みたいな会社なんでしょうね、Netflix は。また、SimpleDB は S3 ほど有名ではないと思いますが、マルチ・データセンターによる冗長性を確保しているのですね。 Agile_Cat も、この Google に関する記事を見て初めて知りましたが、大したものです。その分、S3 に対してパフォーマンスで遅れをとりますが、トレードオフとして、致し方ないところなんでしょうね。 ーーー __AC Stamp 2

ーーーーー

<関連>
Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase

February 16, 2011

Cassandra の Riptano は、DataStax に買収されてしまったの? – 実は社名変更でした

Filed under: NoSQL — Agile Cat @ 5:43 pm
Tags: , , ,

そして、Jonathan Ellis さんは元気なのだろうか?

Cassandra先日ですが、Gigaom の Openwave における Cassandra という記事を読んでいて、『 Riptano(現 DataStax)』 と書かれていたので オヤッと思ったのですが、どうやら、そのとおりのようです。 " Riptano " でぐぐっても、同社のサイトは見当たらず、引っかかったのは、以下の Twitter アカウントでした。Riptano の方は、中身が空っぽになっていて、DataStax の方に、有るべきものが有るという状況です。

そして、DataStax のサイトを見ると、Press Releases の欄に、以下の2つのポストがあります。 そして不思議なことに、Oct 27, 2010 と Feb 1, 2011 の間にあるはずの、" DataStax が Riptano を買収 " というポストがありません。

Feb 1, 2011 – DataStax Injects Scale into Real-Time Web and Enterprise Applications with Apache Cassandra™
Oct 27, 2010 – Riptano, the Commercial Cassandra Company, Raises $2.7 Million in Series A Funding

どう考えても、不思議な展開ですよね。 何方か、何かを、ご存知でしょうか?

ーーーーー

・・・ とポストしたら、すぐに Twitter で @satoruf さんから、単純な社名変更というご指摘がありました。

Riptano Changes Its Name to Datastax, Announces Management Product

Riptano, the sponsor company of the NoSQL database Cassandra, changed its name toDatastax. It also announced a new product called OpsCenter for Cassandra, which it promises will make Cassandra easier and more efficient.

どうも、有難うございました。 そして、お騒がせして、スミマセンでした orz ーーー __AC Stamp 2

ーーーーー

<関連>
Cassandra ドキュメントのリスト
Cassandra プロジェクトと Rackspace
Cassandra 分散データベースでの削除とは?
Twitter が Cassandra を選んだ理由 — MyNoSQL

« Previous PageNext Page »

Theme: Rubric. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 3,239 other followers