이벤트 소싱을 사용하는 CQRS는 시스템 중 하나의 아키텍처로 완벽하게 적합하다고 생각합니다. 현재 걱정하고있는 것은 하나뿐입니다. 많은 양의 이벤트 처리 및 결과적으로 거대한 이벤트 스토어.이벤트 소싱에서 많은 양의 이벤트 처리
우리의 현재 시스템은 하루에 약 100 만개의 이벤트를 수신합니다 (현재 이벤트 소싱과 관련이 없습니다). 오랜 기간 동안 이벤트를 저장하려면 이벤트 저장소가 상당히 커질 수 있지만 롤링 스냅 샷을 자주 비우거나 제거하면 이벤트 소싱의 큰 장점 중 하나 인 시스템 히스토리 및 재생에 대한 정보가 손실 될 수 있습니다.
CQRS 아키텍처에서이 문제를 처리하는 일반적인 방법은 무엇입니까? 그것은 전혀 문제입니까? 이벤트 저장소에 더 많은 하드웨어를 던지거나 아키텍처 설계 단계에서 수행 할 수있는 작업이 있습니까?
가장 일반적인 방법은 스냅 샷과 영구 읽기 모델을 사용하는 것입니다. 즉, 새 읽기 모델을 작성하거나 기존 읽기 모델을 변경해야하는 경우를 제외하고는 실제로 이벤트를 자주 재생하지 마십시오. 도메인 객체의 스냅 샷을 저장하면 긴 이벤트 스트림을 재생하지 않아도됩니다.
스냅 샷 및 영구 읽기 모델을 저장하는 것이 이벤트 소싱이없는 CQRS를 수행하는 것과 완전히 다르지 않다고 주장 할 수 있습니다. 그러나 오래된 모델은 읽기 모델에서 실수를했거나 새로운 정보를 얻거나 다른 엄격한 감사 요구 사항이 필요한 경우에 발생합니다.
비즈니스 가치가 낮은 많은 이벤트가있는이 응용 프로그램에서는 이벤트 로그가 더 작게 유지되도록 실행 중에 이벤트를 많이 비울 계획입니다. 그러나 우리는 일부 객체에 대해서는 여전히 스냅 샷과 영구 모델로 돌아갈 것이라고 상상합니다.
"활성 스트림 세트"를보십시오. 상대적으로 짧은 기간 동안 돌연변이가 발생하고 최종 상태에 도달하면 죽는 수명주기가있는 스트림이 있습니까? 그렇다면 이러한 스트림을 저렴한 스토리지 (백업)로 옮길 수 있습니다. 필요로하는 유일한 이유는 재생 목적을위한 것일 뿐이므로 응답 속도가 느리지 만 액세스가 가능하도록하거나 재생 목적으로 압축 된 사본을 보관할 수도 있습니다. 어떤 경우 든, 이벤트 저장소 밖으로 이동하거나 적어도 활성 스트림 세트 밖으로 이동할 수있는 스트림이 있는지 의문을 제기하십시오.
또 다른 옵션은 여러 물리적 이벤트 저장소에 스트림을 분할하는 것입니다. 어쩌면 사용할 수있는 지리적 경계가 있거나 어쩌면 자연스럽게 파티션을 구성하는 항목이 있습니다 (일반적으로 힌트를 제공하는 도메인). 장점과 단점에 대해 생각해야 할 때입니다.
이 기술은 이벤트 소싱에만 국한되지 않습니다. 이는 국가 기반 모델에도 똑같이 적용될 수 있습니다.
우리는 새로운 읽기 모델을 만들거나 기존의 모델을 변경하거나 실수를하거나 새로운 정보를 얻을 필요가있을 때를 제외하고는 실제로 이벤트를 자주 재생하지 않습니다. 우리가 이벤트를 더 자주 닦는다면 우리는이 일을 할 수 없습니다. 당신은 * 오래된 사건이 거기에 있다고 말합니다. 그러나 우리가 너무 빨리 문질러 닦을 때, 그들은 역사상 충분하지 않습니다. – bitbonk
실제로 많은 이벤트가 비즈니스 가치가 낮다는 사실에 주목했습니다. 우리는 그들이 미래에 대답 할 수없는 특정 질문이 있다는 것을 깨닫고, 그들이 스크럽 될 수 있다는 결정을 내렸다. 그렇지 않으면 나는 마법 답이 있는지 확신하지 못합니다. 가능한 빨리 이벤트를 다시 읽어야합니다. 즉, 경계 상황에 따라 이벤트 저장소를 보유하거나 병렬로 다른 읽기 모델을 다시 빌드 할 수있는 방법을 찾는 것입니다. –
Makes 감각! 감사! – bitbonk