Riak NoSQLデータベース: 利用事例とベストプラクティス

作者 Srini Penchikala , 翻訳者 竹中 翔 - (株)ポータルアイランド 投稿日 2011年12月27日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

Distributed Document Oriented Database ,

データベース管理 ,

データアクセス ,

データベース設計 ,

Patterns and Practices ,

データベース ,

Patterns

共有 |

原文(投稿日：2011/12/23)へのリンク

Riakはユーザセッション関連データの保存に使われる、キー・バリュー型のNoSQLデータベースである。先日、Basho TechnologiesのAndy Gross氏が、QCon SF 2011 ConferenceでRiakの利用事例について講演を行った。InfoQでは、Riakデータベースの機能やベストプラクティスについて、Andy氏とMark Philliphs氏(コミュニティマネージャ)に話をうかがった。

InfoQ: リレーショナルデータベースや他のNoSQLデータベースと比較して、Riakデータベースは主にどのようなケースで使われるのですか？

Bashoチーム: Riakは、可用性が優先される、柔軟なリアルタイムシステム向けのデータベースです。Riakはこのようなケースで使われます(ただし、この用途に制限されるわけではありません)。

• セッションストレージ
• ユーザデータストレージ
• S3ライクなサービス
• クラウドインフラストラクチャ
• モバイルアプリのためのスケーラブルで、低遅延のストレージ
• クリティカルデータストレージや耐障害医療データ(デンマークヘルスケアの利用例を見てください)
• カスタムで構築する分散システムの構成要素

以下のような時に、MySQLやOracleからRiakに乗り換える傾向が見られます。 a) それらで無理矢理キー・バリューデータモデルをとっている b) コストを下げる必要がある c) Shardingベースの脆弱なスケールアウトモデルから逃れる必要がある d) 上記の全て

NoSQLデータベースについて言えば、Voldemortは機能の観点からRiakに最も近く、Cassandraもある程度似ています。しかし、Cassandraは、Riakが提供する柔軟な一貫性を必要としないアプリケーションに向いています。我々は、オペレーションの複雑さを削減するために、MongoDBからRiakに乗り換えるユーザを多く目にしてきました。多くの企業がMongoDBやRedisから始めるものの、オペレーションコストがひどく高くなってくると、Riakに乗り換えるように感じています(一般的には、アプリケーションの再設計や、これを手助けするために必要となるデータモデルの修正がある程度必要となることを覚えておいてください。しかし、長い目で見ると、Riakの安定性のために価値があります)。

InfoQ: Riakはどのようなデータ持続性やデータ管理のパターンをサポートしていますか？

Bashoチーム: 我々は、持続性と予測可能性に重点を置いています。これを受けて、我々は異なる利用シーン向けに、プラガブルなバックエンドをサポートしています。

• デフォルトのストレージエンジンはBitcask(我々が作成したものです)であり、これは低遅延のデータを構築することを目的としています。
• 1.0では、GoogleのLevelDBをサポートしており、これはセカンダリインデクシングコンポーネントのためのバックエンドとして使われます。

他にもいくつかのバックエンドがRiakに同梱されていますし、また、自身の利用シーンに合わせてカスタムバックエンドを実装しているユーザもいます(我々はより簡単なAPIにするよう努力しています)。同一クラスタで１つ以上のバックエンドを使うこともできます。例えば、セッション用にBitcaskを、インデックスされたデータ用にLevelDBを使うことができます。

覚えておいて欲しい最も重要なことは、データセットがRAMよりも大きい場合でさえ、Riakのパフォーマンスはそのままであるということです。

InfoQ: Riakデータベースの制限や、利用が適さないケースについて教えていただけますか？

Bashoチーム: アドホックなクエリや大量の分析処理を必要とするアプリケーションは、Riakにうまくフィットしない傾向があります。コア部分にキー・バリューストアを採用しているので、このようなアプリケーションをRiak上に実装するのは、困難が伴います。我々が主に重視しているのは、予測可能性やスケールであり、データモデルやクエリの容易性とは、ある程度のトレードオフの関係にあります。

とは言うものの、2012年には、これらを解決するための様々な機能をRiakに追加しようと考えています。Riakはすでに、MapReduceやセカンダリインデックス、検索コンポーネントによる、より深いクエリを可能にしています。将来的には、このような機能をより拡充していく予定です。

InfoQ: Riakデータベースを利用するアプリケーションに取り組む際に、アプリケーションアーキテクトや開発者が知っておくべきベストプラクティスは、どのようなものがありますか？

Bashoチーム: Riakは実マシンとクラウド環境の両方で確実に動作します。ほとんどのクラウドは、実マシンに対してI/Oの容量が比較的小さいため、AWSやRackspaceのようなところにデプロイする際は、キャパシティプランニングをより重視すべきです。

キー・バリューでのアプリケーションのモデリングは、これまでリレーショナルモデルを採用してきたアーキテクトにとっては難しいでしょう。データモデルとアクセスパターンの検討に、多くの時間を割いてください。Riakは用途にぴったりではないかもしれません。しかし、もし用途にあっていれば(我々の経験では、70%前後はフィットすると思っています)、Riakが提供する機能を活用していただけると思います(ユーザの１人は、"大規模なアプリケーションのほとんどはキー・バリューストアになる"と言っていました)。

MapReduceはRiakの強力なツールですが、同時にすべてのデータを扱うことを意味していません。RiakでのMapReduceは、小規模なキーの範囲を扱うことを意味しており、リアルタイムリクエストのためのデータ提供に使うべきです。

InfoQ: データモデリングやRiakデータベースを使ったアプリケーション開発をサポートするツールには、どのようなものがありますか？

Bashoチーム: 事実上、全てのメジャーなプログラミング言語をサポートするクライアントがあるのに加え、RubyやRython、PHP、Node.jsといった言語のための、様々なORMライブラリやフレームワークもあります。また、GUIでRiakに格納されたデータを調査したり、微調整するためのオープンソースツールもいくつか存在します。将来的には、これをもっと簡単にできるようにしていく予定です。

InfoQ: 新機能の観点で、Riakデータベースのロードマップを教えてください。

Bashoチーム:ユーザビリティ、コア部分の安定性、よりよい分散データストレージのサポートといったことに焦点を当てていこうと考えています。また、Riakを使っている開発者のために、クエリ容易性や柔軟性も拡張していく予定です。速度も優先課題です。Riakはまだ最速のデータベースではありませんが、将来的にはそこを目指していこうと思っています。

さらに、riak_core(Riakの分散機能の源となっているフレームワーク)やriak_pipe(RiakにMapReduceを提供しているフレームワーク)も引き続き拡張していきます。
 

著者 は現在セキュリティアーキテクトとして活動しており、ソフトウェアプロダクトマネージャとして17年の経験も有しています。