94. Hard Limit (중급) : 버블의 성능 제한, 최대 텍스트 길이, 파일 크기, 최대 이벤트 액션 수, 최대 api 크기

이 섹션에서는 Bubble의 엄격한 제한에 중점을 두고 설명합니다.

• Hard(엄격)한 제한은 워크플로가 종료되기 전에 완료를 시도하는 것과 같이 초과할 수 없는 고정 경계입니다. 더 높은 요금제로 업그레이드하면 일부 엄격한 한도를 늘릴 수 있습니다.

 

소프트 제한(초과할 수 있지만 성능이나 안정성에 영향을 미칠 수 있는 유연한 경계)에 대해서는 성능 및 확장에 대한 일반 문서를 확인하세요

93. 성능(중급) : Performance, 성능 최적화, 빠른 로딩 팁, 페이지 로딩 순서

• 모든 개발 프레임워크 및 서버 시스템과 마찬가지로 Bubble에는 고유한 기능 및 제한 사항이 있습니다.

 

(1) 시스템 제한 이해

• 앱이 엄격한 한계에 도달하는 경우는 매우 드물지만, 개발자로서 이러한 문제가 발생할 경우를 대비하여 이를 인식하고 디버깅할 수 있도록 알아두면 유용할 수 있습니다.
• 이는 앱의 계획 및 개발에 도움이 될 수 있지만, 앱에 얼마나 더 복잡한 영향을 미칠 수 있는지 이해하고 예측하는 것은 이해할 가치가 별로 없습니다. 제한은 시스템의 절대적 상황의 제한에 대한 통찰력을 제공하고 단편적 사례에는 유효할 수 있지만, 다양한 조건과 작업 환경에서 앱 성능을 예측하는 데는 정확도가 떨어집니다.
• 예를 들어, 검색 시 최대 시간제한(Timeout)이 10초일 경우에 완료하는 데 3초가 걸리는 검색이 모든 상황에서 항상 안전하다는 의미는 아닙니다. 예를 들어, 백만 명의 사용자가 동시에 3초 동안의 검색을 실시하면 여전히 전체적으로 앱에 큰 부담이 됩니다. 이러한 대규모 사용자 환경에서는 더 빠르게 검색이 수행되도록 재설계하는 것이 좋습니다. 드물게 “엄격한 제한”이 적용되는 경우도 있지만 앱에서 수행할 모든 작업의 조합을 염두에 두는 것도 중요합니다.
• 엄격한 제한은 시간 제한에 도달하여 프로세스가 중지된 이유를 명확히 하고 리소스 집약적인 프로세스가 결국 제한에 도달할 것임을 상기시키는 역할을 합니다. 앱의 활동이 앱을 안전하게 확장할 수 있는 지속 가능한 수준으로 유지되도록 하려면 이 정보를 중요한 전략에 통합해야 합니다.

 

(2) 데이터베이스 제한

1. 텍스트 필드

• 데이터베이스에 저장되는 단일 텍스트 필드에는 1,000만 자라는 엄격한 제한이 있습니다.
• 여기에는 공백 및 BBCode/HTML 형식과 같은 문자가 포함됩니다.

2. 레코드 크기

• 하나의 레코드에 저장되는 데이터의 총크기는 20MB로 엄격하게 제한됩니다.
• 이는 하나의 레코드 자체에 저장된 데이터를 의미하며, 파일, 이미지 등 관련된 데이터는 아닙니다.

3. 데이터 탭에서 대량 작업(Bulk operation)

• 데이터 탭의 대량 작업(Bulk operation) 버튼을 사용하여 대량 작업을 시작하면 항목 수가 20,000개로 엄격하게 제한됩니다. 즉, 최대 20,000개의 데이터 셋에 대해 API workflow를 예약할 수 있습니다. 워크플로우의 복잡성, 레코드에 저장된 데이터의 양과 같은 다른 요인에 따라 더 낮은 개수로 소프트 제한에 걸릴 수 있다는 점에 유의해야 합니다.

4. 레코드에 대한 참조 삭제

• 데이터베이스에서 항목을 삭제하면 해당 항목이 삭제되었음을 반영하기 위해 Bubble이 다른 레코드를 업데이트해야 하는 경우도 있습니다. 예를 들어 사용자는 작성자의 필드에서 참조되기 때문에 다른 레코드에 연결될 수 있습니다.
• 이로 인해 겉으로는 단순해 보이는 작업이 더욱 복잡해지고 리소스가 많이 소모될 수 있습니다. 참조 레코드 수가 100,000개를 초과하면 참조 레코드가 제대로 업데이트되지 않는 현상이 발생할 수 있으며, 1,000,000개가 되면 프로세스에서 예기치 않은 데이터베이스 오류가 발생할 가능성이 커집니다.

5. 데이터 리스트 저장

• 데이터베이스에서 목록을 하나의 항목(예: 사용자의 작업들)에 저장하는 데는 레코드 10,000개라는 엄격한 제한이 있습니다.
• 주의할 점은, 긴 목록은 레코드가 보유하고 있는 데이터의 양과 적용하는 처리 종류에 따라 더 짧은 목록 수부터 성능에 영향을 미치기 시작할 수 있습니다. 많은 경우 긴 목록을 저장하는 대신 Do a search for를 사용해서 검색하는 것이 더 효율적입니다.

6. CSV 업로드

• 버블 편집기 또는 앱에 업로드된 CSV 파일의 크기 제한은 5GB입니다. 그러나 몇몇 주요 브라우저에서는 2GB보다 큰 업로드를 안정적으로 허용하지 않으므로 대부분의 사용자에게는 이것이 실질적인 제한사항이 됩니다.

7. 파일 업로드

• 버블 편집기 또는 앱에 업로드된 파일의 크기 제한은 5GB입니다. 그러나 몇몇 주요 브라우저에서는 2GB보다 큰 업로드를 안정적으로 허용하지 않으므로 대부분의 사용자에게는 이것이 실질적인 제한 사항이 됩니다.

 

(3) 디자인과 로직 제한

1. 워크플로 시간 초과(Time out)

• 300초(5분) 이상 걸리는 워크플로는 시간 초과 (Time out)에 해당됩니다.
• 동시에 실행되는 다른 프로세스는 앱의 용량이 최대치에 가까워지면 안정성을 유지하기 위해 버블의 제한으로 인해 앱이 느려질 수 있습니다. 이로 인해 워크플로 속도가 느려지므로 워크플로가 시간 초과되는 경우가 있습니다.

2. 페이지의 element 및 Event/Action 수

• 단일 페이지에 element, Event 및 Action을 합친 총개수는 10,000개로 엄격하게 제한되어 있습니다.

3. URL 길이

• Bubble에는 최대 URL 길이가 없지만 브라우저 호환성을 보장하려면 2,000자 이내로 유지해야 합니다. 일반적으로 효율성과 SEO 목적을 위해 URL을 최대한 짧게 유지하는 것이 좋습니다.
• URL Parameter는 문자 수에 포함됩니다.

 

(4) 앱 통합 제한

1. API Connector 응답(Response)

• API 커넥터 또는 플러그인을 사용하여 수행된 발신 API 호출에 대한 응답에는 50MB라는 엄격한 제한이 있습니다. 제한을 초과하면 로그에 "응답이 너무 큼"이라는 오류가 생성됩니다.

2. API Call의 Header

• API 호출의 헤더는 최대 총크기가 8,000자입니다.

3. API Call의 key

• API 호출의 키 최대 총크기는 20,000자입니다.

4. DATA API 동시 Request

• DATA API는 요금계획에 따라 정해진 수의 요청을 처리합니다.
  • Starter: 15,000
  • Growth: 25,000
  • Team: 35,000