Mega service scaling
This chapter introduces the scaling options, billing granularity, and common limitations of Mega Block cloud localization and mapping services, helping you plan resources and procurement solutions based on application scale and concurrency requirements.
The core of Mega Block cloud localization service is creating and purchasing localization service groups, which are service packages including Standard and Trial plans. The resources included in each plan are as follows:
| Item Name | Standard | Trial |
|---|---|---|
| Mapping project | 1 | 1 |
| Cloud localization DBs | 5 | 2 |
| Request concurrency QPS | 10 | 3 |
In Mega Block mapping services, the core concepts and design principles are:
- One location corresponds to one mapping project; each mapping project can be associated with one cloud localization service group.
- Cloud localization databases within the same service group share QPS quotas (billed per request, counted when carrying AppId and passing authentication).
- To support large-scale or complex scenarios, different floors or areas can be captured and mapped separately, with map fusion available when needed.
Mega service scaling typically involves the following dimensions: concurrency QPS (Queries Per Second), number of cloud localization databases, number of bound mapping projects, single-database map capacity, large-scale/complex scenario map fusion, and video input duration for single mapping. This section explains each item's meaning, impact, and scaling recommendations.
Scalable items description
- Cloud localization concurrency QPS
- Number of cloud localization DBs sharing QPS
- Bound mapping projects
- Map capacity per cloud localization DB
- Mapping capability extension: input video duration, multi-map fusion
Cloud localization service concurrency QPS
Concurrency is measured in QPS, indicating the number of service requests received by the server per second. All requests carrying valid cloud localization DB AppIds that pass authentication are counted, regardless of localization success.
Concurrency is an attribute of the cloud service group. All cloud localization databases in the same service group share the QPS quota.
By default, after successful initialization, devices send localization requests at a frequency of 1 request per second. Due to network latency and random request arrival times, instantaneous requests may theoretically exceed the quota. For example, a 10 QPS service group can support approximately 10 devices simultaneously. However, if more than 10 requests are received within a 1-second window, excess requests may be rejected.
To ensure service stability in multi-device concurrency scenarios, we recommend reserving redundancy when purchasing QPS. For instance, to support 10 devices stably, consider purchasing 11-12 QPS.
Management and scaling operations: QPS scaling management guide
Number of cloud localization databases
Cloud localization database instances require computing resources and are billed per instance. Each database corresponds to a unique AppId. Deleting and recreating a localization database doesn't affect quotas, but the new database will generate a new AppId. If the default quota is insufficient, you can request an increase in the number of localization databases.
Note
Normally, you can reopen a cloud localization database and re-add Mega Blocks without affecting localization. However, after shutdown and reopening, the new localization database will have a different AppId.
To open more cloud localization databases beyond the quota: Additional cloud localization DB operations guide
Bound mapping projects
Our product design philosophy is: one location corresponds to one Mega Block mapping project, and one project corresponds to one cloud localization service group.
To associate more mapping projects with the same service group, refer to the operational guide to ensure proper resource and permission configuration: Binding additional mapping projects guide
Map capacity per cloud localization database
The product design principle for cloud localization databases is: one database provides localization results in a single coordinate system, serving one application. Each cloud localization database has a maximum allowed Block (map) capacity limit. Capacity is measured in CC (EasyAR's proprietary unit). Exceeding this limit will restrict adding maps. However, through resource deployment scaling, we still allow adding multiple maps. Each Mega Block has capacity attributes related to localizable area size and resource usage.
| Per cloud localization DB | Limit |
|---|---|
| Block capacity | 4500 CC |
The current default upper limit example is 4500 (subject to actual product configuration). For higher capacity, contact sales or operations support: Map capacity scaling guide
Mapping limitations and capability extension
Mega Block mapping requires computing resources and service costs. Costs relate to mapping area size, recognition zones, and captured video duration.
| Per mapping task | Limit |
|---|---|
| Single captured video | 16 segments * 8 min/segment |
| Single project | 50,000 sqm |
For each task, there are restrictions on input video duration per captured video. The video limit is 16 segments * 8 minutes per segment. A single map corresponds to one captured video, while complex multi-maps can correspond to multiple videos.
Single projects are limited to 50,000 square meters. Contact business representatives for specifics. Consult business now
Complex scenarios or ultra-large spaces requiring multi-map fusion need business consultation for activation. Most localization scenarios can function effectively with multiple independent single maps without fusion. Consult business representatives to determine if multi-map fusion is necessary.
Detailed operations guide: Mapping capability extension guide
Related topics: