This document is written based on FastGPT v4.17.0
What the Data for This Category Looks Like
Data for this category primarily comes from ad platform APIs, attribution systems, CRM lead databases, and landing page tracking script data. Update cadences are mostly real-time or daily batch updates. Daily associated documents include ad campaign daily and weekly reports, keyword or creative adjustment records, A/B test creative performance tables, and optimization retrospective logs. Data fields include impressions, clicks, conversions, budget amounts, creative identifiers, delivery time windows, and more. Units are typically counts, monetary units, hours, and similar.
What Constraints Do These Characteristics Impose on Database and Operations Workflows
Typically, data for this category originates from multiple dispersed sources with real-time or daily batch update triggers. This requires the database and operations workflow to support multi-source synchronous writes and avoid connection exhaustion. Daily documents are mostly structured reports and adjustment records, so transactional storage must be configured to ensure data consistency. High-frequency data updates create concurrent write pressure, so connection pool parameters need to be set appropriately. Additionally, data fields include core metrics like budget and conversion volume, so reasonable storage capacity and index structures must be planned to speed up queries for abnormal metrics.
How to Configure the Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | mongodb://user:pass@host:27017/fastgpt_ad?retryWrites=true&w=majority | Adapts to transactional requirements for multi-source synchronous writes, supports failed retries to ensure data consistency |
PG_URL | postgresql://user:pass@host:5432/ad_optimize?sslmode=require | Stores structured adjustment records, test reports, and similar documents; SSL encryption protects sensitive data security |
DB_MAX_LINK | 200–300 connections | Adapts to real-time/high-concurrency data update scenarios, prevents write failures caused by connection exhaustion |
REDIS_URL | redis://:pass@host:6379/0 | Caches frequently queried campaign performance metrics to shorten response times for anomaly localization |
Three Common Misconfigurations
- Symptom: Knowledge base sync fails, interface displays "Data source connection timeout" or empty fields. Cause:
MONGODB_URIis not correctly configured to point to the docker-deployed database instance, preventing FastGPT from reading synced knowledge base data. - Symptom: Database backup files are too large to transfer directly to local storage. Cause: No batch backup strategy is configured for the high-data-volume campaign performance optimization scenario, resulting in single backup files exceeding local storage limits.
- Symptom: Real-time campaign metric queries time out, with insufficient results returned. Cause: No reasonable
DB_MAX_LINKparameter is set, exhausting the database connection pool and preventing new query connections from being established.
How to Verify Proper Configuration
- Execute the built-in database connectivity test tool to verify the connection status of
MONGODB_URI,PG_URL, andREDIS_URL, confirming no authentication or address configuration errors. - Submit a simulated campaign adjustment record, review system logs and database table data to confirm successful data writing.
- Initiate multiple concurrent metric query requests to confirm the database connection pool is not exhausted, and connection counts meet business concurrency requirements.
- Review the cache monitoring panel to confirm frequently accessed campaign data is properly cached, and query processes behave as expected.
The values provided are common starting points and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.