Mega service scaling
This chapter introduces the scaling options, billing granularity, and common limits of Mega Block cloud localization and mapping services, helping you reasonably plan resources and procurement solutions according to your application scale and concurrency requirements.
The core of the Mega Block cloud localization service is creating and purchasing a localization service group. It is a service package itself, including standard and trial packages. The resources of each package are as follows:
| Package item name | Standard | Trial |
|---|---|---|
| Projects for mapping tasks | 1 | 1 |
| Number of cloud localization databases | 5 | 2 |
| Request concurrency QPS | 10 | 3 |
In the Mega Block mapping service, the core concepts and design principles are as follows:
- One location corresponds to one mapping project; each mapping project can be associated with one cloud localization service group.
- Cloud localization databases in the same cloud service group share the QPS quota. It is billed by request, and any request carrying an AppId and passing authentication is counted.
- To support large-scale or complex scenarios, different floors or areas can be collected separately and mapped independently, and maps can be merged when needed.
Mega service scaling usually involves the following dimensions: concurrent QPS (Queries Per Second), number of cloud localization databases, number of bound mapping projects, map capacity of a single database, map merging for large-scale or complex scenarios, and video input duration for a single mapping task. This section explains the meaning, impact, and scaling recommendations for each item.
Scalable items
- Cloud localization concurrent QPS
- Number of cloud localization databases sharing QPS
- Bound mapping projects
- Map capacity of each cloud localization database
- Mapping capability expansion: input video duration, multi-map merging
Cloud localization service concurrent QPS
Concurrency statistics are measured by QPS, which refers to the number of service requests received by the server per second. As long as a request carries a valid cloud localization database AppId and passes authentication, it is counted in concurrency statistics regardless of whether localization succeeds.
Concurrency is an attribute of the cloud service group. All cloud localization databases in the same cloud service group share the QPS quota.
By default, after a device is successfully initialized, it sends localization requests once per second. Due to network latency and randomness in request arrival time, the actual instantaneous number of requests may theoretically exceed the quota. For example, a 10 QPS service group can support about 10 devices using it at the same time, but if the same service group receives more than 10 requests within a 1-second window, the excess requests may be rejected.
To ensure service stability in multi-device concurrency scenarios, we recommend reserving some redundancy when purchasing QPS. For example, if you need to support stable operation of 10 devices, consider purchasing 11-12 QPS.
For management and scaling operations, refer to QPS scaling management operation help.
Number of cloud localization databases
Cloud localization database instances require cloud computing resources, and the quantity is billed by instance. Each database corresponds to an independent AppId. Deleting and recreating a localization database does not affect the quota, but the new localization database will generate a new AppId. If the default quota is insufficient, you can apply to increase the number of localization databases.
Note
Under normal circumstances, reopening a cloud localization database and adding Mega Block again is enough and will not affect localization, but after shutting down and reopening it, the new cloud localization database AppId will be different from the previous one.
To open more cloud localization databases than the quota, refer to: additional cloud localization database operation help
Bound mapping projects
The design philosophy of our product is that one location corresponds to one Mega Block mapping project, and one project corresponds to opening one cloud localization service group.
If you need to attach more mapping projects to the same service group, refer to the operation guide to ensure that resources and permissions are correctly configured: bind more mapping projects operation help
Map capacity of a single cloud localization database
The design philosophy of the cloud localization database product is that the localization result of one cloud localization database is one coordinate system, serving one application. A single cloud localization database has a maximum allowed Block (map) capacity limit. Capacity is measured in CC (EasyAR's private measurement unit). After the upper limit is exceeded, adding maps will be restricted. However, through deployment resource scaling, we still open and allow adding multiple maps. Each Mega Block has a capacity attribute, which is related to the size of the localizable area and resource usage.
| Each cloud localization database | Limit |
|---|---|
| Block capacity | 4500 CC |
The current default upper limit example is 4500 (subject to the actual product configuration). If you need higher capacity, contact sales or operations support: map capacity scaling operation help
Mapping limits and capability expansion
Mega Block mapping requires computing resources and service cost investment. The cost is related to the area you need to map, the recognition area, and the duration of collected video.
| Each mapping task | Limit |
|---|---|
| Single collected video | 16 segments * 8 minutes/segment |
| Single project | 50000 square meters |
For a single collected video in each task, the product has certain limits on input video duration. The video limit is 16 segments * 8 minutes/segment. A single map corresponds to one collected video, and complex multi-map tasks can correspond to multiple collected videos.
A single project is limited to 50,000 square meters of mapping. For details, contact business. Contact business now
Complex scenarios or very large spaces require multiple maps to be merged and need business consultation for activation. Most localization scenarios can be handled by using multiple single maps for independent localization and may not require merged maps. We recommend consulting business before use to determine whether the multi-map merging feature needs to be enabled.
For more detailed operation help, refer to: mapping capability expansion operation help
Related reading: