【金融科技工程】账务数据库设计：TiDB/OceanBase/Postgres 下的分片、索引、热点账户
💡
原文中文，约23500字，阅读约需56分钟。
📝
内容提要
本文探讨了金融账务数据库的设计与选型，强调服务级别协议（SLA）在数据库选择中的重要性。分析了PostgreSQL、MySQL、OceanBase等数据库的优缺点及适用场景，特别是在高并发和强一致性方面的表现。提出了分片策略、热点账户处理和审计合规等设计原则，强调数据完整性和归档的重要性，并提供了选型建议和实施清单，以帮助工程师做出合理决策。
🎯
关键要点
- 金融账务数据库设计受业务SLA（服务级别协议）限制，RPO=0和RTO<1min是基本要求。
- 账务数据库需满足强一致性，事务原子性和线性一致读是关键。
- 审计和归档要求严格，分录一旦落库不可更改，需通过红冲分录体现。
- PostgreSQL、MySQL、OceanBase等数据库各有优缺点，适用场景不同。
- 分片策略需根据业务特点选择，用户ID、科目、时间等维度均可考虑。
- 热点账户问题严重，需通过分桶、批量合并等策略进行处理。
- 索引设计应关注核心查询模式，使用覆盖索引和分区索引提高性能。
- 冷热数据分层存储，热层用于OLTP，温层用于报表和审计，冷层用于长期归档。
- 并发控制需采用MVCC，悲观锁和乐观锁结合使用以提高性能。
- 选型建议应根据日分录规模和业务需求，合理选择数据库和架构。
❓
延伸问答
金融账务数据库设计中，SLA的基本要求是什么？
金融账务数据库的基本要求是RPO=0（零数据丢失）和RTO<1分钟（故障恢复时间）。
在选择金融账务数据库时，PostgreSQL、MySQL和OceanBase各有什么优缺点？
PostgreSQL适合中小规模账务，约束强但写扩展性有限；MySQL运维成熟，适合中到大规模，但跨分片事务复杂；OceanBase适合超大规模账务，支持多租户和分布式事务，但运维门槛高。
如何处理金融系统中的热点账户问题？
可以通过分桶策略将逻辑账户拆分为多个物理桶，随机或哈希打散写入，查询时聚合各个桶的余额。
金融账务数据库的索引设计应关注哪些核心查询模式？
索引设计应关注账户流水查询、业务回溯和对账聚合等核心查询模式，使用覆盖索引和分区索引以提高性能。
在金融账务数据库中，如何确保数据的完整性？
可以通过设置CHECK约束、使用触发器保证余额守恒，以及建立软外键来确保数据的完整性。
冷热数据分层存储的目的是什么？
冷热数据分层存储的目的是根据数据的使用频率和生命周期，将热数据存储在高性能的OLTP数据库中，而将冷数据存储在低成本的归档系统中，以降低存储成本和提高查询效率。
➡️
