firebase가 왜 production으로 적합하지 않은가

왜 firebase으론 scaling이 불가능한가…

애초에 제품으로 돈을 벌고 싶다면 firebase는 사용하지 않는 것이 좋다.

 

1. 조건에 만족하는 필터링이 불가능… record가 몇 개만 더 늘어나도 제대로 찾는게 매우 힘들어짐. 시간 순 정렬도 안되고...

 

2. Tx, batch가 수행 제한 500개

 

https://firebase.google.com/docs/firestore/manage-data/transactions?hl=ko

각 트랜잭션이나 쓰기 배치에서 쓰기 작업을 수행할 수 있는 최대 문서 수는 500개입니다. 쓰기와 관련된 추가 한도는 할당량 및 한도를 참조하세요.

3. 짧은 시간 내에 document를 update 할 수 없음.

https://firebase.google.com/docs/firestore/best-practices#updates_to_a_single_document

 

You should not update a single document more than once per second. If you update a document too quickly, then your application will experience contention, including higher latency, timeouts, and other errors.

 

동일한 Firestore Document는 1초에 최대 1번만 업데이트 가능하다는 룰이 공식문서에 있네요. 이것도 예측하지 못한 문제를 야기시키는 원인중 하나일거 같아요.

 

• Note: Write rates to a single document can sometimes exceed the one per second limit so load tests might not show this problem.

 

게다가 부하 테스트를 진행해도 이 문제를 보여주지 않기도 함…

 

4. 좁은 문서 범위에 대한 높은 읽기, 쓰기, 삭제 속도

 

사전순으로 가까운 문서 또는 애플리케이션에 대한 읽기 또는 쓰기 속도가 높아지면 경합 오류가 발생합니다. 이러한 문제를 부하 집중이라고 부르며 다음 중 하나라도 해당할 경우 애플리케이션에 부하 집중이 발생할 수 있습니다.

• 매우 높은 속도로 신규 문서를 생성하면서 단조 증가하는 자체 ID를 할당하는 경우
  Cloud Firestore에서는 분산형 알고리즘을 사용해 문서 ID를 할당합니다. 자동 문서 ID를 사용하여 새 문서를 생성하면 쓰기 작업에 부하 집중이 발생하지 않습니다.
• 문서가 얼마 없는 컬렉션에서 매우 빠른 속도로 신규 문서를 생성하는 경우
• 타임스탬프와 같이 단조롭게 증가하는 필드를 사용하는 신규 문서를 매우 빠른 속도로 생성하는 경우
• 컬렉션에서 문서를 빠른 속도로 삭제하는 경우

 

5. 지연시간의 존재

 

User를 생성하였고, 성공 여부를 받았음에도 불구하고, 즉시 User를 확인하는 쿼리를 날려보면 값이 없다… 한 0.5초 후에 나타남. X를 생성하고 결과를 받았음에도 X를 확인하려고 하면 X가 존재하지 않는 경우가 너무 잦음.

 

6. firebase web hosting 접근이 안되고 대처도 느렸음… 박살!

 

구글이 관리를 잘 하고 있는지를 모르겠다.