ビッグデータ活用のためのデータベース最新トレンド

ビッグデータに対応するデータベースとは

ビッグデータに対応するためのポイントとしてデータベースの高速化が挙げられます。このポイントに対する一つの解答として2014年、大手のサービス提供事業者から相次いでインメモリに対応したデータベースがリリースされています。

高速なインメモリデータベース

インメモリデータベースはすべてのデータをメモリ上に持って処理するため、ディスクからデータを読み出すのに比べ非常に高速な処理が可能になります。 インメモリデータベースはデータの更新に関しては更新した内容を保持できる場所に書き込んで保存しておく必要があるため、高速な処理は難しいもののメモリ上にあるデータを読み出すだけの検索処理において大幅な高速化を実現します。

列指向を利用する高速データベース

また同じデータベース高速化を促す技術として列指向があります。データを行ではなく列で持つことで検索処理を高速化するものです。この列指向とインメモリを併せて実装し検索処理をより高速化させるのが最新のトレンドとなっています。

コスト面においてディスクより高価なメモリですが、既にインメモリはデータベースの一つの機能として必須のものになりつつあるため今後はインメモリ機能があるかどうかではなく、インメモリを自社の業務にどう活用できるか？いかに目的を達成できるかの観点から選択をするようになっていきそうです。

ビッグデータの利用で必須なNoSQLとは

ビッグデータ登場前に主流であったRDB（リネーショナルデータベース）ですが、扱えるデータの範囲に限界がありました。そこで生まれた技術がNoSQLです。

ここではビッグデータを扱ううえで必要なNoSQLについて特性や種類をふまえて解説していきます。

ビッグデータを得意とするNoSQL

長い間データベースといえばリネーショナルデータベース(RDB)が主流でした。しかしここ数年でGoogleやAmazonでも実装されているNoSQLを利用する企業が増えてきました。

NoSQLとはデータをテーブル管理するのではなく、XMLやJSONのフォーマットを用いたドキュメント型のデータベースで、一般的にはRDB以外のデータベース管理システムを指します。

増えるデータと広がるNoSQLの活用

ソーシャルメディアのデータ、Webのログ、リアルタイムランキングなど現在はさまざまなタイプのデータ処理が必要となっています。またデータもコンピュータだけでなくスマートフォン、タブレットなどいくつものデバイスからデータが集まるため、RDBでは効率的に扱えない場合が増えています。その際に多彩なデータを柔軟に扱えるスキーマレスなNoSQLが効果を発揮します。

NoSQLの種類

ここではNoSQLの種類について解説していきます。NoSQLは大きく分けて4つの型に分類することができます。一つずつみていきましょう。

高速なキーバリュー型(KVS)

データの管理やアクセスはキーに対して行います。そしてそのキーに対してバリューが存在します。拡張性に優れ、データの読込がRDBと比較して高速です。

列指向のワイドカラムストア型

日本語では列指向とも呼ばれています。データは行で管理されますが、アクセスはKVSと同じようにキーを使用して列単位となります。列に対して数億というデータの追加が可能で、データの書き込みが高速です。

柔軟な開発ができるドキュメント型

キーに対してバリューではなく、より複雑なドキュメントとしてデータを格納します。XMLやJSONといった スキーマレスでデータ構造が柔軟なため、生産性高く柔軟な開発が可能です。

データをモデル化するグラフ型

グラフ理論に基づき相互に結びついた要素で構成されています。グラフデータベースはRDBでは不可能だった形でデータの関係をモデル化し探索することを得意としています。

RDBとNoSQLのメリットを掛け合わせたNewSQL

NoSQLのさらに進化した形としてNewSQLがあります。これはNoSQLのスケーラビリティとRDBのトランザクション機能を併せ持ったもので一般的な知名度はまだ低いもののより高度なデータ処理をしつつビッグデータにも対応できるスケーラビリティを求める企業には選択肢の一つとなります。

また以下の記事ではビッグデータに限らないデータベースの変遷について解説しています。データベースの歴史や誕生背景について知りたい方は参考にしてください。

▼データベースの変遷とトレンドを知ろう
参考記事：データベースの技術トレンド

RDBとNoSQLの共存

NoSQLの登場によってデータベースの選択肢が一気に拡がったものの、今すぐにすべてがNoSQLに置き換えられる訳ではありません。NewSQLの登場を見てもわかるようにRDBが必要な場面もまだまだあり、必要に応じてどちらか、もしくは併用するといった形がこれからも続くと思われます。