Fan Out On Write (Push Model)

Fan Out On Write (Push Model)

Fan Out On Read (Pull Model)로 설명을 하면, 게시물 작성 할 때 , 해당 회원을 팔로우하는 회원들에게 데이터를 배달하는 것입니다
일종의 인덱스? 역할을 하는 Timeline 테이블을 만들어, 조회 시간을 줄여 시간복잡도에서 이득을 가져 가는 것이죠

정리를 하자면, Fan Out On Write(푸시 모델)는 게시물이 생성되는 즉시 팔로워의 타임라인에 게시물이 전달되는 소셜 미디어 시스템에서 사용되는 전략입니다.
실시간 업데이트 및 즉각적인 데이터 일관성을 보장하기 위해 타임라인 데이터가 팔로워의 타임라인으로 푸시됩니다.

1. 단순화된 검색
   • 게시물은 이미 팔로워의 타임라인에 전달되어 있기 때문에 팔로워가 자신의 타임라인에 액세스할 때 추가 데이터베이스 쿼리 또는 검색 작업 없이 게시물을 검색할 수 있습니다.
   • 이는 검색 프로세스를 단순화하고 전반적인 성능을 향상시킵니다.
2. 쓰기 대기 시간 증가
   • Fan Out On Write 접근 방식은 쓰기 대기 시간을 증가시킬 수 있습니다
   • . 포스트 데이터를 여러 타임라인에 동시에 전달해야 하므로 다른 모델에 비해 추가적인 처리와 시간이 필요합니다.
3. 게시물 작성 중 시스템 부하
   1. 게시물을 여러 타임라인에 동시에 전달하면 게시물 작성 프로세스 중에 시스템에 추가 부하가 발생할 수 있습니다.
   2. 시스템은 팔로워의 타임라인에서 즉각적인 가시성을 보장하기 위해 게시물 데이터의 적시 전달을 처리해야 합니다.

흐름으로 이해하기

Fan Out On Read (Pull Model) 모델과 다르게, Timeline 테이블이 추가 되었습니다
테이블을 하나 더 두어서, 타임 라인 조회시에는 Timeline 테이블을 조회하여, 게시물들을 조회하는 것입니다
즉 Pull 모델에서의 조회시점의 부하를 쓰기시점의 부하로 치환 한 것입니다

새로운 Post가 들어오면, from to를 확인하고, Timeline에 Post id와 member Id를 하나로 묶습니다

마치며 : 트레이드 오프에 관하여

결국 ,Fan Out On Write (Push Model)은 공간 복잡도를 희생하고, Fan Out On Read (Pull Model)은 시간 복잡도를 희생합니다.

어떤 것이 데이터의 정합성을 보장하기 쉬울까요?
정답은 Pull Model은 원본 데이터를 직접 참조하므로, 정합성 보장에 유리합니다
하지만 Follow가 많은 회원일수록 처리속도가 느리다.

Pull 모델을 사용하는 회사로는 Facebook이 있습니다

반대로 Push를 사용하는 회사는 트위터입니다

Push 모델 같은 경우 게시물 작성과 타임라인 배달의 정합성 보장에 대한 고민이 필요합니다

모든 회원의 타임라인에 배달되기 전까지 게시물 작성의 트랜잭션을 유지하는 것이 맞을까?
예를 들어 접속이 적은 유저들에게도 실시간으로 데이터를 전달하기 위해 자원을 사용해야하는 것이죠

결론적으로 Push Model은 Pull Model에 비해 시스템 복잡도가 높습니다
하지만 그만큼 비즈니스, 기술 측면에서 유연성을 확보시켜주죠(기존의 테이블과 분리되어 타임라인을 관리하는 등)

결국 은총알읍 없습니다. 개발자는 상황, 자원, 정책 등 여러가지를 고려해 트레이트 오프를 해야 합니다

부족한 점이나 잘못 된 점을 알려주시면 시정하겠습니다 :>