Martin Fowlerの新刊 NoSQL Distilled を読んだよ

NoSQL Distilledは、Martin FowlerとそのThought Worksの同僚によって書かれたNoSQLへの簡単な概略書です。ページ数も薄く、150ページ程度しかないのですが、英語が苦手な我々日本人には、かえってありがたいですね。概略書といっても、日本の本とは違い、実際に実運用で使った人にしか分からない、深く突っ込んだ考察も随所で行われています。

本書では、なぜNoSQLを使うのか、という理由を、水平スケーラビリティ、プログラムの容易さ(プログラムに適したデータモデルの利用)という2つとしています。

NoSQLの水平スケーラビリティについては改めて言うまでもありませんが、プログラムの容易さというのは興味深い観点だと思いました。いわゆるリレーショナルモデルとプログラム言語のデータモデルとのインピーダンスミスマッチを解消する手段としてNoSQLを使うという考え方です。

キーバリューストアやドキュメントデータベースなどでは、一つのレコードをAggregateというひとまとまりのデータと考えることで、配列やハッシュなどのごちゃまぜになったデータ構造をうまく保存できるとしています。この部分については、NoSQLのデータ構造をうまく説明していますので、一読の価値ありです。

またNoSQLの持つスキーマの柔軟性は頻繁な変更のあるシステムと相性が良いのではないかと指摘しています。

また本書では、NoSQLといっても水平スケール指向のものだけでなく、Graph Databaseのように一つのサーバーだけで動かすことを中心にした種類のものにも言及されています。

ドキュメントデータベースなどは、JSONなどのデータにたいして柔軟なクエリを行うこともできるので、一つのサーバーだけで動かすのでもメリットがあるのではないかと考察されています。DynamoDBなどにも対応して欲しい機能です。

但し、本書では依然としてRDBMSがデータベースの第一選択肢に止まり続けるだろうと述べています。私としても、本書を読んだ限りでは、NoSQLの利用は一部の大規模システムなどに止まるのではないかという印象を受けました。より広く使われるには、NoSQLソフトウェアやそれを取り巻く環境がもっと成熟してくることが必要ですね。

本書は列指向データベースのようなOLAP用のデータベースには触れられていなかったのが残念です。私の読解力では、本書で触れられているColumn-Family Storeというものが、Key-Value Databaseとどのように異なるのか全く理解ができませんでした。

NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた

最近はNoSQLなどといって分散データベースがやたらに流行です。私もDynamoDBを使ってみようと思って色々調べているところですが、学べば学ぶほど奥が深くて恐ろしくなってきます。

まず第一に言っておきますが、現在のところ、いわゆるKey-value store型のNoSQLのメリットは「書き込みのスケーラビリティ」であって、それ以外には大きなメリットはありません。

DynamoDBの場合は「管理不要」「高信頼性」というおまけが付きますので、また話は少し別ですけどね。

他のオープンソース製品を自分のサーバーにインストールするのであれば、RDBMSほどこなれていないNoSQLを運用するのは大変な苦痛と危険が伴うでしょうね。前の記事にも書いたように分散システムを運用するというのは困難かつ苦痛を伴う仕事ですから。

ですから、すさまじい数のアクセスがあるようなシステムでなければ、NoSQLを選択する意味はないでしょう。

データベースに関しては、高いサーバーを買ってなんとかなるなら、高いサーバーを買ってPostgreSQLでも動かしているほうがトータルではずっと安くあがると思いますよ。Xeonを80コア積んだHP DL980にFusion-IOを突っ込んでも1500万円あればおつりが来る時代ですからね。


さて、ここから先はだいぶ込み入った技術の話をします。私も専門家ではなく、Amazon Dynamo[1]の論文を読んだ程度で話をしています。間違っているところがあればご容赦を。

最近喧伝されているBrewerのCAP定理[2]という理論がありますが、一貫性(Consistency)、可用性(Availability)、ネットワーク分断耐性(Partition tolerance)の3つのうち2つまでしか同時に得ることができないという話です。

このPartition toleranceを誤って「分散」と捉えて、「クラウドでは分散は必須なのだから一貫性か可用性のどちらかを犠牲にするしかない」と言っている人たちがいます[3][4]。これは大きな間違いです。分断耐性とは、ネットワークが分断した場合にも動作できるかどうかという話であり、現実にネットワーク分断など滅多に発生しない以上、一貫性も可用性も問題なく確保できます。

ネットワークが分断した場合でもアクセスできるという特性は、DNSやCDNや巨大P2Pネットワークなどには必要な特性かもしれませんが、通常のシステムには不要と言えます。また、これはキャッシュやデータ伝搬の仕組みを使えばアプリケーション側で実装できます。従って、この定理は分散データベースとは何の関係もありません。

BASEはここでACIDと対比されていますが、このBASEもどちらかといえば、データベースのスケーラビリティの話というよりはキャッシュなどアプリケーションよりの話に思います。

この古い学会発表をもとに現代のNoSQLを語るのは、はっきり言って無意味ですし、有害だと思いますね。


NoSQLがしばしばconsistencyを犠牲にするのは決してCAP定理のためではなく、スケーラビリティを確保するためであると考えて良いでしょう。

DynamoDBではconsistent readをサポートしていますが、その場合、(Dynamoと同じquorumによる実装なら)特定の条件下では無限のスケーラビリティが失われるはずです。

Dynamoは、ハッシュキーによってデータを格納するノードを変えていますが、このとき同じハッシュキーに読み書きが集中したとしても、consistencyを犠牲にすれば、ノード数に比例した性能を得ることができます。なぜなら、その場合は同じハッシュキーのデータを格納するNノードのうち1ノードだけに書いたり読んだりすれば良いからです。

また、読み書きのどちらか一方がヘビーな場合にはconsistentでもスケールすることができます。書き込みヘビーなら、書き込みは1ノードに行い、読み込みは全ノードに行えば、読み込みがスケールしない代わりにconsistentです。読み込みヘビーならその逆ですね。

それに対して、consistentに読み書きの双方を行う場合には、最低でもNノードの過半数にたいして書き込みと読み込みを行わねばならず、ノード数に比例したスケーラビリティが得られないことになります。

そこでeventual consistencyという話がでてくるのであり、CAP定理とは何の関係もない話なのです。ハッシュキーが十分に分散していればconsistentでもスケーラブルで可用性ある分散データベースが作れるはずです。


しかしこのように一つの値についてconsistencyが確保されたとしても、残念ながらACIDが実現されるわけではありません。なぜならCAP定理やDynamoDBの言うconsistencyというのは、ACIDのconsistencyとはレベルが違うからです。前者は、最後に完了した書き込みのデータが常に読み出されるというだけの話です。後者では、複数のレコードやテーブルやインデックスにまたがる一貫性が必要です。

(ここから先は適当な推測で書いてます)

ACIDを実装するためには、基本的には、トランザクションマネージャが全てのトランザクションを受け付けて、順番を管理して、順番が入れ子になった書き込みなどが起きないように管理する必要があります。これはスケーラビリティを大きく損なう事態です。ですので、NoSQLではACIDを実装することは本質的価値を損なってしまうのです。

一貫性のある書き込みができなければ、データベース全体として不整合な状態が生まれてしまうこともあります。インデックスを管理するためにもatomicな書き込みが不可欠です。

NoSQLでSQLがサポートされないのは、実装の複雑さもさることながら、整合性のあるクエリを行うためにはスケーラビリティが犠牲になることが理由の一つかもしれませんね。

(適当な推測おわり)

システムのうち、80%くらいの動作は不整合性を許容できるかもしれませんが、残りの20%ではどうしても整合性が必要です。そのときにはアプリケーション側で排他制御や整合性の管理を行う必要がでてきます。それではアプリケーションの開発効率を著しく下げてしまいます。

それが、NoSQLは特別にアクセスの多い場合だけ有効であり、普通のシステムで使うことはあり得ないという理由です。


ということで私はNoSQL全般には懐疑的なのですが、Amazon DynamoDBのように管理負担を軽減してくれるものであれば、もう少し広い利用価値があるような気がします。

実用になるプログラムを書こうとすると、どうしてもデータベースを扱う必要性がでてきますが、RDBMSを使うのは初心者や趣味プログラマ等には重荷であり、小さなプログラムを書くモチベーションを下げています。

DynamoDBを使うことで、もうちょい簡単にシステムが作れるようにならないかな、と思って少しアイデアを温めています。

NoSQL Distilledという新刊や、牛の本などの名著を読みながら、もっと勉強していこうと思います。

[1] Dynamo: Amazon’s Highly Available Key-value Store, Giuseppe DeCandia, et al.
[2] Towards Robust Distributed Systems, Eric A. Brewer
[3] Cloudの技術的特徴について --- ScalabilityとAvailability ---, 丸山不二夫 
[4] 結果整合性（Eventual Consistency）についての分かりやすいプレゼン資料 － Publickey

「アントレプレナーの教科書」から学ぶ「顧客開発モデル」の方法論

弊社がバイブルとしている書物の一つに「アントレプレナーの教科書」という本があります。この本では、連続起業家であるスティーブ・ブランクが新規事業立ち上げの方法論を明確なプロセスとして表現しています。

顧客開発モデルでは、顧客を見つけるために仮説設定と検証を繰り返していくプロセスを明示しています。顧客の困っていること＝ニーズは何か、という仮説を立て、それを早い段階からインタビューして検証します。プロトタイプを作成する前にも、質問などによってニーズがあるかどうかを検証していくことを推奨しています。

顧客のところにでかけていっても、すぐに自分の製品について説明したり、「どんな機能が欲しいか」聞いたりするのではなく、まずは顧客がどのように仕事を進めているか、どのような課題を抱えているか、その課題を自社の製品がどう解決できるか、そういうことを調べていきます。

世の中には起業本が山ほどあふれていますが、これほど「実用的」かつ「実践的」な起業本は少ないでしょう。

製品立ち上げのプロセスを４つの大きなステップ、「顧客発見」「顧客実証」「顧客開拓」「組織構築」に分けて、それぞれを数十の小さなステップに細分して説明しています。それによって細かい実践の方法がカバーされています。

起業本の革命児とも言える書籍であり、アメリカでは本書を元にして「リーン・スタートアップ」などの新しい理論や書籍が次々に誕生しました。

この本は素晴らしい本なのですが、ちょっとした弱点があります。

分かりやすく読みやすい本ではあるのですが、分厚く細かく書かれているので、再読したり、事業の最中にちょっと参考にするには重い感じがするということです。

もう一つには、ステップが細かく書かれているのは良いのですが、具体的に書かれすぎていて、実際の事業に当てはめるときにかえってわかりにくいという点です。

そこをカバーするフォロー本として「顧客開発モデルのトリセツ」という電子書籍が出版されました。この本は、アントレプレナーの教科書を読んだ二人の読者が、その本をフォローする解説本として自費出版した本です。

100ページほどの簡潔な電子書籍となっており、いつでもどこでも何度でも読み返しながら顧客開発モデルについての理解を深めることができるようになっています。

私も「アントレプレナーの教科書」を毎回読み返すのは荷が重いと思ってましたので、この電子書籍が出版されたことは福音だと思っています。

顧客開発プロセスを別の角度から見直すことで、顧客開発モデルについてより詳しく、深く理解することができますからね！

ギーク達の破滅の物語

私は普段フィクションは漫画しか読みません。小説や映画などは時間がかかりすぎるとおもって敬遠しています。しかし、主人公がギークとなれば話は別です。

ギーク(geek)とは、私の定義では、理系男性で、自閉的な性格傾向をもつ変人たちのことです。優秀なプログラマーには、このような性格類型を持つ男性が多く居ます。

ここに紹介する三編の小説は、どれも英国の小説で、皮肉で、滑稽でもあり、やや文学的でもあり、主人公のギーク(科学者またはプログラマー)が冒険をして恋をして破滅するという物語です。

ギーク達がもつ幼稚な愛情、または愛情の欠如が物語に乾いた歪みをもたらします。

ギークは他人が苦手であり、他人とあまり関わろうとしない傾向があります。しかし完全に孤独を好むわけでもなく、彼らが他人と関わるときには常に危うさが伴います。

ギークは恋愛が苦手であり、性欲が薄かったり、愛情が薄かったりします。しかし(以下同文)

そうした彼らが人間と関わり社会と関わるときにどのような問題を引き起こすか、冷めた語り口で、ギークの視点から見ていったのが、これらの物語です。

これらの中でも、「ソーラー」で描かれた、ギークのくせに徹底して俗物で好色で無責任でデブでハゲでチビのマイケル・ビアードという人物に好感と親近感を抱きました。

彼は、他人に興味がなく、他人への誠実さへの欠片も無いくせに、セックスとお金と賞賛が大好きという最低・最悪の人物です。そのくせ、血も涙も無い凶悪人物というわけでもなく、徹底して小人物なのです。

このような人物に嫌悪感を持つ人もいるかもしれませんが、私は彼にこそ人間性の真実を見いだします。俗悪な人物でありながらも、成功と虚栄と求めて、人類の発展に貢献してしまったりする、そんな生き様こそ人間的であり人間の真実だと思うからです。

家族愛にあふれた人たちもいれば、他者を顧みずに数式やコードを愛する人もいる、そんな人間の多様性というものが、この人類の発展を生み出してきたのですから。

日本にもこれくらい俗悪なギークがどんどん増えて、俗悪なベンチャー企業をどんどん立ち上げてくれたら面白くなるのになあ、と思いましたよ。もっと欲望にまみれて生きていきましょう。