読者です 読者をやめる 読者になる 読者になる

RDBMSが強すぎる件

以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク!!!」という発言をしたことがあって、その考えは今もあまり変わっていない。

RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。

ところで問題(?)は、RDBMSは強すぎる、ということです。

たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理(つまり、結果整合性でよいような処理)」というのは、意外と多い。

多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「トランザクションはっとけば整合性が保たれていいよね」という感じでトランザクションが使われていることが多いのではないか。極端なところでは、web appの全てのリクエストの開始時にトランザクションを開始して、レスポンスを返すときにトランザクションをcommit(あるいはabortする)というような「フレームワーク」をオレオレで作っていたりするのではないか。

しかしほんらい、並行性を考えたら、トランザクションのような排他性のある制御は、可能な限り細かい粒度にしておくべきだ。めちゃめちゃでかいメソッドがsyncronizedで囲まれてたらみなさん怒るでしょ。

そう考えると、RDMBSの提供してくれるトランザクションは「ほんらいは」トランザクション整合性が必要なところでのみ用いるべきなのではないか。結果整合性で良いようなところでは、ほんとうのトランザクション境界のみでトランザクション整合性だけを保ち、あとはリトライとかいろいろ頑張って結果整合性を保つほうが良いありかたなのではないか。そうすれば並行性も上がる。

とはいえ、わたしたちの現実はそんなに単純に技術的な正しさ(とは?)だけで決まるわけではない。チームメンバーのスキルだとか、ビジネス上どれだけ堅牢である必要があるかとか、あるいはどれだけソフトウェアの速度が求められるのか、どれくらいのスケーラビリティを求められるのか、そういった諸々の要素によって「このソフトウェアはどのように設計されるべきなのか」は決まる。

なので、結論としては、トランザクション整合性であるべきなのか結果整合性で良いのかちゃんと判断した上で、「今回はほんらいは結果整合性でいいところなんだけど、楽するためにRDBMSトランザクションに頼っちゃおっか」とか「いやーRDBMSトランザクションに頼るほうが楽なんだけど、かなりシビアに更新がかかりまくるところだから、RDBMSにはトランザクション整合性だけ保証してもらって、ほかのところはワーカーに任せて結果整合性を取ろう」とか、そういうことを判断できるようになっておく、というのがわれわれ(誰?)に求められているのではないでしょうか。

正しい意見