Firestore의 데이터 구조와 설계 방식은 어떻게 되나요?

Q1: Firestore의 기본 데이터 구조는 어떻게 이루어져 있나요?
A1: Firestore는 Documents(문서)와 Collections(컬렉션)를 중심으로 구성됩니다. 문서는 JSON 형태의 데이터 객체로, 키-값 쌍의 필드들로 이루어져 있으며 고유 ID를 가집니다. 컬렉션은 여러 문서들을 포함하는 컨테이너로, 문서 내에 또 다른 하위 컬렉션을 포함할 수도 있어 계층적 데이터 모델을 지원합니다.

Q2: 문서(Document)와 컬렉션(Collection)의 차이는 무엇인가요?
A2: 문서는 데이터의 실제 개별 레코드를 의미하며, 컬렉션은 그러한 문서들의 그룹입니다. 문서는 고정된 필드와 데이터를 저장하며, 컬렉션은 여러 문서를 모아 관리합니다. Firestore는 컬렉션과 문서로만 이루어진 계층적이며 중첩된 구조를 가집니다.

Q3: 중첩된 데이터 구조는 어떻게 표현하나요?
A3: 문서 내에 Map(객체) 타입이나 배열로 중첩 데이터를 저장할 수 있으며, 필요에 따라 문서 내에 하위 컬렉션(Subcollection)을 생성하여 더 복잡한 계층 구조를 만들 수 있습니다. 하지만 과도한 중첩은 권장되지 않으므로 데이터 접근 패턴에 따라 적절히 설계해야 합니다.

Q4: Firestore의 데이터 모델이 관계형 데이터베이스와 다른 점은 무엇인가요?
A4: Firestore는 스키마리스 NoSQL 데이터베이스입니다. 테이블, 조인, 스키마 설계가 아닌 컬렉션과 문서 단위로 데이터를 관리하며, 일반적인 SQL 데이터베이스처럼 조인을 지원하지 않아 필요하면 클라이언트나 백엔드에서 별도의 조인 로직을 구현해야 합니다.

Q5: Firestore에서 데이터 중복을 허용하나요?
A5: 네, Firestore는 중복 저장을 허용하며 성능 최적화 및 복잡성 감소를 위해 일부 데이터를 중복 저장하는 패턴이 권장됩니다. 이는 보통 읽기 성능 향상을 위해 활용됩니다.

Q6: Firestore 데이터 설계 시 고려해야 하는 중요한 점은 무엇인가요?
A6: 주요 고려사항은 다음과 같습니다. - 데이터 액세스 패턴(사용자가 어떻게 데이터에 접근하는지) 기반 설계
- 자주 변경되는 데이터와 변경이 적은 데이터를 분리
- 문서 크기는 1MB 이하로 유지 (1문서 최대 크기 제한)
- 과도한 조인이나 트랜잭션 최소화
- 하위 컬렉션 기능 활용 및 적절한 데이터 중복 허용

Q7: Firestore에서 트랜잭션이나 배치 쓰기 시 데이터 구조는 어떻게 되나요?
A7: 트랜잭션과 배치 쓰기는 여러 문서에 원자적으로 작업할 수 있으나, 여전히 문서 단위로 수행됩니다. 따라서 트랜잭션 대상이 되는 문서들을 설계 시 묶어서 관리하거나 동시성 이슈를 고려해 분산 데이터 구조를 설계하는 것이 중요합니다.

Q8: 컬렉션 이름이나 문서 ID에 제약이 있나요?
A8: 컬렉션 이름과 문서 ID는 알파벳 대소문자, 숫자, 밑줄(_) 등을 사용할 수 있고, 길이는 1~1500자입니다. 일부 특수문자는 제한되며 고유성을 보장하는 방식으로 설계해야 합니다.

Q9: Firestore에는 스키마가 존재하나요?
A9: 공식적으로 스키마가 없고 유연한 스키마리스 구조이지만, 데이터 일관성을 위해 애플리케이션 레벨에서 스키마를 관리하거나 Firestore 규칙 또는 타 시스템을 통해 스키마 검증을 병행할 수 있습니다.

Q10: 데이터 읽기 성능을 높이기 위한 데이터 구조 설계 팁은 무엇인가요?
A10: 읽기 성능 향상을 위해 자주 함께 조회되는 데이터를 한 문서에 묶어 저장하거나, 하위 컬렉션과 문서를 분리하여 필요한 데이터만 선택적으로 조회할 수 있도록 설계합니다. 또한 중복 데이터를 허용해 조인 없는 단일 조회를 유도하고 인덱스 설정을 적절히 활용합니다.

Firestore는 Google Cloud의 NoSQL 클라우드 데이터베이스로, 실시간 데이터 동기화 및 오프라인 지원 기능을 제공합니다.

Firestore의 데이터 구조와 설계 방식은 다음과 같은 주요 요소로 구성됩니다.

1. 컬렉션과 문서- 컬렉션(Collection) : Firestore는 데이터를 컬렉션이라는 단위로 그룹화합니다.

각 컬렉션은 여러 개의 문서를 포함할 수 있습니다.

예를 들어, "사용자"라는 컬렉션은 여러 사용자 문서를 포함할 수 있습니다.

- 문서(Document) : 문서는 컬렉션의 기본 단위로, JSON 형식의 데이터를 저장합니다.

각 문서는 고유한 ID를 가지며, 필드와 값의 쌍으로 구성됩니다.

예를 들어, 사용자 문서에는 이름, 이메일, 나이 등의 필드가 있을 수 있습니다.



2. 서브컬렉션문서 안에는 서브컬렉션을 포함할 수 있습니다.

서브컬렉션은 해당 문서와 관련된 추가 데이터를 구조화하는 데 유용합니다.

예를 들어, "사용자" 문서 안에 "게시물"이라는 서브컬렉션을 두어 사용자의 게시물 데이터를 저장할 수 있습니다.



3. 데이터 모델링Firestore의 데이터 모델링은 애플리케이션의 요구 사항에 따라 달라질 수 있습니다.

일반적으로 다음과 같은 원칙을 따릅니다:- 중첩 데이터 : 문서 내에 중첩된 객체를 사용하여 관련 데이터를 함께 저장할 수 있습니다.

예를 들어, 주소 정보를 사용자 문서의 필드로 포함할 수 있습니다.

- 정규화 vs 비정규화 : Firestore는 NoSQL 데이터베이스이기 때문에 데이터 중복을 허용합니다.

데이터의 정규화(중복 제거)와 비정규화(중복 허용) 사이에서 균형을 잡아야 합니다.

비정규화는 읽기 성능을 향상시킬 수 있지만, 데이터 일관성을 관리하는 데 더 많은 노력이 필요할 수 있습니다.



4. 쿼리 및 인덱스Firestore는 강력한 쿼리 기능을 제공합니다.

쿼리는 컬렉션 내의 문서를 필터링하고 정렬하는 데 사용됩니다.

Firestore는 자동으로 기본 인덱스를 생성하지만, 복잡한 쿼리를 위해서는 수동으로 복합 인덱스를 설정해야 할 수 있습니다.



5. 실시간 데이터 동기화Firestore는 실시간 데이터 동기화 기능을 제공하여 클라이언트 애플리케이션이 데이터 변경 사항을 즉시 반영할 수 있도록 합니다.

이를 통해 사용자 경험을 향상시킬 수 있습니다.



6. 보안 규칙Firestore는 데이터에 대한 접근을 제어하기 위해 보안 규칙을 설정할 수 있습니다.

이를 통해 인증된 사용자만 특정 데이터에 접근하거나 수정할 수 있도록 제한할 수 있습니다.

결론Firestore는 유연한 데이터 구조와 강력한 쿼리 기능을 제공하여 다양한 애플리케이션에 적합한 데이터베이스 솔루션입니다.

데이터 모델링 시 애플리케이션의 요구 사항을 고려하여 컬렉션과 문서 구조를 설계하는 것이 중요합니다.

Firestore의 실시간 동기화 및 보안 기능을 활용하면 더욱 효과적인 데이터 관리를 할 수 있습니다.