SQLite 성능 최적화 사례 공유

iOS 개발을 최초로 접하고 알게 된 첫 번째 캐시 데이터베이스는 바로 SQLite이다. 그 뒤에도 SQLite를 중견 역량으로 사용해 왔다. 이전에 비교적 많은 데이터의 읽기와 쓰기를 접하지 못했기 때문에 성능 최적화에 대한 관심이 많지 않다. 이번에는 특정한 장면의 대부분이 대량의 읽기와 쓰기에 대해 성능 최적화를 하여 성능을 10배 향상시켰다.
대략적인 응용 장면은 다음과 같다.
매번 프로그램이 시작될 때마다 서버에서 일부 데이터를 추출하여 로컬 데이터베이스 두 테이블을 동기화하여 업데이트합니다. 존재하지 않으면 쓰고 존재하면 필드를 업데이트합니다.데이터가 적을 때는 몇 십 개, 많으면 천 개가 넘는다.
캐시된 데이터에 비동기적인 읽기와 쓰기가 존재할 수 있기 때문에 백그라운드 동기화 대기열을 만들었다. 모든 캐시 데이터베이스 작업은 이 대기열에 있다. 그리고 나는 데이터베이스를 쓰는 관건적인 코드의 실행 시간을 감시했다. 천 개의 데이터가 데이터베이스에 업데이트되는 데 30초가 걸린다. 디스크는 1.5M/s에 기록되어 있다. 비록 카드의 메인 라인이 없지만 이 소모는 백그라운드에서도 용납할 수 없다.
핵심적인 데이터베이스 조작은 대략 이렇다

for 1000 : {

Select -> Update Or Insert

Select -> Update Or Insert

}

두 개의 표가 관련되어 있기 때문에 두 번은 있을 것이다. 테스트를 통해 Select는 한 번에 소식이 거의 없지만 Update나 Insert([FMdatabaseQueue execute Update:])는 소모가 크다. 디스크에 쓸 수 있기 때문에 모든 SQL 문장을 연결할 수 있는지 생각하고 마지막으로 한 번만 생각하기 때문이다.그리고 나서 SQLite에 트랜잭션이 있잖아요. 그래서 FMDB를 이용한 트랜잭션을 시도했어요. 순환이 시작되기 전에 [db begin Transaction], 순환이 끝나면 [db commit], 포장하면 돼요.
트랜잭션 증가 이후의 대략적인 논리:

beginTransaction

for 1000 : {

Select -> Update Or Insert

Select -> Update Or Insert

}

commit

테스트 효과가 매우 좋아서 전체 소모 시간이 30초에서 2.8초 정도로 줄어들었고 단지 두 줄의 코드만 증가했다.
요약:
밟은 구덩이, 지나간 고비, 모두 이후의 경험이다
비록 사무를 교묘하게 이용하여 성능을 향상시켰지만 이렇게 하는 것은 사실 안전하지 않다. 다행히도 소속 장면에서 이 부분의 데이터에 대한 절대적인 일치 요구가 그리 높지 않다.
시뮬레이터와 팩시밀리는 때때로 테스트가 같은 문제를 재현할 수 없다. 소속 구조, CPU, 하드디스크가 모두 다르기 때문에 성능 테스트는 팩시밀리를 기준으로 하는 것이 가장 좋다.이 문제는 테스트할 때 시뮬레이터에 문제가 많았는데 하드디스크가 실제 컴퓨터보다 읽기와 쓰기 속도가 높기 때문에 많은 문제를 피했고 테스트할 때도 발견하지 못했다.
데이터베이스 디자인을 할 때 많이 고려하고 앞으로 어떻게 확장할지, 어떻게 업그레이드할지, 읽고 쓸 때 성능이 어떤지 많이 생각해야 한다