[ SQLiTE ] Local DB Update process (2)

이전글 : [ SQLiTE ] Local DB Update process (1) 

현재까지 Flutter 로 만든 앱들의 동작 환경을 살펴보면 휴대폰 내부에서는 SQLiTE 를 사용하고, 서버는 주로 Docker 로 구축한 MariaDB (또는 MySQL)로 되어있다. 서버와의 통신은 Python 으로 만든 RestAPI 호출로 운영하고 있으며 SSL 적용한 WEB Server 도 컨테이너로 돌아가고 있다.   (참고 : [Environment] 개발 환경에 대해... )

처음에는 Database Update를 위해 효율 보다는 빠른 구축이 먼저였기에 서버의 API를 통해 버전번호를 체크/비교하면서 변경된 데이터를 조회해 온 후 휴대폰 내부의 SQLiTE에 Insert 와 Update 쿼리를 사용해 업데이트를 하면서 서버 Data와 Sync(동기화)를 해오고 있었다.
하지만 사용자가 많이 늘어나고 조금씩이지만 Update해야할 데이터들이 계속 누적되다 보면 Update를 위한 API 호출할 때 마다 응답받는 결과값의 사이즈는 계속 증가될 수 밖에 없으며 Connection 유지 시간 내에 데이터 처리를 못하게 되는 경우도 발생할 수 있기 때문에, API 호출 횟수를 여러번에 나눠서 호출해야 하는 경우도 발생 할 수 있다. 업데이트 시간을 조금이라도 더 줄이기 위해 Batch 처리를 하더라도, 이는 곧 서버에 주는 부하가 증가할 수 밖에 없음을 의미한다. 이러한 방식은 시간이 흐를 수록 신규 유저와 가끔 앱을 실행시키는 유저에게는 업데이트 하는 시간이 무척이나 길고도 지루한 기다림이 될 수도 있다.

그렇다면 해결 방법은?

업데이트 해야 할 데이터를 RestAPI 를 호출해서 응답받고 처리하고, 호출하고 응답 받고 처리하고...
이러한 방식 보다는 DB파일을 다운로드 받아서 통으로 교체하는 것이 훨씬 더 빠르게 처리 될 수 있지 않겠는가?
물론 서버에 최신의 DB파일이 준비되어 있어야 하고, 이를 위해 서버에서 스케쥴링 된 프로그램도 미리 만들어 두고, 다운로드를 위한 WEB 서버도 운영을 해야한다는 전제 조건이 있으며, DB파일의 사이즈도 제대로 비교/분석 해봐야 겠지만, 대개의 일반적인 경우 장점이 훨씬 더 많기에 필자는 DB파일 교체 방식을 더 선호하고 있다. 파일 다운로드는 비교적 수초 이내에 완료 되며 API 호출 결과값으로 DB를 업데이트 하는 방식보다는 월등히 빠르고 서버의 API 호출 부하를 크게 낮출 수 있다.

대략 위 도표와 같은 프로세스로 휴대폰 내부의 SQLiTE 파일을 업데이트 할 수 있다.
핵심 포인트는 사용자정보 테이블의 내용은 사용자별로 계속 유지할 수 있도록, Attach 명령과 함께 Dot명령(.dump) 을 대신하는 Query를 사용 했다는 점이다.