在某市政和公共服务融合建设项目中， 南大通用GBase 8c分布式数据库（gbase database）以一套技术栈同时支撑了报表通（HTAP）、数据中台、物联感知、CIM、智慧综合杆、AI 大模型等异构业务，覆盖交易处理、批量分析、HTAP与空间数据查询等异构负载。从PostgreSQL平滑迁移，数据库形态按业务特征精准选型，最终实现 “一库多能，统一纳管”。
这套架构是怎么落地的？本文继续为你详细拆解。
2、报表通：HTAP让交易和分析“同库办公”
报表通是这个项目里负载最复杂的场景：既要承接事务写入，又要随时跑报表分析。
行业里的常规做法是什么？“两套系统”：一套专门管交易写入，一套专门跑报表分析，中间靠同步链路把数据搬过去。好处是各管各的互不干扰，坏处也很明显 —— 报表永远比业务慢半拍，而且多一套系统就多一份运维成本。
GBase 8c的解法是 HTAP 架构—— 交易和分析不用分家，同一份数据底座，两边一起用。交易写入和查询分析共享同一份数据，库间不再需要搬数据，库内通过增量合并机制保证分析侧能看到最新数据。传统“T+1”式同步模式下，报表永远追不上业务节奏；HTAP让报表跟上了业务的实时步伐。
更有意思的是报表通上层做的智能取数：报表通平台把所有表的“说明书”整理入库，结合语义匹配技术，业务人员用大白话描述需求，系统就能自动找到对应的表、生成查询、直接出数。 从 “找表、翻文档、写 SQL”，变成了 “说句话就取数”。
这背后，是GBase 8c在存储模式上做的功夫：一份数据里，既有适合高并发交易的行存结构，又有适合大范围统计的列存结构 —— 交易和分析这对 “天生矛盾”，在一个库里就化解了。
3、不搞 “一刀切”：分布式与主备式的精准配对
这个项目最值得说道的，不是“上了分布式”，而是“没全上分布式”。
9套系统，数据特征天差地别：物联网类系统（两套）特点是设备接入量大、数据持续写入、数据体量大，采用分布式部署（两分片）。CIM平台、CIM-人口地图、智慧综合杆、AI大模型、数据中台等采用主备式部署，以业务数据读写为主。
可能有人会问： 既然分布式这么厉害，为什么不全上？
因为分布式不是免费的 —— 分片越多，机器越多，成本越高，运维也越复杂。
业务读写为主的系统，用主备式架构就足够稳定高效，硬上分布式纯属浪费资源。而物联网系统这种持续高写入、大数据量的场景，分布式的水平扩展能力才真正用得上。
一边是存储模式按需选（OLTP、OLAP or HTAP），一边是部署形态按需配（分布式or集中式） 。没有完美架构，只有最适合业务的架构。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69979120/viewspace-3187455/ ，如需转载，请注明出处，否则将追究法律责任。
