본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

한도 (Limits)

원문 보기 위키 갱신

| 기능 | 한도 | | 계정당 데이터베이스 수 | 50,000 (Workers Paid) 1 / 10 (Free) | | 최대 데이터베이스 크기 | 10 GB (Workers Paid) / 500 MB (Free) | | 계정당 최대 저장 용량 | 1 TB (Workers Paid) 2 / 5 GB (Free) | | Time Travel 기간 (시점 복구, point-in-time recovery) | 30일 (Workers Paid) / 7일 (Free) | | 최대 Time Travel 복원 작업 수 | 10분당 10회 (데이터베이스당) | | Worker 호출당 쿼리 수 (읽기 하위 요청 한도) | 1000 (Workers Paid) / 50 (Free) | | 테이블당 최대 열 수 | 100 | | 테이블당 최대 행 수 | 무제한 (데이터베이스별 저장 한도 제외) | | 최대 문자열, BLOB 또는 테이블 행 크기 | 2,000,000 바이트 (2 MB) | | 최대 SQL 문 길이 | 100,000 바이트 (100 KB) | | 쿼리당 최대 바인딩 파라미터 수 | 100 | | SQL 함수당 최대 인자 수 | 32 | | LIKE 또는 GLOB 패턴의 최대 문자(바이트) 수 | 50 바이트 | | Workers 스크립트당 최대 바인딩 수 | 약 5,000 3 | | 최대 SQL 쿼리 지속 시간 | 30초 4 | | 최대 파일 가져오기(d1 execute) 크기 | 5 GB 5 |

출처: 문서

본문

Cloudflare는 Workers KV, Durable Objects, R2와 같은 다른 스토리지 솔루션도 제공해요. 각 제품은 서로 다른 장점과 한계가 있어요. 어느 스토리지 옵션이 여러분의 사용 사례에 맞는지 검토하려면 스토리지 제품 선택 문서를 참고하세요.

자주 묻는 질문 (Frequently Asked Questions)

D1 한도와 관련된 자주 묻는 질문이에요:

D1 데이터베이스는 얼마나 많은 작업을 처리할 수 있나요?

D1은 여러 개의 더 작은(10 GB) 데이터베이스로 가로로 확장(horizontal scale out)하도록 설계됐어요. 예를 들어 사용자별, 테넌트별, 또는 엔티티별 데이터베이스 같은 형태죠. D1은 가격이 쿼리와 저장 비용에만 기반하기 때문에, 수천 개의 데이터베이스를 추가 비용 없이 사용해 애플리케이션을 만들 수 있게 해 줘요.

저장 용량 (Storage)

각 D1 데이터베이스는 최대 10 GB의 데이터를 저장할 수 있어요.

동시성과 처리량 (Concurrency and throughput)

개별 D1 데이터베이스는 본질적으로 단일 스레드로, 쿼리를 한 번에 하나씩 처리해요.

최대 처리량은 쿼리의 지속 시간과 직접적인 관련이 있어요.

  • 평균 쿼리가 1ms 걸린다면, 초당 약 1,000개의 쿼리를 실행할 수 있어요.

  • 평균 쿼리가 100ms 걸린다면, 초당 10개의 쿼리를 실행할 수 있어요.

너무 많은 동시 요청을 받는 데이터베이스는 먼저 요청을 대기열에 넣으려고 해요. 대기열이 가득 차면 데이터베이스는 "overloaded" 오류를 반환해요.

각 개별 D1 데이터베이스는 단일 Durable Object에 의해 뒷받침돼요. D1 읽기 복제를 사용할 때 각 복제본 인스턴스는 서로 다른 Durable Object이며, 가이드라인은 각 복제본 인스턴스에 독립적으로 적용돼요.

쿼리 성능 (Query performance)

쿼리 성능은 처리량에 가장 중요한 요소예요. 대략적인 기준은 다음과 같아요:

  • id에 적절한 인덱스가 있는 SELECT name FROM users WHERE id = ? 같은 읽기 쿼리는 SQL 지속 시간이 1밀리초 미만이에요.

  • INSERT나 UPDATE 같은 쓰기 쿼리는 SQL 지속 시간이 수 밀리초가 걸릴 수 있고, 쓴 행 수에 따라 달라져요. 쓰기는 여러 위치에 내구성 있게(durably) 영속되어야 해요. D1이 내부적으로 데이터를 어떻게 영속하는지 자세히 알아보세요.

  • 수백만 행에 영향을 주는 대규모 UPDATE나 DELETE 같은 데이터 마이그레이션은 반드시 배치로 실행해야 해요. 수십만 행이나 수백 MB의 데이터를 한 번에 수정하려는 단일 쿼리는 실행 한도를 초과해요. 작업을 더 작은 덩어리로 나눠서(예: 한 번에 1,000행씩 처리) 플랫폼 한도 안에 머무르세요.

쿼리가 빠르고 효율적이도록 SQL 스키마에 적절한 인덱스를 사용하세요.

CPU와 메모리

D1 데이터베이스에 대한 작업(쿼리 실행과 결과 직렬화 포함)은 Workers 플랫폼 CPU 및 메모리 한도 안에서 실행돼요.

이러한 한도를 초과하거나 다른 플랫폼 한도에 부딪히면 오류가 발생해요. 자세한 내용은 D1 오류 목록을 참고하세요.

Worker가 D1에 동시에 열 수 있는 연결은 몇 개인가요?

Worker 호출(invocation)마다 D1에 동시에 최대 여섯 개의 연결을 열 수 있어요.

Worker의 동시 연결에 대한 자세한 내용은 동시 열린 연결 문서를 참고하세요.

각주 (Footnotes)

  • 계정당 최대 데이터베이스 수는 Workers Paid 및 Enterprise 플랜에서 요청 시 늘릴 수 있어요. 계정당 수백만에서 수천만 개(또는 그 이상)의 데이터베이스를 지원할 수 있어요. 증가를 요청하려면 이 페이지의 한도 증가 안내를 참고하세요. [↩]

  • 계정당 최대 저장 용량은 Workers Paid 및 Enterprise 플랜에서 요청 시 늘릴 수 있어요. 증가를 요청하려면 이 페이지의 한도 증가 안내를 참고하세요. [↩]

  • 단일 Worker 스크립트는 최대 1 MB의 스크립트 메타데이터를 가질 수 있어요. 바인딩(binding)은 D1 데이터베이스, KV 네임스페이스, 환경 변수, 또는 secret 같은 리소스에 대한 바인딩으로 정의돼요. 각 리소스 바인딩은 약 150 바이트지만, 환경 변수와 secret은 제공하는 값의 크기에 의해 통제돼요. 환경 변수를 제외하면 단일 Worker 스크립트에 최대 약 5,000개의 D1 데이터베이스를 바인딩할 수 있어요. [↩]

  • Cloudflare API에 대한 요청은 30초 안에 해결되어야 해요. 따라서 이 지속 시간 한도는 전체 배치 호출에도 적용돼요. [↩]

  • 가져온 파일은 R2에 업로드돼요. R2 업로드 한도를 참고하세요. [↩]

더 알아보기 (Learn more)