米Facebook、自社ストレージエンジンとMySQLを組み合わせた「MyRocks」を発表 | OSDN Magazine
米Facebookは8月31日、自社のストレージエンジン「RocksDB」をMySQLに組み合わせた「MyRocks」を発表した。永続的キーバリューストアのRocksDBをMySQLのバックエンドエンジンとして利用できるもので、社内でも利用しているという。 RocksDBはFacebookが2013年に発表したオープンソースプロジェクト。同社はMySQLを利用してペタバイト級のデータを管理しており、「いいね!」ボタン、コメント、共有などのアクティビティ提供にInnoDBストレージエンジンを利用してきたが、フラッシュストレージ利用時などにInnoDBの性能と信頼性に制限があることから、開発に至った。 Facebooはすでにフラッシュストレージ向けのKey-Balueストア「RocksDB」をオープンソースで公開しているが、今回発表されたMyRocksは、RocksDBをMySQLのストレージ
Facebook、Key-Valueストア「RocksDB」をオープンソース化
Facebook、Key-Valueストア「RocksDB」をオープンソース化：C++ライブラリとして構築 米Facebookは、同社内で高速ストレージ用に開発・使用してきた組み込み式の永続型Key-Valueストア「RocksDB」をオープンソースで公開したと発表した。 米Facebookは2013年11月22日、同社内で高速ストレージ用に開発・使用してきた組み込み式の永続型Key-Valueストア「RocksDB」をオープンソースで公開したと発表した。 Facebookによると、これまでのアプリケーションでは、ネットワークを介したリモートプロシージャコールによって各アプリケーションが管理しているデータにアクセスするのが一般的だった。しかし12億人のユーザーごとにリアルタイムで動的なページを生成しているFacebookのようなアプリケーションの場合、それでは時間が掛かり過ぎるという難点が
Facebook、分散SQLエンジン「Presto」公開。大規模データをMapReduce/Hiveの10倍効率よく処理すると
Facebookは、数ペタバイト級の大規模データに対しても、対話的にアドホックな問い合わせを可能にする分散SQLエンジン「Presto」を、オープンソースで公開しました。 PrestoはFacebook社内で大規模データの分析のために開発され、すでに同社社内使われているもの。 FacebookはPrestoを開発した背景として、大量のデータをHadoop/HDFSベースで保存したものの、バッチ指向のMapReduceではなく、リアルタイム性に優れた処理が必要になったためだと、次のように説明しています。 Facebook’s warehouse data is stored in a few large Hadoop/HDFS-based clusters. Hadoop MapReduce [2] and Hive are designed for large-scale, reliabl
FacebookにおけるMySQLを用いた大規模システムアーキテクチャの現実～MySQL Connect 2013
米オラクルが主催するMySQLのイベント「MySQL Connect」が9月21日から23日まで、サンフランシスコで開催されました。Oracle OpenWorld、JavaOneとの同時開催でした。 基調講演の1つには、MySQLのヘビーユーザーであるFacebookのHarrison Fisk氏が登壇。FacebookにおけるMySQLの役割、大規模運用の背景などを紹介しています。その内容をダイジェストで紹介しましょう。 MySQL@Facebook Lots and lots of small data Harrison Fisk氏。 Facebookでデータパフォーマンスチームのマネージャをしている。社内ではMySQLはもちろん、HBase Hadoopなどにも関わっている。 まずは、どんな種類のデータをMySQLで扱っているのかについて。 Facebookとは基本的にグラフだ。グ
Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
動かしながら変えていくということ - masayang's diary
いまさらだけど、2008年春の時点では、FacebookはMySQLに強く依存していたんだよね。しかも1800サーバ(900のMaster/Slave組み合わせ)!! そして、裏ではCassandraへの移行が既に始まっていた、と。 いくらx86とはいえ、1800台もサーバ動かせばそれは「資産」として扱いたくなる心境だけど、そこを敢えて否定してCassandraに持っていった姿勢は見習う必要がある。そして、その移行の理由は: Cassandra does not support a full relational data model; instead, it provides clients with a simple data model that supports dynamic control over data layout and format. →データスキーマをより素早く変
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
