What this category of data looks like
This category of data covers the entire process of ironmaking, steelmaking, continuous casting, quality control and scheduling departments. Daily documents include heat plans, batching lists, converter smelting records, composition reports, continuous casting process records, and slab judgment sheets. Data sources include hot metal and scrap steel data, L2 process control, laboratories, MES, energy medium systems, and equipment status. Update frequencies cover per heat, real-time, and per shift. Data fields include heat unique identifiers, hot metal temperature, composition content, continuous casting pulling speed, and other fields with dedicated units corresponding to different business links.
What constraints these characteristics impose on the database and operations maintenance link
This category of data is multi-source, heterogeneous, and has highly varied update frequencies. Real-time L2 process data requires low-latency writing. Structured records for each heat require frequent new entries. Shift-level summarized data requires scheduled synchronization. These factors place high demands on the database's concurrent processing capabilities. The production process cannot be stopped arbitrarily, and heats and casting sequences are tightly coupled. A database outage will directly disrupt the production flow, leading to issues such as heat downgrades and continuous casting interruptions. As a result, database high availability and rapid recovery capabilities must be ensured. The field formats of various document types vary significantly, so storage and querying must adapt to different data structures. A complete data link must also be retained to facilitate traceability of production issues.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://username:password@host:port/fastgpt?authSource=admin&connectTimeoutMS=30000 | Adapts to storage of multi-source structured and unstructured ledger data, supports sharding expansion to handle high-frequency heat data writes, and ensures reasonable connection timeouts |
PG_URL | postgresql://username:password@host:port/fastgpt | Stores tightly coupled heat-casting sequence association data and summarized report metadata, supports complex associated queries |
DB_MAX_LINK | 200–300 | Matches the connection requirements of multi-department concurrent queries and real-time data writes, and avoids connection pool exhaustion |
REDIS_URL | redis://:password@host:port | Caches real-time L2 process data and summarized results of high-frequency queries, reducing real-time query load on the primary database |
Three common configuration errors
- Symptom: After deploying FastGPT v4.17.0, logs indicate database connection failures, and the login interface is inaccessible. Cause: Connection parameters for
MONGODB_URIorPG_URLare not configured correctly, the authentication source for the corresponding database is not specified, or account permissions are insufficient. - Symptom: External MongoDB tools cannot directly manage storage data related to ledgers. Cause: External access permissions for the corresponding database are not enabled, and FastGPT storage relies on a specific index structure. Direct modifications may damage data consistency.
- Symptom: Some fields are missing or data is incomplete when generating ledger summarized reports. Cause: Synchronization logic is not configured to adapt to the update frequencies of multi-source data, resulting in real-time heat data not being synchronized to the summary database in a timely manner, or the
DB_MAX_LINKconfiguration is too low, causing some write requests to be discarded.
How to confirm configurations are correct
- Run a database connection test script to verify connectivity for
MONGODB_URI,PG_URL, andREDIS_URL, and confirm there are no authentication or network errors. - Import full-process document data for a single heat, query the corresponding storage repository, and confirm that data fields are complete and formatted in accordance with business requirements.
- Simulate a scenario of multi-department concurrent ledger queries, observe changes in database connection counts, and confirm that the
DB_MAX_LINKconfiguration covers concurrent requirements. - Generate a shift-level ledger summarized report, verify the match between report data and original data sources, and confirm that the data synchronization logic functions normally.
The values provided are common starting points and should be measured against the reader's own samples.