firebase에서 DB를 구조화하기 위해서는 데이터를 손쉽게 적재하고 검색할 수 있는 방식을 설계하는 것이다.
Firebase에서의 DB
-
firebase는 NoSQL 기반
-
View에 적합하게 데이터를 구조화
-
쿼리의 수를 줄어기 위해 데이터 중복을 허용
-
데이터 변경시 데이터 일관성을 보완하기 위해 다중경로 갱신을 이용
-
firebase는 2가지의 DB를 제공한다.
- Realtime Database : 초기 firebase DB, 여러 client에서 실시간 동기화. 모바일 앱에 적합, 지연시간이 짧음.
- Colud firebase : 최신 DB, 모바일 앱 개발 목적, realtime DBㅇ보다 빠른 쿼리, 원활한 확장성.
- 하나의 프로젝트에서 두 종류의 DB를 모두 사용할 수도 하나만 사용할 수도 있음.
- 자세한 차이는 공식사이트 참고
Firebase에서의 데이터 구조, JSON Tree!
- firebase에서 실시간 데이터베이스 (real- time DB)는 JSON 객체로 이루어져 있다.
- JSON Tree에 데이터가 추가될 경우, 기존의 JSON Tree와 연결된 키(key)를 갖는 Node가 된다.
- SQL DB와 다르게 테이블(table), 레코드(record)이 없다.
- 데이터 값을 키로 직접지정하거나 push()를 통해 자동으로 지정할 수 있음.
키 직접생성시 주의사항
- 키를 직접 생성하는 경우, UTF-8 encoding이 되어야 함.
- ., $, #, [, ], /, ASCII 제어문자 0~31, 127 포함불가
- 값에 ASCII 제어문자 사용불가
- DB에 저장되는 데이터는 JSON유형에 맞는 유형으로 표현하여 코드 관리를 용이하게 해줌.
{
"users": {
"James": {
"name": "Peter James",
"contacts": { "ghopper": true },
},
"ghopper": { ... },
"eclarke": { ... }
}
}데이터 구조 설계시 권장사항
데이터 중첩 최소화
- firebase는 최대 32단계 데이터 중첩허용
- 그러나, DB 특정 위치의 데이터를 불러오면 하위 노드의 데이터까지 함께 검색, 읽기, 쓰기 권한이 부여됨
- children node까지 불러오게 됨으로써 많은 byte 차지하게 됨.
- 따라서, 데이터 구조를 최대한 평면화하는 것을 추천
- 하단: 공식문서 코드
{
// This is a poorly nested data architecture, because iterating the children
// of the "chats" node to get a list of conversation titles requires
// potentially downloading hundreds of megabytes of messages
"chats": {
"one": {
"title": "Historical Tech Pioneers",
"messages": {
"m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." },
"m2": { ... },
// a very long list of messages
}
},
"two": { ... }
}
}데이터 구조 평면화
- 비정규화를 통해 서로 다른 경로로 분할
- 필요에 따라 별도의 호출로 효율적 다운로드 가능
- 공식문서의 코드
{
// Chats contains only meta info about each conversation
// stored under the chats's unique ID
"chats": {
"one": {
"title": "Historical Tech Pioneers",
"lastMessage": "ghopper: Relay malfunction found. Cause: moth.",
"timestamp": 1459361875666
},
"two": { ... },
"three": { ... }
},
// Conversation members are easily accessible
// and stored by chat conversation ID
"members": {
// we'll talk about indices like this below
"one": {
"ghopper": true,
"alovelace": true,
"eclarke": true
},
"two": { ... },
"three": { ... }
},
// Messages are separate from data we may want to iterate quickly
// but still easily paginated and queried, and organized by chat
// conversation ID
"messages": {
"one": {
"m1": {
"name": "eclarke",
"message": "The relay seems to be malfunctioning.",
"timestamp": 1459361875337
},
"m2": { ... },
"m3": { ... }
},
"two": { ... },
"three": { ... }
}
}참고
공부에는 끝이 없다