RDBとDAppsと役所仕事

ファイル保存や認証など、単発のアプリはDApps化は簡単だが、業務アプリや基幹系は相応に難しいはずだ。これをDApps化することは可能なのか、あるいは意味があるのかについて考えてみる。

これが難しい理由の一つは、トランザクションの存在である。DApps化のためには、データベース層とアプリケーション層の両方をDApps化する必要があるが、DAppsとRDBは相性が悪い。トランザクションが多発するため、分散すること自体が不利になるのだ。

BitCoinのような1取引1トランザクションなら問題は少ないのだろうが、RDBだと1取引が多数のトランザクションを誘発する。これを全てスマートコントラクトで構築しなければならないとなると、その計算時間は膨大だ。通信遅延も含め、総量がRDBの何倍必要になるか、想像することすら難しい。

これをできるだけ回避するには、RDBのR、すなわちリレーショナルな部分を破棄するしかない。もちろん完全には破棄できないから形だけの破棄となり、上位で作りこむ。本当にRが必要な部分だけをそこで書き、重要でないところでは無視する。

RDBのRの多くの部分は、計算機資源節約と整合性確保の目的で使われていて、トランザクション自体には滅多に係らない。例えば店舗のIDと正式名称などだ。これらは夜の定期メンテナンス時間に更新すればよい。

このように、業務で本質的に必要なトランザクションのみが動くようにDBをチューニングすれば、分散NoSQLでも使い物になるはずだ。

これを実現したとしても、やはり本家RDBよりは大幅に遅く、計算機資源の必要量は膨大になるだろう。そこまでして分散すべきか、というのは一つの課題である。

もちろん定性的な意味はあって、それは無停止性である。インターネットと同じく単一故障点を持たないこと、個々のノードに高性能や耐故障性(HPC等)、UPS、高速回線、セキュリティなどが必要ないこと、スケールアウトが簡単なこと(ノードを増やすだけ)、などだ。例えば国や自治体のシステム先日の東北の地震で役所が壊滅したような場合でも、情報を守ることができる。それをどれだけ評価するか、という問題だ。