ミクシィの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
    コンテンツマネジメントシステム
fig

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

fig

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

fig

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

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や動的なパーティショニングの機能がないので、自分たちで実装している。

Tokyo Cabinetの後継、Kyoto Cabinet

Tokyo Tyrantを開発した平林幹雄氏は、Tokyo Cabinetの後継製品にあたるKyoto Cabinetのバージョン1.0を5月に発表しています

Tokyo Cabinetは全てC言語で記述してあり、標準ライブラリ以外はすべて自作しているため高速化されている半面、メンテナンスが難しくなっているとのことで、Kyoto Cabinetでは、多少性能を犠牲にしてもC++とSTL(標準テンプレートライブラリ)で実装したものと説明されています。

しかしKyoto CabinetはTokyo Cabinetに比べて空間効率と並列性は向上しているとのことで、マルチコア、メニーコアの環境ではKyoto Cabinetのほうが効率がよいそうです。

Tags: NoSQL データベース

このエントリーをはてなブックマークに追加
ツイート
follow us in feedly





タグクラウド

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本