カラムナー、キューブ、インメモリ…ビックデータ分析におけるデータベースのまとめ｜いまさら訊けないビッグデータ分析

データベースの「タイプ」を知ってますか？

こんにちは、ギックス技術チームの岩谷です。

先日とある方より「ビッグデータ分析処理で、Tableauはキューブを作成しないからシステムの運用がしやすいって聞いたんだけど、どういう事なのかな？」という質問をいただきました。その時私は「Tableauはいわゆる”ふつうのDB”を直接検索してグラフをユーザに見せてくれるのが長所の一つなんです。キューブっていうのは”特別なDB”に分類されるもので、これを中間DBみたいに別途立てる必要がないんですよ。だからその分運用も楽なんです。」という答えをさせていただきました。

その後私は「ああ、そういえば”ふつうのDB”、”特別なDB”についてもちょっと説明したかったな」と思っていて、今回は「ビッグデータに使われるデータベースのタイプまとめ」と題して綴らせてください。

ビッグデータを処理するデータベースにはいくつかの型がある

ビッグデータ・高速処理・多次元分析といったBI業務に求められる要求を満たす為に、BI製品が搭載するデータベースにはいくつかのタイプがあります。ここにそれぞれの特徴を簡単にご説明させてください。

 ①.ハードウェア最適化タイプ(Oracle Exadata・IBM PureData System など)

ハードディスクのアクセススピードやバススピードなど、ハードウェアの性能を突き詰めることで速度を上げるタイプです。多くの場合、専用ハードウェアとセットでアプライアンスとして提供されます。データボリューム・アクセススピードともに圧倒的なハイスペックを誇りますが、価格も圧倒的に高いです。以前私が参画させていただいたプロジェクトでもOracle Exadataを導入しましたが、ン億円～～という世界で見積もり資料を見たときには腰を抜かしてしまいました笑。

②.カラムナータイプ(Amazon Redshift など)

列指向データベースとも呼ばれ、一般的なDB(リレーショナルデータベース)が「行単位」でデータを管理するのに対して「列単位」でデータを管理するタイプです。対象となる一部の項目データを取得する為に行全体へのアクセスを行う必要がない為、巨大なデータを取り扱う上で「取り出し項目数は少ないが、取り出し件数は多い」場合には、非常に適しています。また列単位でデータを格納するという特性上、分散処理との実装の相性が良好です。複数台のマシンでクラスタを構築し、ノード数をスケールアウトすることで全体性能(応答速度)を向上させることが容易だと言えます。Amazon Redshiftがビックデータ解析の敷居を一気に押し下げ人気を博しているのもここに理由の一端があります。すなわちノード数のスケールアウトによる分散処理はクラウド基盤にとっても基本的な思想であるため、クラウドベンダであるAWSの提供するRedShiftはこの「分散処理によってDB応答速度を上げる」というユーザ要求にまさにうってつけであったと言えるわけです。

③.インメモリタイプ(PowerPivot・Apache Derby・Oracle Berkeley DB など)

一般的なDBがデータをハードディスクなどのストレージにデータを格納した状態で、ディスク→メモリ→CPUという手順でデータを転送して処理を行うのに対し、あらかじめ殆どのデータをメモリ上に格納した状態でDBのサービスを行うタイプです。最大のボトルネックとも言えるディスクI/Oを極力抑えることで、「スピードが命」な業務に最適です。反面、扱えるデータの最大量が「メモリに依存」するため、データをディスクに格納する他タイプよりも劣ってしまいます。(*1)また、データベースの起動時に殆どのデータをメモリ上に読み込む為、起動時間が比較的長いことにも注意が必要です。

*1：搭載メモリ容量を超えるデータも、ストレージにキャッシュすることによって扱うことは可能なものの、速度が著しく低下し、製品としての魅力を損なうことから本記事では説明を割愛しました。

④.キューブタイプ(Open OLAP・ Oracle OLAP Server)

ディメンションやメジャーといった、多次元分析に必要な要素をデータベースのレイアウトに色濃く反映させることにより、高速検索を実現するタイプ。言い換えれば多次元分析に特化したデータベースです。他タイプに比べ、ハードウェアの性能を高く求められない、多くのOLAP製品が存在する、という事で、BIソフトウェアにおけるスタンダードな方式の一つとなっています。分析の為のシステム構築(要件定義・設計・実装)および分析作業において、BIやOLAPの知識を必要とします。このタイプのDBはどうしても中間DBという性格が強くなってしまいます。本記事冒頭のかたの質問に関しても正にこの通りでこの中間DBの構築・運用・保守にご苦労されているみなさんも多いと思います。

【 私見】SQLが使えるか否かもポイント

以上、 駆け足ではありますがビッグデータに使われるデータベースの種類をタイプ別に紹介してみました。ここで私見として私がこれらのDBを利用する上で気にしているポイントを挙げたいと思います。それは「SQLを用いた情報検索が可能か否か？」です。SQLはデータベースへの問い合わせに用いられるコンピュータ言語であり、汎用的なDBアクセス手法として現在広く用いられています。冒頭で触れた”ふつうのDB”とはこのSQLを用いることのできるDBとも言えます。上記について触れますとOracle ExadataはSQLでのアクセスが可能です。またAmazon Redshiftも可能です。対して PowerPivotやOpen OLAPはSQLを用いることができません。この辺りもふまえてビックデータ処理に最適なデータベースソリューションを選択することが分析チームのアウトプットに大きな影響を与えると考えています。

【連載記事：いまさら訊けないビッグデータ分析】

1. 文字コードや文字化けを理解しよう(その1)
2. 文字コードや文字化けを理解しよう(その2)
3. 「データマート」と「キューブ」の違いとは？
4. カラムナー、キューブ、インメモリ…ビックデータ分析におけるデータベースのまとめ (本編)