ミクシィのNoSQLデータベース「Tokyo Tyrant」をNetVibesが採用した理由

2010年7月29日

カスタマイズ可能なポータルサービスを提供するフランスの「NetVibes」は、バックエンドデータベースとしてミクシィの平林幹雄氏が開発し、同社内でも利用されているNoSQLデータベースの「Tokyo Tyrant/Tokyo Cabinet」（以下Tokyo Tyrant）を採用しているそうです（追記：平林氏は7月末でミクシィを退職されるとのこと）。

なぜNetVibesはTokyo Tyrantを採用したのか、その理由がmyNoSQLの記事「Netvibes: A Large Scale Tokyo Tyrant Deployment Case Study」で紹介されています。NetVibesは、Hadoop、CouchDB、Tokyo Tyrant、File system、MySQLを評価した上でTokyo Tyrant/Tokyo Cabinetを採用したとのこと。

NetVibesがどのような理由で彼らがTokyo Tyrantを選択したのかを見る前に、平林氏によるプレゼンテーション「Introduction to Tokyo Products」で、Tokyo Tyrantがどういうソフトウェアなのか、見ておくことにしましょう。

Tokyo Productsとはどんなソフトウェアか？

Tokyo TyrantやTokyo Cabinetを含むTokyo Productsにはさまざまなソフトウェアがあり、オープンソースとして開発されています。

Tokyo Cabinet
データベースライブラリ
Tokyo Tyrant データベースサーバ
Tokyo Dystopia
全文検索エンジン
Tokyo Promenade
コンテンツマネジメントシステム

Tokyo Cabinetは、キーバリュー型データストアの実装。特徴として、高い並列性とスケーラビリティを備え、トランザクションにも対応。

Tokyo Tyrantは、Tokyo Cabinetを用いたデータベースサーバ。memcachedと互換プロトコル。

平林氏のプレゼンテーションはこの記事末に埋め込んでおきます。

MySQLでの運用が限界に達し、Tokyo Tyrantへ

myNoSQLの記事でインタビューに答えたのは、NetVibesのエンジニアFlorent Solt氏。

NetVibesは、Tokyo Tyrantを経由してTokyo Cabinetを利用。ポータルで利用しているフィード情報をTokyo Cabinetのデータベースに格納する一方、MySQLも並行して利用しており、こちらはユーザーアカウントなどの情報を管理しているとのこと。

Tokyo Tyrantへ切り替えることになったきっかけは、MySQLでの運用が限界に近づいてきたためだとしています。インタビューの内容を引用しましょう。

（当初はすべてのデータをMySQLで管理していたが）、MySQLの限界が近づいてきたので代替できるものを探し始めたんだ。限界のほとんどは（Blogによる）ディスク領域のフラグメンテーションの問題と、インサートに関する本質的なスピードの問題だった。

1年半前のことだけど、少し調査をしたんだ。当時はいまほど選択肢がなかったけれど。実際に実データでベンチマークをした。Hadoop、CouchDB、Tokyo Tyrant、ファイルシステム、そしてMySQL。予算、レスポンス、知識の差などからTokyo Tyrantを選んだ。

Tokyo Tyrant利用に当たっては、独自のShardingを利用しているとのこと。

データ構造について理解すれば、どの機能を選択するかはそれほど難しくない。例えば、本質的なスピードが必要ならhashを使っているし、複雑なキー構造を用いるならb-treeを、条件付き問い合わせを使うならtableを使っている。

Tokyo ProductsにはShardingや動的なパーティショニングの機能がないので、自分たちで実装している。