What the Data for This Category Looks Like
The data sources for this category include wafer test maps, MES systems, bonding and molding equipment, ATE test machines, X-ray/SAM testing equipment, and customer specification documents. Data update frequencies fall into three categories: per batch, per die test, and daily. Daily documents include packaging process cards, bonding and molding parameters, wafer incoming material maps, test program versions, yield reports, and failure analysis reports. Data fields include batch number, wafer ID, bonding temperature, molding pressure, test bin code, yield value, and others. Units include degrees Celsius, Pascals, seconds, and others.
What Constraints These Characteristics Impose on the Database and Operations Maintenance Link
Multi-source heterogeneous data sources require databases to support mixed storage of structured and unstructured data. Configure unified field mapping rules to align batch identifiers across different devices and systems. High-frequency data updates create demand for high-concurrency writes. Configure sufficient database connection resources to avoid write blocking. Diverse document types require databases to support associated queries to complete matching verification between wafer maps and physical batches. Strict data consistency requirements mean any field deviation may trigger production abnormalities. Configure basic data validation constraints.
How to Set Configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://fastgpt_seal:custom password@database host:27017/seal_test_db?authSource=admin | Stores unstructured business data such as ATE test raw data and wafer incoming material metadata, and binds exclusive database permissions to prevent unauthorized access |
PG_URL | postgresql://fastgpt_ledger:custom password@database host:5432/production_ledger?sslmode=require | Stores structured production ledger data, supports associated queries for batch and test data, and adapts to complex statistical logic |
DB_MAX_LINK | 20–30 connections | Adapts to concurrent write requests for each batch test, preventing write failures caused by exhausted connections |
REDIS_URL | redis://:custom password@cache host:6379/0 | Caches frequently accessed test program versions and wafer map indexes to reduce repeated query loads on the database |
Three Common Mistakes
- The symptom is a MongoDB connection error
Authentication failed, caused by failing to create a dedicated database user for fastgpt, and using the root user directly to connect, which triggers a permission verification failure. - The symptom is a 400 status code (no body) returned when calling MySQL tools, caused by an incorrect database connection string configuration, or the database not granting external access permissions for the corresponding port.
- The symptom is excessive database write latency, leading to deviations between ledger data and actual production batches, caused by an excessively low
DB_MAX_LINKvalue that cannot support high-concurrency device data write requests.
How to Confirm the Configuration Is Complete
- Execute the MongoDB connection command, log in to the database using the user configured in
MONGODB_URI, and verify that test data collections can be read and written normally. - Log in to the database configuration page in the FastGPT v4.17.0 backend, test the connectivity of
PG_URL, and confirm that structured ledger data can be inserted normally. - View the Redis monitoring panel, confirm that the cache hit rate corresponding to
REDIS_URLaligns with the business access frequency. - Simulate a single batch of device data writes, check that the number of database connections does not exceed the configured
DB_MAX_LINKvalue.
The values provided are common starting points and should be measured against the reader's own samples.