What Is Database Federation?什么是数据库联邦？
This focused article is part of the federated queries and data virtualization guide; use the pillar guide to compare related concepts, methods, and implementation decisions across the full topic.
本文是联邦查询与数据虚拟化指南内容集群中的专题文章；如需比较完整主题下的相关概念、方法与实施决策，请返回基石指南。
Database federation coordinates queries across multiple autonomous databases through a shared logical access layer while each database retains its own schema, engine, owner, and operational boundary. The federation maps logical objects to exported local objects, decomposes a request, executes eligible work near each component database, transfers selected results, and completes remaining joins or transformations.
数据库联邦通过共享逻辑访问层协调多个自治数据库的查询，同时让每个数据库保留自己的Schema、引擎、所有者和运行边界。联邦层把逻辑对象映射到对外发布的本地对象，分解请求，在各组件数据库附近执行符合条件的工作，传输经过选择的结果，再完成剩余连接或转换。
A single SQL endpoint does not make the databases physically one system. Metadata, query fragments, intermediate rows, errors, and credentials still cross boundaries. Local teams may change schemas, statistics, maintenance windows, and policies independently. A production design therefore exposes autonomy and heterogeneity instead of masking them as implementation details.
单一SQL端点并不会让这些数据库在物理上变成一个系统。元数据、查询片段、中间行、错误和凭据仍会跨越边界；本地团队也可能独立调整Schema、统计信息、维护窗口和策略。因此生产设计应显式呈现自治性与异构性，而不是把它们藏成实现细节。
The foundational Sheth and Larson paper describes a federated database system as cooperating database systems that are autonomous and possibly heterogeneous. That definition remains useful, but modern products use overlapping labels. Confirm actual schema mediation, pushdown, write support, consistency, and failure behavior rather than assuming a feature from the word “federation.”
Sheth与Larson的奠基论文把联邦数据库系统描述为一组协作、自治且可能异构的数据库系统。这个定义仍然有用，但现代产品的命名存在重叠。应验证实际Schema中介、下推、写入支持、一致性和故障行为，而不是从“联邦”一词推断功能。
Build a Database Federation Architecture from Local to Global Schema从本地Schema构建数据库联邦架构
Each source owns its native schema. A component representation normalizes supported types and capabilities without changing the source database.
每个来源拥有原生Schema。组件表示在不改变源数据库的前提下规范受支持类型与能力。
A source exposes only approved tables, columns, views, functions, and write paths. This is the contract offered to the federation.
来源只发布获批的表、列、视图、函数和写入路径，这就是其向联邦提供的契约。
Shared objects resolve names, relationships, types, and semantics across exports. The model records conflicts rather than pretending every local term agrees.
共享对象跨导出Schema解析名称、关系、类型与语义；模型应记录冲突，而不是假装所有本地术语一致。
Consumer-specific views expose only the fields, naming, row scope, and freshness appropriate to each workload.
面向使用者的视图只暴露各工作负载适用的字段、命名、行范围和新鲜度。
Not every implementation materializes all five classical schema levels, and product names differ. The durable rule is traceability: every consumer field must resolve through a versioned mapping to an owner-approved local field, expression, or authoritative reference. Record units, code systems, collation, time zones, decimal precision, null meaning, key cardinality, and observation time.
并非每种实现都会显式建立经典五层Schema，产品命名也不一致。持久原则是可追溯：每个消费字段都必须通过版本化映射解析到所有者批准的本地字段、表达式或权威参照。还要记录单位、代码体系、排序规则、时区、小数精度、空值含义、键基数和观察时间。
How Database Federation Works from Query to Result数据库联邦如何从查询走到结果
- Authenticate and bind.认证与绑定。 Resolve the caller, purpose, session settings, and external schema.解析调用者、用途、会话设置和外部Schema。
- Resolve logical objects.解析逻辑对象。 Map views and fields through the mediated schema to exported component objects and owners.经中介Schema把视图与字段映射到导出的组件对象及所有者。
- Discover capabilities.发现能力。 Read connector features, types, functions, statistics, locality, transaction support, and health.读取连接器能力、类型、函数、统计、位置、事务支持和健康状态。
- Decompose and authorize.分解与授权。 Split the logical plan into database-specific subplans and federation-stage work, then check every access path.把逻辑计划拆成数据库子计划与联邦阶段工作，再检查每条访问路径。
- Optimize placement.优化执行位置。 Choose predicates, projections, aggregates, joins, limits, and functions that are safe to push down.选择能够安全下推的谓词、列、聚合、连接、限制和函数。
- Execute with budgets.按预算执行。 Apply connection pools, deadlines, cancellation, concurrency limits, memory limits, spill controls, and source quotas.应用连接池、截止时间、取消、并发限制、内存限制、溢写控制和源端配额。
- Join and reconcile.连接与核对。 Normalize returned types, combine remaining streams, preserve observation metadata, and reject hidden partial results.规范返回类型，组合剩余数据流，保留观察元数据，并拒绝隐藏的部分结果。
- Return evidence.返回证据。 Expose source versions, plan fragments, pushdown, rows, bytes, timing, policy decisions, warnings, and coverage.暴露来源版本、计划片段、下推、行数、字节、时序、策略决定、警告和覆盖范围。
IBM’s first-party documentation gives one concrete example: a federated server distributes requests and treats remotely processed work as pushdown. PostgreSQL exposes another implementation model through foreign servers, user mappings, foreign tables, and foreign-data wrappers. These examples illustrate mechanisms, not a universal contract.
IBM第一方文档给出一种具体实现：联邦服务器分发请求，并把远程处理的工作称为下推。PostgreSQL则通过外部服务器、用户映射、外部表和外部数据包装器展示另一种实现模型。这些示例说明机制，并不代表统一契约。
Control Pushdown, Distributed Joins, and Source Load控制下推、分布式连接与源端负载
Push down predicates, projections, aggregation, and limits only when connector translation preserves meaning. Verify the remote SQL or source plan; do not infer pushdown from a fast demo. Functions, collations, null ordering, time zones, or type casts can prevent remote evaluation. Stale statistics can also make a planner move the large side of a join.
只有在连接器转换保持语义时，才下推谓词、投影、聚合与限制。应验证远程SQL或来源执行计划，不能从一次快速演示推断下推。函数、排序规则、空值顺序、时区或类型转换可能阻止远程计算；陈旧统计信息也可能让规划器移动连接中的大表一侧。
| Choice选择 | Use when适用条件 | Verify验证内容 |
|---|---|---|
| Push join to one database把连接下推到一个数据库 | Both objects are reachable there and semantics match两个对象均可到达且语义一致 | Remote plan, privileges, temporary data handling远程计划、权限和临时数据处理 |
| Broadcast a small side广播小表侧 | Cardinality is bounded and movement is allowed基数有界且允许移动 | Actual rows, bytes, sensitivity, spill实际行数、字节、敏感性和溢写 |
| Join in federation layer在联邦层连接 | Sources cannot safely share work来源无法安全共享工作 | Network, memory, partitioning, skew, deadline网络、内存、分区、倾斜和截止时间 |
| Materialize a fragment物化一个片段 | The same heavy or unstable subplan repeats同一重型或不稳定子计划反复出现 | Freshness, lineage, refresh recovery, storage新鲜度、血缘、刷新恢复和存储 |
Protect business databases with read replicas where valid, dedicated pools, query tags, rate limits, statement timeouts, cancellation propagation, lock limits, and workload windows. Measure source CPU, I/O, connections, cache disruption, locks, rows scanned, rows returned, and bytes transferred alongside federation latency.
应在适用时使用只读副本，并通过专用连接池、查询标签、限速、语句超时、取消传递、锁限制和负载窗口保护业务数据库。除联邦延迟外，还要测量源端CPU、I/O、连接数、缓存扰动、锁、扫描行、返回行和传输字节。
Handle Schema Drift, Slow Databases, and Partial Failure处理Schema漂移、慢数据库与部分故障
Version exports, mappings, connector capabilities, drivers, and statistics. Detect renamed or removed objects, type and collation changes, altered constraints, permission drift, capability regression, and changed cardinality. Quarantine incompatible mappings instead of silently coercing them. PostgreSQL warns that foreign-table constraints are often assumed rather than enforced locally; a false declaration can produce incorrect planning or results.
应为导出、映射、连接器能力、驱动与统计设定版本，并检测对象重命名或删除、类型和排序规则变化、约束变化、权限漂移、能力退化及基数变化。不兼容映射应隔离，而不是静默强制转换。PostgreSQL提醒，外部表约束通常由本地假定而非强制执行；错误声明可能导致错误计划或结果。
Use per-database connection and read timeouts, one overall deadline, cancellation propagation, bounded retries with jitter, circuit breakers, bulkheads, backpressure, and spill limits. Retry only safe reads. Never present a partial answer as complete. If a workload explicitly permits degradation, return missing databases, coverage, observation times, unresolved joins, and the business meaning of the degraded result.
应使用每数据库连接与读取超时、整体截止时间、取消传递、带抖动的有界重试、断路器、舱壁、背压和溢写限制。只重试安全读取，绝不能把部分答案呈现为完整结果。若工作负载明确允许降级，必须返回缺失数据库、覆盖范围、观察时间、未解决连接和降级结果的业务含义。
Hypothetical Example: Federating CRM, Orders, and Stock Databases假设示例：联邦CRM、订单与库存数据库
Illustrative scenario, not a customer case: a service team needs open-order exposure by customer risk tier and current stock. Customers are owned in a PostgreSQL CRM database, orders in a SQL Server database, and stock in a MySQL operational database. Each owner publishes a read-only view with approved columns, key definitions, an observation timestamp, and a capacity limit.
这是说明性场景，不是客户案例：某服务团队需要按客户风险等级和当前库存查看未结订单风险。客户由PostgreSQL CRM数据库管理，订单位于SQL Server，库存位于MySQL业务数据库。每位所有者都发布只读视图，明确获批列、键定义、观察时间戳和容量限制。
The mediated schema maps three local identifiers to one governed customer and SKU crosswalk. The planner pushes open-status and date predicates plus order aggregation to SQL Server, fetches only required tiers from PostgreSQL, and requests only relevant SKUs from MySQL. The remaining small results join in the federation layer. The response records three observation times because the databases do not share one snapshot.
中介Schema通过受治理对照表把三个本地标识映射到统一客户与SKU。规划器把未结状态、日期谓词和订单聚合下推到SQL Server，只从PostgreSQL读取所需等级，并仅向MySQL请求相关SKU；剩余小结果在联邦层连接。由于这些数据库不共享一个快照，响应记录三个观察时间。
Illustrative acceptance thresholds: at most 12 concurrent requests, a 45-second overall deadline, zero unexplained reconciliation difference, a documented row and byte budget per database, and explicit failure if the stock database is unavailable. Load testing shows that month-end historical scans exceed the order database envelope, so the team materializes the historical aggregate nightly while leaving current stock federated. These values are examples, not InfiniSynapse or vendor guarantees.
示例验收阈值：并发最多12个、整体截止45秒、无法解释的核对差异为零、每数据库明确行数与字节预算，并在库存数据库不可用时显式失败。负载测试显示月末历史扫描超出订单数据库范围，因此团队每晚物化历史聚合，同时继续联邦当前库存。这些数值只是示例，不是InfiniSynapse或任何厂商的保证。
Use InfiniSynapse for an Approved Multi-Database Analysis使用InfiniSynapse执行获批的多数据库分析
InfiniSynapse’s public site presents direct connections to supported platforms such as Snowflake, Supabase, PostgreSQL, and MySQL, plus multi-source joint analysis without requiring a complex migration. That makes the application a related entry for a bounded, authorized analysis. This guide does not claim that InfiniSynapse is a general database-federation server, global-schema mediator, distributed transaction coordinator, connector SDK, policy engine, or replacement for database controls.
InfiniSynapse官网说明其可直接连接Snowflake、Supabase、PostgreSQL和MySQL等受支持平台，并在不要求复杂迁移的情况下进行多来源联合分析。因此，该应用可作为有边界、获授权分析的相关入口。本指南不声称InfiniSynapse是通用数据库联邦服务器、全局Schema中介、分布式事务协调器、连接器SDK、策略引擎或数据库控制替代品。
Before starting, prepare supported connection details, owner approval, least-privilege credentials, network and certificate requirements, exported views, join keys, field definitions, observation-time expectations, query scope, result limits, and database-load budgets. Keep architecture, schema governance, policy enforcement, monitoring, and recovery with the responsible source and platform teams.
开始前，请准备受支持连接详情、所有者批准、最小权限凭据、网络与证书要求、导出视图、连接键、字段定义、观察时间预期、查询范围、结果限制和数据库负载预算。架构、Schema治理、策略执行、监控与恢复仍由负责的来源及平台团队管理。
When the approved databases, access, semantics, and workload guardrails are ready, open InfiniSynapse to perform the authorized analysis within the confirmed product workflow.
当获批数据库、访问、语义和工作负载护栏准备就绪后，可打开InfiniSynapse，在已确认的产品工作流内执行授权分析。
Analyze approved database sources分析获批数据库来源Database Federation FAQ数据库联邦常见问题
What is database federation?
什么是数据库联邦？
Database federation is an architecture and operating pattern that lets a coordinated query layer access multiple autonomous databases through a shared logical interface while each component database retains its own engine, schema, owner, and operational controls. The federation maps logical objects to local objects, decomposes queries, executes eligible work near each database, and combines selected results.
数据库联邦是一种架构与运行模式，让协调查询层通过共享逻辑接口访问多个自治数据库，同时各组件数据库保留自己的引擎、Schema、所有者和运行控制。联邦层把逻辑对象映射到本地对象，分解查询，在各数据库附近执行符合条件的工作，再组合经过筛选的结果。
How does database federation work?
数据库联邦如何工作？
A federation layer authenticates the caller, binds a request to a mediated or global schema, resolves each object to an exported local schema, checks connector capabilities and policy, decomposes the plan, pushes supported filters and calculations to component databases, transfers selected rows, performs remaining joins or transformations, and returns results with execution evidence.
联邦层验证调用者身份，把请求绑定到中介或全局Schema，将对象解析到对外发布的本地Schema，检查连接器能力与策略，分解执行计划，把受支持的筛选和计算下推到组件数据库，传输经过选择的行，执行剩余连接或转换，并返回带执行证据的结果。
What is the difference between database federation and a federated database?
数据库联邦与联邦数据库有什么区别？
Database federation describes the process, architecture, and controls used to coordinate autonomous databases. A federated database is the logical database or user-facing composite produced by that arrangement. Product terminology varies, so evaluate schemas, autonomy, execution plans, consistency, security, and failure behavior instead of relying on a label.
数据库联邦描述协调自治数据库所用的过程、架构和控制；联邦数据库则是这种安排产生的逻辑数据库或面向用户的组合对象。产品术语并不统一，因此应检查Schema、自治性、执行计划、一致性、安全和故障行为，而不是只依赖名称。
Is database federation the same as sharding?
数据库联邦等同于分片吗？
No. Sharding partitions one logical dataset across nodes, commonly under one application or database design, to distribute capacity. Database federation coordinates separately owned or heterogeneous databases that already have independent schemas and lifecycles. A system can use sharding inside a component database and federation above several components.
不等同。分片把一个逻辑数据集分布到多个节点，通常处于同一应用或数据库设计之下，用来分散容量；数据库联邦协调已经具有独立Schema与生命周期、可能由不同团队拥有或采用不同引擎的数据库。组件数据库内部可以分片，而多个组件之上再使用联邦。
Does database federation provide distributed transactions?
数据库联邦是否提供分布式事务？
Not automatically. Some products and source combinations support remote writes or one-phase or two-phase commit, while others are read-only or provide narrower semantics. Treat cross-database writes as a separate design: verify participant support, failure recovery, locks, timeouts, in-doubt handling, and business compensation before enabling them.
并不会自动提供。某些产品与来源组合支持远程写入、单阶段或两阶段提交，另一些只读或仅提供更窄语义。应把跨数据库写入作为独立设计，启用前验证参与者支持、故障恢复、锁、超时、存疑事务处理和业务补偿。
How do you test database federation for production?
如何对数据库联邦进行生产验收？
Reconcile representative results against source-native controls; inspect object resolution, pushdown, join location, bytes moved, and source load; compare direct and federated permissions; and inject slow sources, timeouts, expired credentials, schema drift, cancellation, and partial outages. Approve a bounded workload envelope with named owners and rollback criteria.
用代表性结果与来源原生对照核对；检查对象解析、下推、连接位置、移动字节和源端负载；比较直连与联邦权限；并注入慢源、超时、凭据过期、Schema漂移、取消和部分故障。最终批准带有明确所有者与回退标准的有限工作负载范围。
Official Sources and Verification Notes官方来源与验证说明
- Sheth and Larson’s primary paper on autonomous, heterogeneous federated database systems and reference architectureSheth与Larson关于自治异构联邦数据库系统及参考架构的原始论文
- IBM Db2 documentation for federated servers, distributed requests, source clients, and pushdownIBM Db2关于联邦服务器、分布式请求、来源客户端与下推的文档
- IBM Db2 documentation for transaction protocols in a federated systemIBM Db2关于联邦系统事务协议的文档
- PostgreSQL documentation for foreign servers, user mappings, foreign tables, and foreign-data wrappersPostgreSQL关于外部服务器、用户映射、外部表和外部数据包装器的文档
- PostgreSQL CREATE FOREIGN TABLE documentation and constraint cautionsPostgreSQL CREATE FOREIGN TABLE文档与约束注意事项
- Microsoft SQL Server documentation for linked servers, providers, distributed queries, and login mappingsMicrosoft SQL Server关于链接服务器、提供程序、分布式查询和登录映射的文档
These sources describe formal concepts and concrete implementations; they do not establish one universal feature set. Verify the exact database version, driver, connector, source combination, security model, transaction behavior, limitations, and commercial terms you plan to operate.
这些来源说明形式概念与具体实现，并不建立统一功能集。请针对计划运行的确切数据库版本、驱动、连接器、来源组合、安全模型、事务行为、限制和商业条款重新验证。