읽기-쓰기 분리
기업의 사업이 계속 확장되고 사용자 수가 크게 증가하면, 원래 데이터베이스는 스스로 유지하기 어려울 가능성이 큽니다. 그렇다면 네
- 스케일인 기능은 하드웨어 성능을 확장하지만, 사용자 수는 계속 증가할 가능성이 높고, 향상된 성능은 곧 잠식될 것입니다.
- 읽기-쓰기 분리: 데이터베이스는 버티지 못합니다. 읽기와 쓰기가 너무 많아서 특히 최근 24시간 동안 가장 인기 있는 제품처럼 복잡한 쿼리가 있을 경우 더욱 그렇습니다. 매우 복잡한 SQL 문이 필요하고, 물론 실행도 느립니다.
하지만 읽기와 쓰기를 분리하려면 데이터베이스를 마스터 라이브러리와 슬레이브 라이브러리로 분리해야 합니다.
시장에 나와 있는 주요 관계형 데이터베이스는 데이터 복제를 지원하므로, 데이터베이스를 마스터와 슬레이브 두 역할로 나누고, 마스터에 쓰기 작업을 하며, 마스터 서버를 다른 슬레이브 서버와 동기화할 수 있습니다.
읽기 작업과 데이터 분석과 같은 오프라인 작업은 슬레이브 서버에서 수행됩니다.
인터넷상의 많은 애플리케이션이 읽히기 때문에 여러 노예가 부하를 분담하고 데이터의 가용성과 정확성을 보장할 수 있다는 것을 알고 있습니다.
하지만 해당 원본 애플리케이션 코드도 수정되어야 하며, 데이터를 쓸 때는 마스터 라이브러리를 사용하고, 데이터를 읽을 때는 슬레이브 라이브러리를 사용하도록 변경해야 하며, 이는 재작성과 동일합니다.
복합 쿼리
하지만 코드를 다시 작성한 후에도 너무 많은 복잡한 쿼리가 사용되어 성능이 크게 향상되지 않았고, 데이터베이스 구성 요소에서 조인이 매우 성능 집약적이라고 말했습니다.
그렇다면 지난 24시간의 인기 상품을 별도의 테이블로 저장할 수 있을까요? 간단한 SQL만 사용하면 됩니다.
즉, 단일 데이터베이스 테이블 집합은 보고서, 검색, 트랜잭션 등 다양한 동작에 적합하지 않습니다.
현재 테이블은 데이터를 추가하고 수정하도록 설계되어 있으며, 복잡한 쿼리에는 적합하지 않습니다.
하지만 이 쿼리 베이스가 어떻게 업데이트되는지, 이 지연을 감당할 수 있는지, 실시간으로 업데이트되지 않을 수도 있는지도 고려해야 합니다.
CQRS
지연이 허용되는지 여부는 지난 24시간 동안 인기 있는 최고의 제품과 같은 비즈니스 관점에서 봐야 하며, 약간의 오래된 정보는 큰 영향을 미치지 않으며, 최종 일관성만 필요합니다.
우리는 CQRS(명령어 쿼리 책임 분리)를 사용할 수 있는데, 이는 명령어를 쿼리 책임과 추가하거나 수정하는 데 사용하는 방법입니다.
CQRS에서는 읽기(쿼리)와 쓰기(명령)의 분리에 중점을 둡니다. 사용자가 읽는 데이터는 보통 구식이기 때문에 데이터베이스에서 읽을 필요가 없고, 직접 읽은 데이터 소스를 설정할 수 있기 때문입니다. 캐시일 수도 있고, XML, JSON 등일 수도 있습니다.
앞서 언급한 업데이트 문제를 어떻게 해결하나요? 이벤트(Event)를 사용할 수 있습니다. 예를 들어, 제품이 판매될 때 원래의 Read 모델을 수정하기 위해 이벤트를 게시할 수 있습니다.
이렇게 해서 동기화는 이벤트 메커니즘을 통해 비동기적이 됩니다.
마지막으로, 이 방법은 복잡한 쿼리에만 사용하는 것이 가장 좋으며, 원래의 단순 쿼리는 여전히 관계형 데이터베이스에서 가져옵니다. 왜? 새로운 기술의 도입에는 동기 돌연변이 단계나 이벤트 메커니즘과 같은 대가가 따르기 때문에, 우리는 신기술의 장점만 보고 단점만 볼 수 없습니다.
|
게시됨 2020. 5. 4. 오전 9:58:50
|
|
|
|
