NoSQL -AmazonとGoogleの思想の違い - IT社員3人組によるリレーブログ

どうも、ITコンサルタントのShoheiです。

ようやくMacBook Airが到着しました。最高です。

さて、今日は以前Koheiの記事で紹介のあったNoSQLについて、もう一歩だけ踏み込んで議論をしてみましょう。

アーキテクチャには二種類ある

上述の記事では、3つのデータモデルについて説明がありました(カラム志向型データモデルも加えて４つで説明されることもあります)。

今度はデータの持ち方、ではなくアーキテクチャーに目を向けてみると、大きく2種類に分類することができます。

f:id:go-mount:20181113212207p:plain

図の左側に描いたものは、マスタ型と呼ばれていて、図の頂点部分にあたるマスタノードが配下にあるノードたちを管理する、という構図になっています。GoogleのBigtableがこの構造を採用しています。

一方左側はP2P(Pear to Pear)型と呼ばれます。AmazonのDynamo DBがこの構造です。こちらでは、Google系のようにマスターノードを立てるのではなく、個々が互いを管理する形になっています。

これらの特徴について、簡単に見ていきましょう。

2つの派閥

比較をしていく前に、Bigtable系／Dynamo系について簡単に説明しましょう。

それぞれ論文が発表されています。

例えばBigtableの論文には*1、以下のように、Googleのいろんなサービスの中で実際に使われていることが述べられています。

Many projects at Google store data in Bigtable, including web indexing, Google Earth, and Google Fi- nance.

またDynamoの論文*2 に関しても、Amazonサービスのコアであり、ショッピングカートなどの裏側の技術として使われていることも記載あります。

a highly available key-value storage system that some of Amazon’s core services use to provide an “always-on” experience.

それぞれの論文には、DBの中身のアーキテクチャまで解説がしてあります。それもあり、この二つは他の多くのNoSQL製品にも影響を与えてきました。

そのため、マスタ型・P2P型のところに上ではBigtable系／Dynamo系と記載をしています。

なお、前回記事のデータモデルの話と今回のアーキテクチャの話を表にまとめると、以下のようになります。*3

※イネーブラ型は一旦無視してください

f:id:go-mount:20181113215236p:plain

Bigtable系とDynamo系の違い

さて、話を戻しましょう。

上述のマスタ型とP2P型、これらのアーキテクチャの違いは何を生むのでしょうか。

結論から先に言うと、DBとして重視するポイントが違います。

重視するポイントについて考えるにあたり、一つ押さえておかなければならない概念があるので説明します。

CAPの定理 :CAPとは

整合性(Consistency),可用性(Availability),分断体制(Partition Tolerance)の頭文字をとって、CAPと総称される概念があります。

f:id:go-mount:20181113230326p:plain

それぞれの意味は記載の通りなのですが、Partitionsだけあまり今までのRDBMSだと意識されてこなかった言葉ですかね。

RDBMSの場合、書き込みを一台のマスタサーバにだけ行うことが多いのですが、一方でNoSQLは大量のサーバにデータを置いて読み書きするような使い方が想定されます。

この時、ノード間でデータを冗長化している場合、どんな問題が生じるでしょう。

一つ考えられるのは、あるノードに書き込んだ際、裏でノード間同期が走るかと思いますが、その際にノード間の通信が障害によりできなくなったら、つまりNWが分断されたら、データが書き込まれたことを他のノードに伝えられなくなります。そして不整合が起きる可能性が出てきます。この状態を、分断体制が弱いと言います。