What Data for This Category Looks Like
Model allocation data primarily comes from platform workflow call requests, application model scheduling configurations, and model service return logs. Data updates follow two rhythms: real-time generation and scheduled synchronization. Real-time generation creates full-link records for single model calls. Scheduled synchronization updates the effective status of scheduling policies in batches. Each data record includes fields such as scheduling unique identifier, associated application ID, target model ID, allocation trigger condition, call latency, execution status, and more. The request_timestamp field uses milliseconds as its unit. The response_latency field uses seconds as its unit. The status field is an enumeration type, with valid values including pending, running, success, and failed.
Constraints Imposed on Database and Operations Workflows
Real-time generated call records create high concurrent write pressure. Databases must support horizontal sharding and batch write optimization to avoid single-node write bottlenecks. Scheduled synchronization of scheduling policy update data requires atomic update support. This ensures consistency of configuration effective status. Fields for associated application ID and model ID need joint indexes. This speeds up query statistics by application or model dimension. Enumeration type status fields must have valid value ranges predefined. This prevents dirty data from being written. Data volume grows with platform call volume. Automatic archiving rules must be configured. This migrates historical records beyond the retention period to cold storage. This reduces online storage pressure.
How to Configure Parameters
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGO_SHARD_COUNT | 3–5 | Call record data volume for model allocation grows with application count. 3-5 shards balance write and query load, and align with sharding deployment specifications for v4.15 |
DB_RETENTION_DAYS | 30–90 days | Historical model allocation records only support operations troubleshooting and policy optimization. This range balances storage costs and data availability |
ALLOCATION_LOG_INDEXES | ["app_id", "model_id", "request_timestamp"] | Queries by application, model, and time dimension are frequent scenarios for operations and statistics. Joint indexes effectively speed up these queries |
PARALLEL_WRITE_WORKERS | 8–16 | Real-time call record write concurrency is high. This parameter controls batch write thread count, balancing server resource usage and write efficiency |
DB_CONNECTION_POOL_SIZE | 20–50 | Database connection demand for model allocation scheduling fluctuates with application call volume. This range covers peak connection demand and avoids connection leaks |
Three Common Configuration Mistakes
- Docker container deployment results in failed MongoDB connection, with
connection refusederror. The cause is incorrect modification of database connection configuration within the container, and failure to map the local MongoDB address to the container network. - Connection to local MongoDB via MongoDB Compass fails, returning
authentication failederror. The cause is incorrect configuration of MongoDB username and password in FastGPT, or failure to enable remote access permissions for the database. - Model allocation call records lack the
response_latencyfield. The cause is failure to validate required fields during data writing, leading to incomplete field population for some abnormal call records.
How to Verify Successful Configuration
- Database connection tests are run using the configured MongoDB address and credentials to verify successful connection establishment.
- A model allocation call is initiated, and the database is checked for a complete record including
app_id,model_id, andrequest_timestamp. - Joint index queries are executed, filtering call records by specified application ID and time range to confirm query results match expectations.
- The database storage monitoring panel is reviewed, confirming write concurrency and connection count do not exceed configured threshold ranges.
The parameter values provided on this page are common starting points for configuration. Actual values are affected by data characteristics, data volume, and business rules. Specific issues require targeted analysis. Testing on local samples is recommended before finalizing settings.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.