技術者向けの連投ツイートを久々にしてしまいました。この辺りの知見が明確にできているのは技術者冥利につきますが、この辺りの知見を実装には移せておらず、ツイートできるレベルに留めてしまっているというのは技術者としてはちょっと悔しいですね。だけど、こうやって公開しておけば、いつか振り返っていただけることもあるかも知れない。

すなわち、次の通り。

オブジェクトごとに発生・消滅の時点属性をつけて消去しないが模範回答だが利用者全員に高価となり機能しません。こんなこともあろうかと kakotile という仕様は考えておきました。変化は算出すれば良くなりますが、これでも高価のよう https://github.com/gsi-cyberjapan/kakotile-spec/blob/master/README.md
履歴確認ニーズは利用の数%以下と考え、ふつうのファイルシステムにおける Time Machine のような動きをさせるようにするとこんな感じになるものと思います。あとはタイムスタンプの運用定義を現実的なものにして確実に回す。地物が複数タイルにまたがる時には迷わず全て書き換える。
編集が時間的に混み合う場合にも、難しく考えずタイル単位にロックすることにすれば大抵大丈夫。ただし、タイルレベルロックを導入するより作業者の運用で作業領域が実時間の上で重ならないようにする方が経済的のはずで、ロックを実装するコストをかけられるのなら手厚いバックアップに振向けるべき。
手厚いバックアップというのは、実際には分散ストレージ風に実装すると、多分うまく運用すれば平常運用時のパフォーマンスも稼ぐことになる。事故の時は慎重に書き戻しにも使えることにするキャッシュみたいな感じで。これはタイルで空間分割する利点の利用でもあります。
データのコンシステンシ確認を編集者を巻き込んだプロセスの中に埋め込むのも多分贅沢で、ライフサイクルを別にする変化確認エージェントみたいなものが別プロセスで動き問題を見つければタイル単位で通知するようにする。対話処理の速度とスケーラビリティ、ソフトウェアとデータの健全な分離のために
ソフトウェアを更新したらデータベースの再設計とマイグレーションが生じた、が、データ事業の最大の敵です。タイル方式はソフトウェア技術の数世代、情報の1/4世代くらいの実績を積みつつあり、タイルネイティブな書き換えプロトコルは検討の価値があるはずだと思っています。
語り尽くしておけば、情報は書き出しと発行については安価に時点が取れることに着目すれば、タイムスタンプは実世界事象から取るのではなくあくまで編集から取ることにし、必要に応じて発行についても考慮するべき。実世界事象の時刻にこだわれるリソースがあれば、それは編集の即時化に振り向ける。
情報は実世界のモデルではなく観測の記録である。観測と記録すなわち編集のループを究極に短く回すことではじめて実世界のモデルに迫ることができるのであり、編集のコストを上げる方向では、実世界のモデルに迫ることは永遠にできない。抽象化すればそういうことなのかなと思います。
ウェブの時代には、さらに刊行への考慮も欠かせません。伝わって初めて情報ですから、観測から記録、集約を経て刊行までが、要求仕様に沿った一気通貫のタイムラインのなかで考慮される必要がある。ステップごとに考えないことで得られるメリットは大きいと思っています。
従来通りの QA はするのだけど、細粒度にする、みたいなことになるとよい、ということですね。点検や検査、作業記録を省けという意図はまったく持っていません。念のため。