はじめに
近年、「NoSQL」の技術が注目を集めています。NoSQLとは、"Not Only SQL"の略で、SQLを用いないデータベースの総称です。NoSQLというとCassandra、Redis、MongoDBなどたくさんのデータベースがありますが、HBaseもその中の一つです。
今回は、まずHBaseはどのようなデータベースなのかを説明します。その後に実際に動かしてみてHBaseを体験してみましょう。
対象読者
- HBaseを使ってみたいけど、どう使ったらよいか分からない方
- MySQLなどのRDB以外のデータベースを使ってみたい方
HBaseはどんなデータベース？
冒頭でも書きましたが、HBaseはGoogleの基盤ソフトウェアのBigtableのオープンソースクローンであり、NoSQLの一つです。
Bigtableは、数千台のコモディティなサーバでペタバイト級の大量データを扱うために開発されたデータベースであり、Google内のさまざまなアプリケーションで使用されています。Bigtableはスケーラブルで、かつ高パフォーマンスで高可用性を実現するデータベースを目指して開発されました。当然、これらの特性はHBaseに受け継がれています。
それでは、さまざまな視点からHBaseを見ていきましょう。
CAP定理で見るHBase
NoSQLと一緒に語られるものとしてCAP定理があります。
CAP定理とは、Consistency（一貫性）、Availability（可用性）、Partition-tolerance（分断耐性）の頭文字をとったものですが、分散システムにおいてこの3つを同時に満たすことはできないという定理です。
Consistencyとは、データの更新があった場合にすべてのクライアントは同じデータが見えることです。
Availabilityとは、ノードに障害が発生した際に、すべてのクライアントはデータのいくつかの複製を発見することができることです。
Partition-toleranceとは、分散システムのネットワークが切断されてもサービスを継続することができることです。
大規模な分散システムでは、ネットワークの分断はどうしても起こり得るので、Partition-toleranceは必須です。従って、この定理の本質はPartition-toleranceを担保すると同時に、ConsistencyとAvailabilityの両方を満たすことはできないということになります。
HBaseは、ConsistencyとPartition-toleranceをとったCP型のデータベースです。
HBaseは強い一貫性を持っており古いデータが見えてしまうことはありませんが、ノードの障害時に一時的に数十秒程度のダウンタイムが発生します。このことについては当然ユースケースによりますが、筆者はたいていのユースケースでは大きな問題にはならないと考えています。
また、HBaseとは違ったアプローチをとったデータベースとしては、Cassandraが挙げられます。Cassandraは、AvailabilityとPartition-toleranceをとったAP型のデータベースです。
CassandraはConsistencyが調整可能になっており、Availabilityを優先することもできますし、Consistencyを優先することもできます。
HBaseはマスタ型
HBaseは、マスタ型のアーキテクチャです。マスタ型のアーキテクチャでは、中央管理するサーバが存在します。
HBaseでは、HMasterとHRegionServerという2種類のプロセスが存在します。HMasterがマスタとなりHRegionServerの管理やコーディネーションを行い、HRegionServerはクライアントと実際にデータのやりとりを行います。データのやりとりに関してはHMasterを経由することはないので、HMasterがボトルネックになることはありません。
ちなみに、HMasterはホットスタンバイを立てることができて自動フェイルオーバーが可能です。
マスタ型と対称的なアーキテクチャとしてP2P型があります。P2P型のアーキテクチャでは、マスタとなるプロセスが存在せず、すべてのノードが同じ役割です。CassandraなどがP2P型のアーキテクチャを採用しています。
P2P型のアーキテクチャでは、マスタとなるプロセスが存在しないので、ノードの状態管理やコーディネーションを工夫する必要があります。
Cassandraはゴシッププロトコルを用いてこれらを行なっています。
