- In-Memory 방식이 존재 : 사용하려는 모든 데이터는 우선 메모리에 로딩되는 과정이 존재
- 코어 데이터 : 읽고 쓰는 모든 데이터는 원칙적으로 메모리에 로드된 다음에 처리 (영구 저장소를 아예 사용하지 않고, 순수하게 인 메모리 방식으로만 사용하는 것이 가능)
- In-Memory : Disc에 저장하지 않고, 휘발성으로 잠깐 이용하려는 경우에 In-Memory로 사용
- Entity를 통해 데이터 저장 구조 정의
- 다른 DB방식은 테이블을 통해 데이터 저장구조를 정의
- Entity : 데이터가 저장될 구조
- Attribute : 엔티티의 하위 속성들을 정의하는 역할
- Relation : Entity간의 관계 정의
- Fatched Properties : 템플릿의 형태로 만들어 둔 것 (반복되는 요청이나 값만 바꾸어 비슷한 요청들을 묶어놓은 것)
용어
| SQL | CoreData |
|---|---|
| 데이터베이스 파일 | 데이터 모델 파일 |
| 테이블 | Entity |
| 컬럼 | Attribute |
| 외래키+조인 | 릴레이션 |
- 데이터를 객체로 취급 (테이블의 행, 레코드 하나하나를 독립된 객체로 사용)
- 사원 정보의 레코드 정보 2개를 읽을 때, 2개의 사원 객체가 생성
- DAO 패턴
- SQLite에서 DAO 클래스를 생성하고, 그 객체로 접근하는 것과 같이 사용 (단, core data는 DAO 객체가 자동으로 생성됨)
- Managed Object: MO 패턴
- Value Object 패턴과 동일, Core Data에서는 MO 패턴이라고 하며, MO 클래스의 프로퍼티를 Entity의 각 Attribute와 직접 연결시키는 방식을 사용(ORM 매핑)
ORM 매핑 : 객체와 관계형 데이터 베이스를 자동으로 mapping 시켜주는 방식
VO(Value Object)- 데이터 베이스의 한 레코드를 담는 객체
- 필드, 생성자, Getter/Setter 메서드 구성
- 레코드(행)의 갯수만큼 생성해서 사용
- 필드 클래스
- VO 객체, Domain 객체, DTO 객체, 자바빈즈라고 부른다.
객체 그래프 관리자 (Object Graph Manager)
Core Data는 어플리케이션에서 Model 계층의 객체를 관리하는 데 사용하는 프레임워크이자, 라이프 사이클이나 영속성 관리를 위한 기능을 제공하는 객체 그래프 관리자 (Object Graph Manager)
1. 객체 그래프(Object Graph)란?
- 객체를 하나의 노드로 간주, 서로 간의 연관 관계를 링크로 이어보면 다양하게 연결되는 복합적인 그래프 형태의 도형
- 객체 : 독립적이고 자체적인 생명 주기를 가지면서 속성과 기능으로 이루어진 단위 구성체
- 특성 : Core Data가 객체 그래프를 담당한다는 것은 객체끼리 연결할 수 있으며, 그 객체끼리는 영속적으로 동기화
- 연결된 A, B 두 객체에서 A 객체에 데이터가 삭제되면 자동으로 B 객체 데이터도 삭제
- DB는 두 테이블에 연관 정보를 불러오려면 join 조건이 필요
- 코어 데이터의 구조
- 관리 객체 (Managed Object): NSManagedObject
- table에서 레코드를 읽을 때, core data에서는 객체가 생성되는데, 이 객체를 저장하는 자료형
예시 : 직원들의 데이터를 다룰 때, DB에서 직원들의 정보를 읽어오면 그대로 사용하지 않고, VO 인스턴스에 담아서 사용, 이럴 때 VO가 관리 객체에 해당
- 관리 객체 컨텍스트 (Managed Object Context)
- MO를 가지고 CRUD 역할 (Core Data에서 생성되는 모든 관리 객체는 Context에 담겨 관리)
- Context에 담긴 객체는 영구 저장소로 보내 저장, 삭제 가능
- Core Data는 메모리에 로드된 상태로 처리되는데, 이 때의 메모리가 "Context"를 의미
- "영구 저장소"와 "영구 저장소 코디네이터"에 대한 관리자 역할
- 읽기와 쓰기를 영구 저장소에 요청 (DAO패턴과 유사)
- 영구 저장소 코디네이터(Presistent Store Cordinaotor)
- Context와 직접 데이터를 주고 받으면서 다양한 영구 저장소들의 접근을 조정하고 입출력을 담당
Context가 데이터 요청 -> Cordinator가 요청을 받고, 영구 저장소에서 데이터 탐색 -> Cordinator가 MO 인스턴스를 생성하여 반환
- 관리 객체 모델 (Managed Object Model)
- Entitiy의 구조를 정의하는 객체인 동시에 이를 바탕으로 MO패턴의 모델 클래스를 참조
MO vs MOM(Managed Object Model)
- MOM : 클래스이자 형식, 구조를 의미, 데이터를 CRUD하지 않으며 관리 객체의 각 요소를 제대로 담을 수 잇도록 저장 데이터를 구조화
- MO : MOM을 바탕으로 생성된 인스턴스
- CRUD : Create, Read, Update, Delete
- 영구 객체 저장소(Presistent Object Store)
- 초기에는 직접 읽을 수 있으며, 디버깅에 용이한 XML 저장소 타입을 사용
- 앱을 배포할 당시 대량의 데이터를 고려하여, SQLite 데이터 베이스를 사용하는 것이 용이
| 타입 | 설명 |
|---|---|
| 인메모리 저장소 타입 (NSInmemoryStore Type | 메모리 기반의 저장 방식(영구 저장소 사용 X), 앱 종료시 데이터 보존이 되지 않음 |
| 플랫 바이너리 저장소 타입 (NSBinaryStore Type) | 데이터를 단순 바이너리 파일 형식으로 저장, 장점은 조회 성능 개선, 단점 초기 로딩 시간 증가 |
| XML 저장소 타입 (NSXMLStore Type) | 원자성, 장점은 직접 열어보고 확인 가능(초기 디버깅용이), 단점은 처리 속도가 느림 |
| SQLite 데이터 베이스 (NSSQLiteStore Type) | 객체 그래프 중 일부만 로딩, 가장 많이 사용됨 |
- 바이너리 방식은 원자성을 갖지만, SQLite 같은 경우는 그렇지 않음(파일 손상이 발생할 가능성 존재)
"영구저장소"와 "레코드(메모리에 저장된 데이터)"사이의 데이터 교환 원리
- "차등저장(Differencial Save) 매커니즘" : 매번 데이터 전체를 커밋하는 대신 마지막 저장 이후에 변경된 부분만 커밋, save() 메서드 호출
- 매 작업 단위마다 커밋을 하게 되면 오버헤드가 발생하므로 최대한 늦게 해주는 것이 효율적
코어 데이터의 한계
- In-Memory 방식 : 메모리에 로딩된 객체에 대해서만 수정 가능(SQLite는 메모리에 객체 모두를 로딩하지 않아도 최소한의 데이터만 로드)
- In-Memory에서 데이터 삭제 시, 영구 저장소에서 데이터 read -> 객체로 생성 -> 이것을 메모리에 로딩 -> 이것을 삭제하고 다시 Context를 저장소에 Commit
- 데이터 로직에서의 한계
- 중복된 값의 입력을 방지하는 "Unique"키가 없으므로, 어플리케이션에서 비즈니스 로직을 통해 처리해야 가능
- thread-safe하지 않음(싱글스레드 환경)
- thread 끼리 Lock기능(다른 thread가 침범하지 못하는 것)이 존재하지 않음(단 Lock을 걸지 않음으로써 빠르게 데이터 처리가 가능)
- SQLite 역시 single thread만 지원
출처 : 김종권의 iOS 블로그
제로부터 시작하는 이세계 Swift