What the data for this category looks like
Business data for crowdsourced annotator management comes primarily from crowdsourcing platforms, annotation quality data, training and examination systems, and financial systems. Daily maintenance documents include personnel access rules, training materials, performance sheets, and settlement lists. Data update frequencies are mostly daily or monthly. Core time-consuming steps include personnel screening, quality ranking, and settlement verification. The data structure includes basic personnel information, annotation quality scores, training assessment results, and financial settlement details. This category focuses on end-to-end data related to personnel organization and performance settlement, and has obvious differences from the category characteristics of text annotation projects.
What constraints these characteristics impose on database and operations
Multi-source data access requires the database to support cross-table join queries. This enables cross-system data integration for personnel screening, quality ranking, and settlement verification. Daily or monthly batch data updates require the database to have stable batch write and transaction support capabilities. This prevents data inconsistencies during settlement verification. High-concurrency query demands from core time-consuming steps need reasonable connection pool and index optimizations for the database. This stops system response delays caused by excessive query pressure. Data is directly linked to personnel performance and financial settlement. Any errors can lead to incorrect or missed payments, or project delays. Operations must prioritize data accuracy and recoverability. Complete backup and rollback mechanisms must be configured.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | Single-node deployment: mongodb://[username]:[password]@[host]:27017/fastgpt; Production replica set deployment: mongodb://[username]:[password]@[host1]:27017,[host2]:27017,[host3]:27017/fastgpt?replicaSet=rs0 | Stores unstructured data such as annotation conversation history and personnel operation logs. Single-node deployment suits local testing. Replica sets ensure high availability for production environments. |
PG_URL | postgresql://[username]:[password]@[host]:5432/fastgpt | Stores structured data such as personnel performance sheets, settlement lists, and access rules. PostgreSQL supports complex cross-table join queries. This meets the business requirements of personnel screening and quality ranking. |
DB_MAX_LINK | 200–300 concurrent connections | Supports high-concurrency query demands for batch settlement verification and personnel quality ranking. This prevents service interruptions caused by exhausted connections. |
REDIS_URL | redis://[password]@[host]:6379/0 | Caches frequently accessed personnel lists and performance ranking data. This reduces repeated query pressure on databases and improves response speeds for core steps. |
Three common configuration mistakes
- An error "replica set not configured" occurs on startup. This happens when a local single-node deployment retains replica set configuration parameters, and the content of
MONGODB_URIis not adjusted for the actual deployment scenario. - Annotation conversation history cannot be viewed in MongoDB. This occurs when
MONGODB_URIdoes not correctly specify the database namespace. This leads to data being written to the wrong database or not linked to conversation data for the corresponding annotation project. - MongoDB cannot be connected during local Windows 10 deployment. This occurs when the host address, port, or authentication information in
MONGODB_URIis configured incorrectly. This does not match the actual running parameters of the local MongoDB instance.
How to confirm correct configuration
- Run the database connectivity detection tool built into FastGPT v4.17.0. Verify whether the connection status of
MONGODB_URIandPG_URLis normal. - Submit a test personnel access record. Check whether corresponding data entries are generated in MongoDB and PostgreSQL. Verify that database write functions work properly.
- Initiate a batch performance query operation. Observe system response times. Confirm that the
DB_MAX_LINKconfiguration supports concurrent query demands. No connection exhaustion errors occur. - View Redis monitoring metrics. Confirm that the cache hit rate is within a reasonable range. Verify that the caching function configured via
REDIS_URLis working correctly.
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.