RDBに代わるスケーラブルなデータモデルの必要性

このあたりの内容を卒業研究にする予定で、中間報告書まで書いたけど、整理と裏付けが全然追いつかなくて卒論なんて書けそうにないので、とりあえずテキトーにブログに書いておくなど。


データストアには、状態を永続化して共有する機能と、データモデル（状態を操作する意味論）を規定する機能の、２つの機能がある。この２つの機能を、より使いやすく、より高速に、よりスケーラブルに提供することが求められる。そうでないとシステム全体が成り立たない。


冗長化とか負荷分散とか、ハードの質に頼らない高性能なシステムを構築したいときは、「状態を持たないようにする」のが定石になる。同じ状態を２台のホストで同期し続けたり、状態を分割しながら整合性を保ち続けるのは、非常に難しい。このため、状態は共有データストアに保存しておくのがもっとも簡単で、現実的な解になる。


MVCアーキテクチャにおけるViewとControllerはModelの上に成り立っており、そのModelの実装は、データストアの機能に依存するところが大きい。データストアがアトミックな操作を一切サポートしていなければ、いくらModelでがんばっても、高速なトランザクションを実現するのは難しい。データの検索や絞り込みについても同じで、データの物理的な分布を知らないアプリケーションがいくらがんばっても、高速な実装は難しい。


従来は「高級」なデータモデルを保ったまま、状態を共有する機能を高めてきたが、ここにきて困ったことに、物理的な限界が見えてきてしまった。
…と言うと正しくないかも知れない。物理的な限界には達していないのだが、（高級なデータモデルを保ったまま、状態を共有する機能を高めるのは、高級なデータモデルを諦めることに比べて）コスト的に高くなってしまう、と言う方が正確かも知れない。

@frsyuki データモデルが関係代数などが規定する論理的な構造、サーバへの保存はストレージのモデルで物理的な構造。この2つの組み合わせでいいのでは。
http://twitter.com/masayh/status/6654253395


経済原理はこの意味では、論理か物理かのいずれを優先するかを選ぶといえます。保守による長期的コスト低下より、短期開発による売り上げの増大や開発コスト低下を選んだのでしょう。
http://twitter.com/masayh/status/6655773843


同様にコスト低下はクラウドを生みだして、サーバ集約やスケールによる物理レベルでの解決も併用するようになった。これは理性レベルでの生産性、保守性だけでの追及では飽き足らなくなった貪欲な経済原理の進展を意味します。
http://twitter.com/masayh/status/6655822982


ここで言うデータモデルの「高級」さとは、「アトミックに更新できる単位が大きい」ことを意味している。
アトミックに更新できるとは、あるデータを書き換えるときに、すべて更新されるか、まったく更新されないかの、どちらかにしかならない、ということである。一部のデータだけが更新されたような中途半端な状態にはならない。


例えばRDBMSはとても高級なデータモデルを提供していて、すべてのデータをアトミックに更新できる（アトミックに更新できる単位が全データ）。どこのデータを選んできても、アトミックに更新できる。
この特性がどれだけ重要かは、あまり理解できていないが、普段RDBMSを使っている方々にしてみれば当然のことの様に重要なのではないかーと予想している。


一方でKVS（key-value store）はとても貧弱なデータモデルしか提供していなくて、１つのデータしかアトミックに更新できない（アトミックに更新できる単位がvalue）。あるvalueを更新するとき、そのvalueの前半の数バイトだけ更新されたような中途半端な状態にはならないが、複数のvalueをアトミックに更新することはできない。


なぜ今になってkey-valueなる貧弱なデータモデルが（一部で）流行し始めたかと言えば、アトミックに更新できる単位を限定した方が、スケーラブルな実装が作りやすいのである。


ここで、CAP定理という（誤解されやすくて誤用しやすい）法則がある。
複数のサーバの分割して保存されたデータを、必ず Atomic に更新できるように保証しようとすると、応答を返せなくなってサービスが止まってしまうことがあるので、サービスの可用性を向上させるには、Atomic に更新するデータは複数のサーバーに分割しないようにするか、Atomic に更新することを諦めるしかない（と読めたけど違うかも）。


そこで、CAPのどれを捨てるかと言う議論がある。

例えば、複数のデータを更新するときに、Atomicでなくても良いとすれば（CAPのCを捨てる）、Availability と Partition Tolerance を満足できる。つまり、一応は複数のデータを非同期に（Atomicでなく）更新できる特性を保ちながら、いつでも高速に応答できて、複数のサーバーにデータを分割してスケールアウトできる。
一方で、たまにデータがロックされっぱなしになって応答を返すのに時間がかかるような状況になっても良いとすれば（CAPのAを捨てる）、分散トランザクションなどを使って、Atomic と Partition Tolerance を同時に保証できる。
あるいは、データを複数のサーバーに分割してスケールしなくても良いとすれば（CAPのPを捨てる）、データをすべて１台のサーバーにまとめて Atomic と Availability を同時に保証できる。


…が、詳しくは前の参考文献にお任せして、分かりやすい観点だと、Atomic に更新可能な範囲を広くすると、その範囲では（物理法則的に）スケールアウトできないんだーというのがポイントだと思う。

つまり、スケールアウトが必要なら、すべてのデータをAtomicに更新できるというRDBMSのデータモデルに代わる、新しいモデルを考える必要がある。RDBに代わるスケーラブルなデータモデルが必要だ。


ときに、本当にスケールアウトする必要があるのか、という話がある。根本的だけど、実はここが一番紛糾しているんじゃないかと思う。

「クラウド」はマルチテナントシステムなシステムで、１つの企業だけで使う物ではない。だから１つに企業にとっては、スケールアウトする必要は無いとも言える。しかし「クラウド」がアノ価格で使えるのは、スケールアウトするシステムがあるからだろう。クラウドの価格が魅力的に映るのであれば、ウチにはスケールアウトは必要ないとは言えないハズだ。

それは規模の経済性が働いているからアノ価格になるのであって、巨大企業でもない組織が、ちまちまとスケールアウトするシステムを作っても意味がない、という話もあるだろう。しかし技術的に巨大企業に依存してしまうのは、また別の問題があると思う。


今はまだ、その新しいデータモデルが確立されていない時期だと思うので、そのあたりの知見を独占されずに収集しておくという意味でも、データモデルについてはよく考えておきたいところ。


データを分割して分散しなきゃならんねぇと考え始めると、次にそのデータを扱って何か処理を行いたいときに、「データを移動させるよりプログラムを移動させた方が速い」という話が出てくる。そこでMapReduceが出てきたりする（分散データストアのデータモデルは、それ以前の話になる）。分散されたデータの保存と処理も合わせて、分散システム全体を統合して考えられるようなデータモデルを確立できないかなぁ、と思う。