Google Firestore는 Google의 고유 한 NoSQL 문서 기반 데이터베이스입니다.
Cloud Functions, Firebase Auth 및 Firebase Storage와 같은 나머지 Firebase 제품군과 함께 사용하면 앱을 빠르게 시작하고 실행하려는 신생 기업 또는 단독 개발자에게 매우 매력적인 기술 스택처럼 보일 수 있습니다.
이것이 바로 9 개월 전에 모바일 앱용 기술 스택을 선택할 때 생각했던 것입니다. Firestore에는 제가 끌리는 몇 가지 장점이 있었습니다.
넉넉한 프리 티어, 자동 확장 NoSQL 데이터 모델, 다른 Firebase 서비스와의 일부 통합이 있었습니다. 지금이 기술로 이 행복한 거품 속에 있는 것처럼 느껴진다면, 여기에 조언 한 마디가 있습니다. Firestore의 단점을 알고 있는지 확인하세요.
https://dev.to/spencerpauly/why-i-switched-away-from-google-firestore-3pn
Firestore를 다시 사용하지 않는 세 가지 큰 이유
1. 독점 데이터베이스
우리는 모두 "공급 업체 종속"이라는 용어를 들어 보았습니다. 음, Firestore는 이 아이디어의 전형입니다. 제품이 단순하거나 작기 때문에 이것이 문제가 되지 않는다고 생각한다면, 가장 간단한 앱을 사용해도 Firestore의 공급 업체 종속이 급증한다고 지금 바로 말씀 드리겠습니다.
DEV 및 PROD 버전의 데이터베이스를 배포하는 간단한 작업을 수행하려고 할 때 이것을 경험했습니다. 이것은 Firestore의 큰 도전입니다.
첫 번째 장애물은 프로젝트와 관련된 여러 Firestore 데이터베이스를 가질 수 없다는 사실입니다. 따라서 별도의 project-dev 및 project-prod 프로젝트를 만들어야 합니다. 이것은 처음에는 너무 어렵지 않으며 일반적으로 좋은 디자인 패턴 일 수 있지만 이제 개발 경험이 2 배 더 복잡해집니다. 이제 각 프로젝트가 별도의 Firebase 인증을 갖도록 할 것인지 결정해야 하며 클라우드 기능이나 저장소 버킷 등은 어떻습니까?
그리고 이 배포를 자동화하는 도구가 없기 때문에 데이터베이스 데이터와 기능을 "복사"하고 사용자를 프로덕션으로 인증하려면 수동으로 수행해야 합니다. 그런 다음에도 이러한 작업 중 일부는 firebase CLI를 통해 수행 할 수 있지만 데이터 마이그레이션과 같은 더 중요한 작업은 수행 할 수 없습니다.
프로덕션 및 개발 환경을 설정했다고 가정하면 이제 20 개의 다른 문제가 발생합니다. 자동 백업은 어떻게 수행합니까? 스테이징 서버를 새로 고치기 위해 자동화 된 방법으로 한 데이터베이스에서 다른 데이터베이스로 데이터를 내보내는 방법은 무엇입니까? 테스트를 위해이 데이터베이스의 로컬 버전을 실행하려면 어떻게 해야 합니까? 이 모든 질문에 대한 답은 ... 복잡합니다.
이보다 복잡한 사용 사례는 이 데이터베이스가 오픈 소스가 아니기 때문에 수행하기 어렵기 때문에 이러한 작업을 위한 도구를 만드는 주변 커뮤니티가 없습니다.
이러한 문제 중 일부는 Firestore에 고유 한 것이 아니라 독점 데이터베이스 공급 업체에만 해당됩니다.
이것이 제가 다시는 독점 데이터베이스를 선택하지 않는 이유입니다. 최신의 가장 훌륭한 것을 시도해 볼 때가 있지만 회사의 가장 중요한 자산 (귀하의 데이터)의 무결성, 보안 및 접근성과 관련하여 10 점 만점에 10 번을 사용하는 것이 더 나은 선택이라고 말하고 싶습니다.
오픈 소스에서 검증 된 솔루션입니다.
2. Firestore는 스스로 최적화 합니다. 너 말고.
이 부분은 Firestore를 사용하는 동안 정말 짜증났습니다. Firestore에는 일관되게 서로 끝에 있는 두 가지 기능이 있습니다.
이 치명적인 조합은 더 복잡한 쿼리 (거의 피할 수 없음)를 수행해야 하는 경우 데이터를 오버 페치 한 다음 사용하기 전에 Cloud 함수 또는 클라이언트 측에서 필터링 해야 함을 의미합니다. 이것은 네트워킹 대역폭과 클라이언트 측 처리 시간에만 낭비되는 것이 아니라 Firestore의 지불 전략으로 인해 결국 더 많은 비용을 지출하게 됩니다. 제가 본 가장 큰 결과는
그 결과 데이터베이스 컬렉션과 사용 가능한 쿼리 작업이 내 고객이 결정하는 대신 내 제품에 구현하는 기능을 정의합니다.
이제 Firestore가 이런 방식으로 설정되는 이유를 이해하기 때문에 잠시 악마의 대변인 역할을 할 것입니다. Firestore는 하나의 목적으로 구축 되었기 때문입니다. 잘못된 쿼리를 작성하기가 매우 어렵게 만들었습니다. Firestore에 대해 수행 할 수 있는 거의 모든 쿼리는 O (1) 복잡성입니다. 이는 데이터베이스 처리 시간이 짧고 클라이언트가 매우 빠르게 결과를 얻고 있음을 의미하기 때문에 훌륭합니다. 그러나…
Firestore는 서버 측에서의 처리 비용을 낮추기 위해 구축되었습니다. 하지만 그거 알아? 문서 당 비용을 지불하므로 쿼리에 1ms 또는 100ms가 걸리는지 여부는 지갑에 문제가 되지 않습니다. 이는 Firestore가 비용을 절감하기 위해 최적화하고 있음을 의미합니다. 당신 것이 아닙니다. 그리고 데이터를 오버 페치하고 클라이언트 측에서 수동으로 필터링 해야 하므로 실제로 전체적으로 더 비싸고 느린 쿼리가 발생합니다.
이것이 내가 Firestore를 떠나는 이유입니다. 이것이 그들의 비즈니스 모델이라는 것을 확인한 후,이 제품으로 확장 할 방법이 없다는 것을 알게 되었습니다.
3. NoSQL 데이터베이스는 귀하에게 적합하지 않을 수 있습니다
처음에 Firestore에 매료 된 한 가지는 NoSQL 데이터 모델이었습니다. MongoDB 또는 AWS DynamoDB와 같은 NoSQL에 대한 다른 옵션이 있지만 Firestore는 제가 바로 좋아하는 정말 멋진 자동 확장 기본 솔루션을 제공했습니다. 더 이상 마음에 들지 않을 때까지.
일반적인 웹 또는 모바일 애플리케이션에 대한 대부분의 데이터는 매우 관계가 있습니다. 일반적인 응용 프로그램에는 어떤 방식으로든 사용자와 관련된 것 뿐만 아니라 사용자도 있을 것입니다. 그리고 이러한 것들은 다른 것들과도 관련이 있을 것입니다. 기타 등등. 그리고 그들은 목록에서 보거나, 색인화 되거나, 사용자가 만든 모든 것을 보기 위해 쿼리 될 수 있습니다. 이러한 기본 사용 사례를 관리하는 경우 Firestore는 괜찮지 만 일단 더 복잡해지면 Firestore가 고장 납니다.
이러한 문제에 대한 NoSQL 솔루션에는 데이터 복제, 팬 아웃 쓰기 등이 포함됩니다. 이러한 원칙은 처음부터 SQL 데이터베이스를 사용하는 것보다 구현하는 데 더 많은 개발 시간이 걸립니다. 솔루션으로 Firestore를 찾고 있다면 Firebase의 판매 포인트이기 때문에 개발 시간을 절약 할 수 있는 무언가를 찾고 있을 것입니다.하지만 Firestore는 나중에 갚아야 하는 시간 부채를 받는 것과 비슷합니다. 제가 개발해야 하는 정말 고통스러운 장애물을 설명하기 위해 프로젝트에서 몇 가지 간단한 예를 들어 보겠습니다.
보시다시피, NoSQL 데이터베이스가 당신을 망치고 많은 개발 시간을 낭비하는 상황이 너무 많습니다. SQL 데이터베이스는 사용자의 요구를 훨씬 더 잘 충족 할 수 있도록 확장 성이 뛰어나고 강력합니다. 그리고 그거 알아? 두 세계의 장점을 모두 원한다면 둘 다 사용할 수 있습니다. 관계형 데이터베이스를 SQL 데이터베이스에 넣고 비 관계형 데이터 (예 : 수백만 개의 실시간 채팅 메시지 등)를 NoSQL 데이터베이스에 저장하면 둘 다의 장단점으로 두 가지 이점을 모두 얻을 수 있습니다.
Firestore가 나에게 적합합니까?
여전히 Firestore에 대한 몇 가지 사항이 마음에 듭니다. 클라이언트 측 오프라인 지원을 관리하는 클라이언트 SDK는 편리했으며 본질적으로 관계가 없는 간단한 데이터를 쿼리 하는 경우에도 여전히 고려할 것입니다. 하지만 내 프로젝트에 완료 날짜가 고정되어 있고 위에서 언급 한 제한 사항에 해당하지 않는다는 것을 알지 못하면 권장 할 수 없습니다.
그렇다면 Firestore의 대안은 무엇입니까?
저와 같고 데이터베이스에서 중첩 된 JSON 응답을 받는 것을 좋아한다면 GraphQL 사용을 고려해야 합니다. 저는 SQL Database와 짝을 이루는 GraphQL로 전환했고, 쉬운 쿼리 측면에서 이전에 좋아했던 모든 것을 얻을 수 있는 완벽한 균형을 찾았지만, 더 많은 작업을 수행하고 싶다면 데이터베이스를 직접 쿼리 할 수 있습니다. 또한 속도가 여전히 비슷하다는 사실을 발견했으며 데이터베이스가 확장됨에 따라 속도가 느려지기 시작하면 읽기 복제본을 추가 할 수 있습니다.
다른 사용 사례에 대한 권장 사항은 다음과 같습니다.
데이터를 쉽게 넣을 수 있는 버킷을 원한다면 Contentful과 같은 것을 확인하십시오 : https://www.contentful.com/
오픈 소스 Postgres 데이터베이스 위에 CRUD API를 만들기 위해 사용하기 쉬운 오픈 소스 UI를 제공하는 것을 원한다면 Hasura + Postgres를 사용한 GraphQL을 고려하십시오 : https://hasura.io/
데이터 중복을 처리 할 필요는 없지만 GraphQL을 사용하거나 데이터베이스 확장을 관리하고 싶지 않은 SQL 데이터베이스를 원할 경우 AWS Aurora를 고려하십시오. https://aws.amazon.com/rds/aurora/
등록된 댓글이 없습니다.
