私は以前の記事で、「Graph DBでは、排他制御の設計が難しいのでOLTPに向かないのではないか？」という見解を書きました。
その後、Amazon Auroraの技術的基礎となっているLog-Structured Storageについて学んだり、その他"Append-Only"方式のDB製品があることを知りました。
そうする内に、"Append-Only"方式な設計を適用すれば、Graph DBで極めてスマートにOLTPを実装できるだろうことに気づきました。「更新」の都度、アクティブなノード（Vertex）を表すリンク（Edge）を繋ぎ足すことや、変更履歴となる「チェックポイント領域」の複数のエントリーからのリンクを多重に持つことなどは、Graph DBでは素直に設計することができます。
さらに考えると、（DatomicやCouchDBといった製品を用いないで、）"Append-Only"方式というDBアーキテクチャーを実装するとしたら、むしろGraph DBが（RDBより）適している、とさえ言えそうです。
〜・〜
5年前くらいですが、一緒に仕事させていただいた方が、企業の組織情報管理専用のデータ管理アプリケーションに取り組んでいらっしゃいました。それはGraph DBをベースとしたものでした。組織情報は一般に階層レベルが動的で、RDBにマップするのはなかなか厄介です。またマスターデータであり高トランザクショナルでも無いので、Graph DBがよく適するエンプラ・アプリの代表と言えるかもしれません。
その組織情報管理アプリは、「組織変更」が為されるとき、基本的に全変更履歴を保全するという設計でした。これは、技術的な問題からそうしたのではありません。内部統制観点から業務要件として、組織情報の変更履歴の保全や変更前後での組織の同一性のトレーサビリティが求められていました。
当時は設計意図を理解しきれていなかったのですが、今から考えるに、業務要件レベルで"Append-Only"が求められていたこのアプリケーションのケースで、Graph DBをアーキテクチャーの基礎にするのは極めてよく考えられた選択だったのだと分かります。
〜・〜
＜新たな結論＞
(1) Graph DBにとって"Append-Only"方式は相性がよいのではないか。
(2) Graph DBでOLTPするなら"Append-Only"方式を検討すべき。
(3) （業務要件から）"Append-Only"が求められるなら、DatomicやCouchDBといった製品を検討するとともに、Graph DBで構築することを検討してみるのがよさそう。
◆以上
