IT社員3人組によるリレーブログ

某IT企業に勤める同期3人が、日常で思ったことを記録していきます (twitter: @go_mount_blog)

NoSQL -AmazonとGoogleの思想の違い

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

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

 

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

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

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

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

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

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

一方左側はP2P(Pear to Pear)型と呼ばれます。AmazonDynamo 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が分断されたら、データが書き込まれたことを他のノードに伝えられなくなります。そして不整合が起きる可能性が出てきます。この状態を、分断体制が弱いと言います。

CAPの定理とは

さて、CAPが何かわかったところで、CAPの定理に戻りましょう。

中身だけいうと、分散システムにおいては、CAPのうち、2つしか同時に満たすことができない、という法則です。言い換えると、分散システムでDBMSを実現するには、CAPのうち一つを犠牲にしなければならない、ということです。

改めてDynamo系とBigtable系の違い

さて、上でDBとして重視するポイントが違いますと述べましたが、もうわかったでしょうか。そうです。Dynamo系とBigtable系では、CAPのうち犠牲にしているポイントが違います。

超ざっくり書くと以下のようになり、Dinamo系はAP, Bigtable系はCPを選択しています。またRDBMSは前述の通り、あまり複数ノードによる分散制御を意識していなかったのでACを選択しています。

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

どんなイメージ?

AP重視とCP重視といっても、どんなイメージかわからないかと思うので、イメージを絵に描いておきます。

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

ただ、APの場合についても、やはりDBでデータの不整合が起きることは致命傷なので、BASE特性という特性を備えさせることで、弱い整合性を担保しています。

この辺りは話し始めると長くなるので、より具体的なアーキテクチャとともに次回説明していきましょう。

まとめ

NoSQLのアーキテクチャの概念と、CAPの定理について説明しました。