Cloud Firestore: 두 판 사이의 차이
편집 요약 없음 |
편집 요약 없음 |
||
3번째 줄: | 3번째 줄: | ||
[[구글]]에서 [[클라우드]] [[Firebase]] 서비스의 일부로 제공하는 [[NoSQL]] 기반 [[데이터베이스]]. 원래 제공하던 Realtime [[데이터베이스]]와 병행 제공하고 있으나, [[구글]]은 웬만하면 Firestore를 쓰라고 권하고 있다. Realtime 쪽은 앞으로 기능을 개선시킬 계획이 없는 반면, Firestore 쪽은 앞으로 계속 발전시킬 것이라고 <del>일단 장담은</del> 하고 있다. | [[구글]]에서 [[클라우드]] [[Firebase]] 서비스의 일부로 제공하는 [[NoSQL]] 기반 [[데이터베이스]]. 원래 제공하던 Realtime [[데이터베이스]]와 병행 제공하고 있으나, [[구글]]은 웬만하면 Firestore를 쓰라고 권하고 있다. Realtime 쪽은 앞으로 기능을 개선시킬 계획이 없는 반면, Firestore 쪽은 앞으로 계속 발전시킬 것이라고 <del>일단 장담은</del> 하고 있다. | ||
문서(document) 기반으로 [[NoSQL]]이므로 [[관계형 데이터베이스]]와 같은 엄격한 스키마를 필요로 하지 않는다. 최대 장점이라면 서버와 클라이언트 사이의 실시간 동기화로, [[구글]]의 가이드라인 대로 라이브러리를 가져와서 코딩하면 별다른 걸 안 해도 서버의 변경 내용이 실시간으로 클라이언트에도 반영된다. 인터넷 연결이 끊어졌을 때에는 자동으로 로컬 캐시에 있는 내용을 사용하므로 초기에 서버에서 아무 데이터도 받지 못했을 때를 제외한다면 어쨌든 돌아는 간다. 처음에 [[데이터베이스]]를 설정할 때 메인 서버가 있는 지역을 선택하도록 하지만 [[NoSQL]]답게 분산 처리가 뛰어나므로 글로벌 서비스에도 문제가 없다. | 문서(document) 기반으로 [[NoSQL]]이므로 [[관계형 데이터베이스]]와 같은 엄격한 스키마를 필요로 하지 않는다. 각각의 문서는 JSON 형식으로 표현할 수 있으며, 이러한 문서를 묶은 것이 컬렉션이다. 굳이 [[관계형 데이터베이스]]와 엮어 보자면 컬렉션은 테이블, 각각의 문서는 레코드로 볼 수 있지만 엄격한 스키마를 요구하지 않으며, 문서가 컬렉션을 가질 수 있다는 점에서 [[관계형 데이터베이스]]와는 큰 차이를 보인다. 이전 리얼타임 데이터베이스도 JSON 형식으로 표현할 수 있는 문서지만 리얼타임 데이터베이스는 전체를 하나의 큰 JSON 문서 트리로 표현하는 구조라면 Firestore는 컬렉션 → 문서 → 컬렉션 → 문서와 같은 구조를 계속해서 이어나갈 수도 있다. | ||
최대 장점이라면 서버와 클라이언트 사이의 실시간 동기화로, [[구글]]의 가이드라인 대로 라이브러리를 가져와서 코딩하면 별다른 걸 안 해도 서버의 변경 내용이 실시간으로 클라이언트에도 반영된다. 인터넷 연결이 끊어졌을 때에는 자동으로 로컬 캐시에 있는 내용을 사용하므로 초기에 서버에서 아무 데이터도 받지 못했을 때를 제외한다면 어쨌든 돌아는 간다. 처음에 [[데이터베이스]]를 설정할 때 메인 서버가 있는 지역을 선택하도록 하지만 [[NoSQL]]답게 분산 처리가 뛰어나므로 글로벌 서비스에도 문제가 없다. | |||
이러한 편리한 기능에도 불구하고 거지 같은 질의 기능으로 뒷목잡게 만든다. 원래 [[NoSQL]]이 [[SQL]]은 아주 쉽게 되는 갖가지 조인 연산이 안 되고 해서 [[관계형 데이터베이스]]에 익숙한 사람들에는 머리에 쥐나게 만들지만 Firestore는 [[몽고DB]]와 같은 [[NoSQL]]과 비교해도 더 짜증나는 부분이 많다. | 이러한 편리한 기능에도 불구하고 거지 같은 질의 기능으로 뒷목잡게 만든다. 원래 [[NoSQL]]이 [[SQL]]은 아주 쉽게 되는 갖가지 조인 연산이 안 되고 해서 [[관계형 데이터베이스]]에 익숙한 사람들에는 머리에 쥐나게 만들지만 Firestore는 [[몽고DB]]와 같은 [[NoSQL]]과 비교해도 더 짜증나는 부분이 많다. |
2021년 4월 12일 (월) 21:28 판
정확히는 Cloud Firestore.
구글에서 클라우드 Firebase 서비스의 일부로 제공하는 NoSQL 기반 데이터베이스. 원래 제공하던 Realtime 데이터베이스와 병행 제공하고 있으나, 구글은 웬만하면 Firestore를 쓰라고 권하고 있다. Realtime 쪽은 앞으로 기능을 개선시킬 계획이 없는 반면, Firestore 쪽은 앞으로 계속 발전시킬 것이라고 일단 장담은 하고 있다.
문서(document) 기반으로 NoSQL이므로 관계형 데이터베이스와 같은 엄격한 스키마를 필요로 하지 않는다. 각각의 문서는 JSON 형식으로 표현할 수 있으며, 이러한 문서를 묶은 것이 컬렉션이다. 굳이 관계형 데이터베이스와 엮어 보자면 컬렉션은 테이블, 각각의 문서는 레코드로 볼 수 있지만 엄격한 스키마를 요구하지 않으며, 문서가 컬렉션을 가질 수 있다는 점에서 관계형 데이터베이스와는 큰 차이를 보인다. 이전 리얼타임 데이터베이스도 JSON 형식으로 표현할 수 있는 문서지만 리얼타임 데이터베이스는 전체를 하나의 큰 JSON 문서 트리로 표현하는 구조라면 Firestore는 컬렉션 → 문서 → 컬렉션 → 문서와 같은 구조를 계속해서 이어나갈 수도 있다.
최대 장점이라면 서버와 클라이언트 사이의 실시간 동기화로, 구글의 가이드라인 대로 라이브러리를 가져와서 코딩하면 별다른 걸 안 해도 서버의 변경 내용이 실시간으로 클라이언트에도 반영된다. 인터넷 연결이 끊어졌을 때에는 자동으로 로컬 캐시에 있는 내용을 사용하므로 초기에 서버에서 아무 데이터도 받지 못했을 때를 제외한다면 어쨌든 돌아는 간다. 처음에 데이터베이스를 설정할 때 메인 서버가 있는 지역을 선택하도록 하지만 NoSQL답게 분산 처리가 뛰어나므로 글로벌 서비스에도 문제가 없다.
이러한 편리한 기능에도 불구하고 거지 같은 질의 기능으로 뒷목잡게 만든다. 원래 NoSQL이 SQL은 아주 쉽게 되는 갖가지 조인 연산이 안 되고 해서 관계형 데이터베이스에 익숙한 사람들에는 머리에 쥐나게 만들지만 Firestore는 몽고DB와 같은 NoSQL과 비교해도 더 짜증나는 부분이 많다.
일단 텍스트 검색은 거의 불가능에 가깝다. 사실상 필드 값 전체에 걸쳐서 정확히 같은 문자열인가만 비교할 수 있다. '큰지', '작은지' 비교하는 연산자도 사용할 수 있으나 효용성이 정말 많이 떨어진다. 구글은 Algolia와 같은 텍스트 검색 엔진을 붙여서 쓰라고 하는데 이건 또 별도로 유료라서 이중으로 돈이 나간다. 따라서 검색 기능이 필요한 앱을 만들 때에는 정말로 뒷목 잡게 만드는 원흉이다. NoSQL이 텍스트 검색 부분은 인덱스 문제로 관계형 데이터베이스에 비해서 약하지만 Firestore는 그 중에서도 심한 편에 속한다.
유료다. 기본 무료 사용량을 제공하므로 개발 단계, 혹은 소규모 서비스는 무료에 가깝게 사용할 수 있으나, 사용량에 따라 돈이 나간다는 점에 유의하자.
- 데이터 용량 : 1 기가바이트까지는 무료. 이후 매달 기가바이트 당 0.18 달러.
- 네트워크 방출량 : 월 10 기가바이트까지는 무료. 이후에는 구글 클라우드 요금제에 준한다.
- 읽기 : 하루 5만 문서까지는 무료. 이후 10만 문서 당 0.06 달러.
- 쓰기/지우기 : 각각 하루 2만 문서까지는 무료. 이후 각각 10만 문서 당 0.18 달러.
요금제는 Firebase 전체에 적용하는 Spark와 Blaze가 마찬가지로 적용되며, Spark는 위의 무료 사용량까지만 서비스를 제공한다. Blaze는 Spark와 같은 무료 사용량을 제공하고, 이를 넘어가는 부분은 과금한다.