前回、「ACID原理とCAP定理」という記事で、NewSQLが生まれた背景を説明しました。説明といっても、ざっくりとNoSQLデータベースが生まれた背景に触れ、でもNoSQLはACID原理に準拠できなくてOLTP（オンライン トランザクション処理）をサポートできないよね → そこで、NewSQL登場！→ つ・づ・く… という流れでした。つづきが気になって気になって食事が喉を通らない読者が餓死してしまわないように、がんばって続きを書きたいと思います。
NewSQLはどうやってCAP定理の壁を乗り越えたのでしょうか？
前記事を読み返すと、最後にこう書いてあります。ならば、話は簡単です。はい、NewSQLはCAP定理の壁を乗り越えていません。めでたしめでたし。
というわけにはいかないので、CAP定理についてもう少しだけ解説しておきましょう。ブリュワーさんが「分散システムでConsistency（一貫性）、Availability （可用性）、Partition-tolerance （分断耐性）の3つを同時に提供できない」と断言したのだから、できないものはできないのです。ブリュワーさんも決して酔った勢いで言ったわけではなく、研究成果として発表したのだし、NoSQLとNewSQLの両者もそこを覆そうとはしていません。
覆すどころか、必死で妥協点を探っています。この3つのうちの2つしか提供できないのなら、さて、どれを捨てるか、と。1つ犠牲にしなければならないのなら、まずPartition-toleranceは捨てられません。複数ノードにまたがるサーバーが、ノード間の連絡が途絶えたらもう機能しない、なんてことは許されません。それが許されるなら、そもそも分散すべきではなかったことになります。そんなことでへこたれるなら、最初から1ノードで貫け！と星一徹に卓袱台返しされてしまいます。
だから、分散システムにPartition-toleranceは不可欠です。
では、ConsistencyとAvailabilityのどちらを捨てるのか？
それならConsistencyでしょう。だって、クラウド時代に可用性は捨てられないし、それに昨今は多様性の時代です。十人十色、複数の見解があって然るべきで、最終的に一致すればそれで良いのです。人はそれをEventual Consistency（結果整合性）と呼びます。たとえば、ソーシャルメディアなど、膨大なデータを処理するために分散システムによる拡張性は重要だし、可用性も捨てられないけど、同時進行の一貫性にはユーザーは気付きもしません。そう、結果的に一貫性が保たれていれば、途中の不備はバレないのです。
なんだ、バレないなら、いいや・・・
という問題ではなく、重要性の問題です。別にズルするのではなく、Consistencyの優先順位を他の2つより下げただけです。NoSQLを責めないであげてください。
でも、AvailabilityをConsistencyより優先したはいいけど、それでAvailabilityは完全なの？と問われたら、NoSQLは何と答えるでしょうか。優秀なNoSQLシステムは、「もちろん、ファイブ ナインズ（five nines）のHA（高可用性）さ！」と胸を張って答えるでしょう。つまり99.999%、これは一年間のダウンタイムが5分半を切る優秀さです。システムの開発者も運用者も十分満足する数字で、誰もはなから100％など期待していません。
え、今、何と・・・？
優先順位を下げられたConsistencyはきっと唖然として、耳を疑っている違いありません。100%じゃないの？ じゃあ私を捨てたのは一体何のため？ どうせ100%じゃないのなら、パーセンテージを少し下げて、私の100%を目指したらいいじゃない・・・
至極ごもっともです。はなから完全なAvailabilityを諦めているのなら、完全なConsistencyを目指して、どれだけAvailabilityを下げずに済むのかに挑戦したほうが理にかなっています。理にかなっているだけでなく、それでOLTP（オンライン トランザクション処理）もサポートできるのです。
はい、こうやって生まれたのがNewSQLでした。NewSQLデータベースは、スケールアウト可能な分散システムでOLTPをサポートするというニーズ面だけでなく、CAP定理の妥協をできるだけ小さくする観点からも、クラウド時代の申し子としてとして生まれるべくして生まれたデータベースなのです。めでたしめでたし。
次回は、NoSQLがどうやってConsistencyを確立したかについて書くかな？ いや書かないかな？ ま、ちょっと覚悟はしておけ。
RSSフィードを取得する
