EventSourcingDB 1.3.0, 쓰기·쿼리 속도 크게 높이고 v2 API 추가
EventSourcingDB 1.3.0 Is Available
EventSourcingDB 1.3.0이 나왔다. 쓰기와 EventQL 쿼리, 읽기 성능이 모두 개선됐고 스토어가 커져도 쓰기 속도가 느려지지 않는다. v1과 나란히 도는 v2 API는 요청이 수락되면 결과를 응답 본문에 담아 돌려주고, 모든 에러에 자체 문서로 연결되는 코드를 붙인다. 요청·응답·유휴 연결에 시간 제한을 두고, 기본 활성화된 rate limiting과 OpenMetrics 헬스 엔드포인트 등 운영 기능도 보강했다. v1 API는 2027년 1월 31일까지 지원된다.
서버가 요청을 수락했다면, 그 결과는 본문에 담겨 있다.
- bythreads
저는 개발자들의 실력이 이벤트 소싱을 사용할 만큼 충분히 높은 IT 운영 환경에서 일해본 적이 없습니다. 종이 위에서는 좋고 수염 기른 덕후들에게는 좋지만, 주니어는 이걸 상대로 코딩할 수 없어요.
- zbentley
EventQL은 좋아 보이지만,
> EventQL 사전 조건이 평가되는 동안 다른 모든 쓰기는 대기하므로, 그 사이에 아무것도 끼어들 수 없습니다. 읽기는 그동안 계속됩니다. 어떤 쓰기도 다른 쓰기를 오래 막지 않도록, 한 쓰기의 EventQL 사전 조건들은 쓰기가 순서를 얻은 시점부터 최대 5초 동안 모두 함께 평가됩니다. 사전 조건 평가에 더 오래 걸리는 쓰기는 아무것도 쓰이지 않은 채 400으로 거부됩니다.
(출처: https://www.eventfoundation.io/docs/eventsourcingdb/precondi...)
이건 엄청난 발등 찍기 같습니다. 물론 트랜잭션 시맨틱을 구현하거나 일관성/MVCC/스냅샷에 대해 고민할 필요는 없겠죠. 하지만 그 대가가 "모든 UPDATE ... WHERE가 다른 모든 쓰기를 최대 5초 동안 막는다"라니요? 정말요?
그건 나쁜 트레이드오프 같고, (엄청난 노력이 필요한) 제대로 된 트랜잭션성 구현, (중간 정도 노력이지만 상당한 호환성 파괴가 있는) 계층적으로 중첩된 subject 지원을 제거해서 UPDATE-WHERE에 대한 전역 뮤텍스 제한을 해제하거나 subject 범위로 효율적으로 한정하는 것, 또는 (가장 적은 노력으로) EventQL 사전 조건 지원을 완전히 제거하는 것 모두보다 못합니다. 충분히 크고 개발자가 많은 시스템이라면 "EventQL 사전 조건을 쓰지 마라"가 실질적으로 지켜지리라고 상상하기 어렵습니다.
현실적으로, 주요 이벤트 소싱 시스템이 어느 한 클라이언트의 느린 EventQL 사전 조건 때문에 최대 5초 동안 막힌다는 건 어디서든 갑자기 광범위한 다운타임 이벤트를 초래할 것 같습니다.
그렇긴 해도, 제가 뭔가를 놓치고 있을 수도 있습니다 […]
- chaostheory
이건 한 사람의 삶과 업무에 대한 기억이나 "생각"을 한 대의 머신에서 실행되는 개인 에이전트에 저장해서 표류나 환각을 방지하고 싶을 때 유용할 수 있습니다… 하지만 라이선스 때문에 이건 실현 가능하지 않습니다.