이 페이지에서는 mongoimport와 같은 도구를 사용하여 MongoDB 호환성을 갖춘 Cloud Firestore에 데이터를 일괄 로드할 때의 권장사항을 설명합니다.
Cloud Firestore는 비즈니스 요구사항을 충족하기 위해 자동 확장을 제공하는 고도로 분산된 시스템입니다. Cloud Firestore는 시스템에서 수신한 부하에 따라 데이터를 동적으로 분할하고 결합합니다.
부하 기반 분할은 사전 구성 없이 자동으로 이루어집니다. Cloud Firestore 부하 기반 분할 시스템에는 데이터를 모델링할 때 유의해야 하는 다른 문서 데이터베이스와 비교되는 중요한 고유한 특징이 있습니다.
Cloud Firestore의 분산된 특성으로 인해 일부 설계 옵션을 변경해야 할 수 있습니다. 특히 기본 복제본이 쓰기 처리량의 병목 현상인 데이터베이스에 최적화된 워크로드의 경우 더욱 그렇습니다.
권장사항
단일 스레드 클라이언트에서 대량의 데이터를 처리하는 워크로드는 병목 현상을 일으킬 수 있습니다. 클라이언트와 서버의 처리량이 유사하게 일치하므로 클라이언트가 단일 스레딩을 사용하여 데이터를 일괄 로드할 수 있습니다.
Cloud Firestore 데이터베이스는 훨씬 더 많은 동시 로드를 처리할 수 있지만 클라이언트가 요청을 동시에 전송하도록 구성해야 합니다.
mongoimport
mongoimport 도구를 사용하면 기본적으로 요청이 순차적으로 이루어집니다.
Cloud Firestore로의 로드 시간을 개선하려면 --numInsertionWorkers 플래그를 사용하여 작업자 수를 설정하세요.
올바른 설정은 클라이언트 크기에 따라 조정해야 할 수 있지만 일반적으로 최소 32로 시작하는 것이 좋습니다.
비동기 프로그래밍
MongoDB 호환 API를 사용하여 자체 소프트웨어를 개발할 때 다음과 같은 방법으로 동시 로드를 개선할 수 있습니다.
비동기 프레임워크: 비동기 프레임워크를 사용하면 요청을 동시에 처리하고 응답할 수 있습니다. 데이터베이스를 호출할 때 복잡한 풀링이나 큐를 개발할 필요가 없습니다.
각 요청 흐름은 독립적인 연결을 사용하고 데이터베이스 동시에 호출할 수 있습니다.
병렬 컴퓨팅 제품 사용: Cloud Run과 같은 서비스를 사용하면 시스템에서 데이터를 처리하는 데 필요한 컴퓨팅 작업자 수를 확장할 수 있습니다.
일시적인 실패
Cloud Firestore와 같은 대규모 분산 시스템으로 작업할 때는 네트워크 일시적 오류나 문서의 경합과 같은 일시적인 오류가 발생할 수 있습니다.
대량의 정보를 일괄 로드할 때는 더 큰 일괄 로드 작업이 실패하지 않도록 실패한 쓰기에 대한 재시도 전략을 유지하는 것이 중요합니다.
[null,null,["최종 업데이트: 2025-08-29(UTC)"],[],[],null,["\u003cbr /\u003e\n\n\n|--------------------------------------------------------|\n| *Relevant to Cloud Firestore Enterprise edition only.* |\n\n\u003cbr /\u003e\n\nThis page describes the best practices when bulk loading data to Cloud Firestore with MongoDB compatibility\nwith tools like `mongoimport`.\n\nCloud Firestore is a highly distributed system offering automatic\nscaling to meet the needs of your business. Cloud Firestore dynamically\nsplits and combines your data based on the load received by the system.\n\nLoad-based splitting happens automatically without any required\npre-configuration. The Cloud Firestore load-based splitting system has some\nimportant, unique characteristics compared to other document databases that\nare important to keep in mind as you model your data.\n\nCloud Firestore's distributed nature can require changing some design choices\nto change, particularly for workloads that were optimized for\ndatabases where the primary replica is the bottleneck for write throughput.\n\nBest Practices\n\nWorkloads that process large amounts of data in a single threaded client can\ncreate a bottleneck. Clients might be able to use single threading to bulk load\ndata, as the throughput of the client and server are similarly matched.\nA Cloud Firestore database can handle significantly more parallelism, but\nthis requires that you configure clients to send requests in parallel.\n\n`mongoimport`\n\nWhen using the `mongoimport` tool, requests are made sequentially by default.\nTo improve the load time into Cloud Firestore,\nset the number of workers with the `--numInsertionWorkers` flag.\nThe correct setting might require tuning based on\nthe size of your client, but we generally recommend starting with at least `32`.\n\nasync programming\n\nWhen developing your own software using MongoDB compatible APIs, you can improve\nparallelism in the following ways:\n\n- *Async frameworks*: using async frameworks let you process and respond to requests in parallel. It is not necessary to develop any complex pooling or queuing when making calls to your database. Each request flow can use independent connections and make their database calls in parallel.\n- *Use parallelized compute offerings* : using services like Cloud Run, your system can scale the number of computation workers required to process data.\n\nTransient Failures\n\nWhen working with a large distributed system like Cloud Firestore, you might encounter\ntransient failures such as network blips or contention on a\ndocument.\n\nWhen bulk loading large amounts of information, it's important to\nmaintain a retry strategy for failed writes without failing the larger bulk load\noperation.\n| **Note:** Cloud Firestore with MongoDB compatibility does not support `retryWrites`. We recommend using transactions to ensure your application guarantees idempotency."]]
