MySQL CDC to Bigquery 환경에서 Soft Delete 를 권장해야 하는 이유

안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다.

 

 

 

 

 

목차

소프트 딜리트 vs 하드 딜리트

Mysql CDC

CDC와 Delete

DataLake DataWarehouse

DataLake와 Delete

Bigquery와 Delete

 

---

 

 

 

01. 소프트 딜리트 vs 하드 딜리트

 

소프트 딜리트란, UPDATE 명령어를 사용하여 삭제 여부를 알수 있는 컬럼에 데이터가 삭제되었다는 값을 넣어 표현하는 삭제 방법이다.

하드 딜리트란, DELETE 명령어를 사용하여 특정 데이터를 삭제하는 삭제 방법이다.

쿼리로 비교하면 다음과 같다.

 

아래와 같은, 고객 테이블(테이블명: customer)이 있다고 가정하자.

id	state	name	email
1	ACTIVE	김OO	email_one@gmail.com
2	ACTIVE	이OO	email_two@gmail.com
3	ACTIVE	박OO	email_three@gmail.com

 

이때, state는 고객의 상태를 의미한다.

 

 

 

 

1-1. 하드 딜리트를 했을 경우

만약 id를 기준으로, id가 3인 값을  HARD DELETE 처리한다면, 아래 쿼리와 같이 구성할 것이다.

DELETE FROM customer WHERE id=3;

이후, customer 테이블은 아래와 같이 변화되었을 것이다. (id=3 에 해당하는 데이터가 삭제된다.)

 

id	state	name	email
1	ACTIVE	김OO	email_one@gmail.com
2	ACTIVE	이OO	email_two@gmail.com

 

 

 

 

1-2. 소프트 딜리트를 했을 경우

그렇다면, 만약 하드 딜리트가 아닌 소프트 딜리트 처리를 하면 어떻게 될까?

만약 id를 기준으로, id가 3인 값을  SOFT DELETE 처리한다면, 아래 쿼리와 같이 구성할 것이다.

UPDATE customer SET state = "DELETED" where id = 3

 

이후, customer 테이블은 아래와 같이 변화되었을 것이다. (state가 업데이트 된다.)

 

id	state	name	email
1	ACTIVE	김OO	email_one@gmail.com
2	ACTIVE	이OO	email_two@gmail.com
3	DELETED	박OO	email_three@gmail.com

 

 

 

 

 

1-3. hard delete와 soft delete 중 어떤 것을 사용해야 할까?

hard delete를 사용했을 때 DB 공간낭비를 하지 않을 수 있다거나, soft delete를 사용했을 땐 추적이 용이하다거나, 등등 각자의 장단점이 있다고 한다.

따라서, 대부분은 soft delete를 권장하고 있으나, 비즈니스 로직에 따라 hard delete가 권장되는 경우도 있다.

 

하지만, 아래와 같은 경우라면 soft delete가 대체로 권장된다.

* Mysql CDC 환경을 사용하는 경우

* Data Lake 환경이나, Data Warehouse 환경인 경우

 

(이유는 아래 챕터에서 다루겠다.)

 

 

---

 

02. Mysql CDC to Bigquery와 Delete

 

 

2-1. MySQL CDC 

MySQL CDC(Change Data Capture)란, MySQL 에서 변경된 데이터를 실시간으로 감지하여 해당 변경 데이터를 캡처하고 & 캡처된 데이터를 이용하여 다른 데이터베이스나 애플리케이션에 전달하는 기술이다.

 

대표적인 CDC 방법은 mysql의 binary log를 바라보고, 해당 binary log를 송수신하여 DB 변경사항을 받아와 반영하는 것이다.

이러한 CDC 환경의 데이터 아키텍처에서의 Delete는 Soft Delete가 권장된다.

 

CDC 환경의 경우, 경우에 따라 Delete 쿼리가 추적이 어렵기 때문이다.

 

 

 

 

2-2. Bigquery 의 Streaming Insert  

나의 사례의 경우에는, MySQL CDC to Bigquery 상황이었다.

이때, CDC 니까 Streaming insert 방식으로 데이터가 들어가는 방식을 취하고 있다.

 

BigQuery Streaming이란, Google Cloud의 BigQuery 서비스에서 제공하는 기능 중 하나다.

BigQuery Streaming은 실시간으로 데이터를 전송하여 BigQuery 테이블에 즉시 삽입할 수 있는 메커니즘을 제공하는 특징이 있다.

따라서, 센서나 로그 & 클릭 이벤트 등을 실시간으로 수집하는 환경에서 주로 Streaming 기능을 사용한다.

 

 

그렇다면, Bigquery Streaming Insert와 Delete는 무슨 연관이 있는 걸까?

정답은, Bigquery Streaming Insert 에서는 Delete를 지원하지 않는다는 것이다. 이와 관련한 공식 문서는 아래와 같다.

https://cloud.google.com/bigquery/docs/reference/standard-sql/data-manipulation-language

 

따라서, 특정 row가 update가 되면 row가 직접 update되지는 않으나 변경된 row 버전이 insert 가 되어 문제가 없지만(최신 데이터 추출을 위해서는 각 id가 가진 최신 Kafka 오프셋의 row를 추출하면 DB와의 Sink가 맞게 된다.),

Delete 가 되어버리면 delete는 미지원 쿼리이므로, 특정 row에 대한 삭제가 되지 않는다.

 

따라서 MySQL에서 Hard Delete가 되면, Bigquery의 CDC Streaming Table과 Sink가 맞지 않게 된다.

따라서 해당 환경에서는 Hard Delete는 데이터의 정합성을 해치기 때문에 좋지 않은 선택이 된다.

 

 

---

 

 

03. 결론

 

찾아보면 Data Lake 또는 Data Warehouse 환경에서는, Hard Delete를 가급적 지양하는 것이 좋다고 한다.

위와 같은 사례 외에도, 데이터의 히스토리 추적 등에서도 훨씬 유리하기 때문이다.

 

이번 경험을 통해 MySQL CDC to Bigquery 환경에서 주의해야 할 사항을 한 가지 더 새기게 되었고,

Streaming insert 에 대해서도 더 자세히 들여다보게 된 계기가 되었다.

 

오늘의 포스팅 끝..ㅎㅎ