EventSourcingDB 1.3.0、あらゆるリクエストに時間制限を設けて安定性を高める
EventSourcingDB 1.3.0 Is Available
EventSourcingDB 1.3.0がリリースされた。書き込みとEventQLクエリが大幅に高速化し、読み取りも改善。すべてのリクエストに時間制限が設けられ、60件以上の修正が含まれる。v2 APIが追加され、受理されたリクエストの結果をレスポンスボディで返し、各エラーに固有のコードを付与。v1 APIは2027年1月31日までサポートされる。アップグレード時はデータのバックアップや旧サーバーの停止など注意点がある。
サーバーがリクエストを受理した時点で、その結果はボディに含まれる。
- bythreads
開発者のスキルがイベントソーシングを使えるほど高かったIT運用の現場で働いたことがない。紙の上では良くても、ネックビアード向けだ。ジュニアにはコーディングできない。
- zbentley
EventQLは良さそうだが、
> EventQLの事前条件が評価されている間は、他のすべての書き込みが待機するので、何も割り込めない。その間も読み取りは続行される。どの書き込みも他の書き込みを長くブロックしないように、書き込みのEventQL事前条件は、書き込みの順番が来てから最大5秒間、すべてまとめて評価される。事前条件にそれ以上時間がかかる書き込みは拒否され、何も書き込まれず、400が返る。
(https://www.eventfoundation.io/docs/eventsourcingdb/precondi... より)
これは巨大なフットガンに思える。確かに、トランザクションセマンティクスを実装したり、一貫性/MVCC/スナップショットについて考えたりする必要はない。しかし、その代償は「すべてのUPDATE ... WHEREが他のすべての書き込みを最大5秒間妨げる」ことなのか？本当に？
それは悪いトレードオフに思える。適切なトランザクション性を実装する（多大な労力）よりも劣り、階層的にネストされたサブジェクトのサポートを削除してUPDATE-WHEREに対するグローバルミューテックスの制限を解除するか、サブジェクトに効率的にスコープする（中程度の労力だが、互換性を大きく損なう）よりも劣り、EventQL事前条件のサポートを完全に削除する（最小の労力）よりも劣る。十分に大きく、複数の開発者がいるシステムでは、「EventQL事前条件を使わない」という方針が実効性を持つとは思えない。
現状では、主要なイベントソーシングシステムが、あるクライアントの遅いEventQL事前条件によって最大5秒間ブロックされるのは、どこからともなく広範囲のダウンタイムイベントを引き起こす原因になると思う。
とはいえ、私が見落としている緩和策があるかもしれないが […]
- chaostheory
これは、一人の人間の生活と仕事の記憶や「思考」を保存したいパーソナルエージェントにとって、ドリフトや幻覚を防ぐために1台のマシン上で動かす場合には有用かもしれない…しかし、ライセンスのせいでそれは実現不可能だ。