前回は、Hadoopがどのような仕組みでスケール・アウト性を実現しているのかを述べました。また、Hadoopが基本的に、バッチ処理のスループットの向上を目的にしていることを指摘しました。 Hadoopには、「できること」と「できないこと」があります。処理の性質によっては、既存のリレーショナル・データベース管理システム（RDBMS）や、最近注目されているKey-Value Store（KVS）型データベースなどが適していることもあります。 今回は、RDBMSが果たしている役割とニーズの変化を踏まえながら、「データのライフ・サイクル」に着目して、RDBMS、Hadoop、KVSの3者をどのように使い分けていくべきかを解説します。 RDBMSが果たしている役割 RDBMSは、米IBMの研究所に勤務していたエドガー・F・コッドが1970年に発表した、「関係モデル」というデータ・モデルを採用したデー
クラウド上のデータベースとして、分散型のキーバリューストア（分散KVS）を用いることが多くなった。分散KVSは、スケーラビリティーに優れており、特にユーザー数が多いシステムでは利用価値が高い。 ただし、分散KVSにはいくつかの制約があり、システム開発に利用する際には、これまでの“RDBMS脳”をいったんリセットする必要がある。中でも、RDBMSでは真っ先に考慮していた「正規化」については、分散KVSでは原則として行ってはいけない。 分散KVSの四つの特徴 なぜ分散KVSでは正規化をしてはいけないのか。これを理解するには分散KVSの特徴を押さえる必要がある。分散KVSには、大きく四つの特徴がある（図1）。 一つは、分散KVSでは問い合わせにキーを使って、バリュー（値）を取得することだ。データ構造が単純なので、データの取り出し時間が短くて済む。PerlやPHPの連想配列や、JavaのMap、C
これまでの連載を通して、CouchDBの基本的な概念と使い方、アプリケーションの作成方法までを解説してきました。ここからはさらに一歩踏み込んで、CouchDBをDBサーバやAPサーバとして実際に運用するときに役に立つ機能を紹介していきます。具体的には、次の3つのテーマを取り扱います。 全文検索を導入すれば、CouchDB内にあるすべてのドキュメントを対象に、特定のキーワードを指定して検索できます。ユーザー認証では、例えばDBの管理者権限を特定のユーザーのみに付与できます。ユーザー認証はまだ充実しているとはいえないレベルですが、現時点ではどのような選択肢があるかを紹介していきたいと思います。最後にCouchDBへの負荷を分散させる方法として、CouchDBのインスタンスをノードとして複数用意し、各ドキュメントを分散して配置するやり方を紹介します。これらの手段を目的に応じて生かすことができれば
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
