本文回答三个问题关系型数据库怎么存数据怎么保证数据可靠它在地理空间上的能力边界在哪里核心结论先给出关系型数据库把一切存成表——一行是一个对象一列是对象的一项特征这套模型配合 ACID原子性、一致性、隔离性、持久性详见 1.5 节承诺支撑了从银行转账到地图查询的绝大多数系统但它的空间关系只能在查询时临时计算这条边界正是 QLever 这类 RDF 图数据库切入的位置。第一部分关系型数据库本身1.1 表的基本构成行、列、键关系型数据库relational database的核心存储单位是表table。用 OpenStreetMapOSM数据举例节点ID名称类型纬度经度12345天安门广场广场39.9055116.397612346故宫午门景点39.9163116.3972表里每一行是一个具体的对象第一行是天安门广场第二行是故宫午门。行在术语里有很多等价说法——行、记录record、实例instance、实体entity、对象object指的是同一件事。表里每一列是对象的一项特征叫属性attribute对象的一项特征也叫字段field。1.2 主键与外键**主键primary key**是每行的唯一标识值不能重复也不能为空。OSM 里每个节点、每条路径、每个关系都有一个全局唯一的 ID这就是天然的主键。**外键foreign key**指向另一张表的主键让表与表产生关联。OSM 中路径way如一条道路由多个节点node按顺序组成可以用两张表存节点表主键节点ID节点ID纬度经度100139.9000116.4000100239.9001116.4001道路表主键道路ID道路ID道路名称W500长安街东段W501长安街西段如果道路只有起点和终点可以把两个端点节点ID直接放在道路表里。但真实道路通常由几十个节点按顺序组成不同道路的节点数不同不可能都塞进同一行——那样每行列数会不一样。关系型数据库的做法是再加一张道路—节点连接表道路ID节点ID顺序W50010010W50010021W50010032道路ID 和 节点ID 都指向各自表的主键这就是外键顺序列保存节点在道路上的先后。这样无论道路有多少节点道路表本身的列数都固定。1.3 表与表的三种关系关系类型含义OSM 例子一对一A 一行只对应 B 一行一个 OSM 节点对应一个地址条目一对多A 一行对应 B 多行一个行政区包含多条道路多对多互相交叉需中间表一个标签可被多个对象使用一个对象可有多个标签1.4 SQL统一的查询语言SQL 是关系型数据库的标准查询语言做四类事查数据、增数据、改数据、删数据。MySQL、PostgreSQL、Oracle 的语法基本相通学会一套即可通用。1.5 ACID数据库的四个承诺原子性一组操作要么全成功要么全失败。银行转账时扣款和入账必须同时完成入账失败扣款自动回滚。一致性数据始终符合规则。库存不能为负数订单金额必须等于单价乘数量违反规则的操作会被拒绝。隔离性多人同时改同一条记录时数据库用锁机制或**多版本并发控制MVCC**防止互相覆盖。可以理解成数据库给正在修改的记录上锁其他人要么等锁释放要么读一个旧版本的快照不会读到半成品。持久性数据提交后服务器断电也不丢。实现方式是先写日志再写数据——数据库先把操作写进 WAL预写日志然后才改磁盘崩溃后读日志即可恢复。注意持久性保证的是最新数据不丢不是保存所有历史版本想看历史变更需要额外的审计日志功能。1.6 事务与触发器**事务transaction**不只是增删改。它是一组操作单元可以包含查询、数据修改甚至表结构变更。核心特征是这组操作要么全部提交要么全部回滚。比如读取库存 → 判断够不够 → 扣减库存 → 生成订单四步放在一个事务里任何一步出错就全部撤销。**触发器trigger**是数据库里的自动执行程序做完动作 A自动触发动作 B。比如每插入一条新订单自动扣减对应商品的库存每删除一个用户自动清理该用户的关联记录。第二部分关系型数据库的周边2.1 邻居关系型 vs 非关系型关系型数据库先定义表结构再存数据用 SQL 统一查询强调 ACID。非关系型数据库NoSQL不预先定义表结构数据格式灵活强调高并发和高扩展。主要有四类文档型MongoDB、键值型Redis、列族型Cassandra、图型Neo4j。知识图谱通常用图数据库存储属于非关系型。图数据库用点vertex和边edge表示实体及其关联查朋友的朋友比关系型数据库的多次表连接更高效。2.2 扩展方式纵向扩展Scale Up给现有服务器加 CPU、内存、硬盘。关系型数据库天然适合这种方式——表与表关联紧密放在一台机器上做连接查询最方便。横向扩展Scale Out加更多普通服务器把数据分散到多台机器。比如主从复制一台主库负责写多台从库负责读或者分片用户 ID 尾号 0–4 的放 A 服务器5–9 的放 B 服务器。关系型数据库的横向扩展比 NoSQL 困难因为跨机器的关联查询很复杂。2.3 地理空间能力PostGISPostGIS 是 PostgreSQL 的空间扩展。装上它PostgreSQL 就能存储和查询地理空间数据。空间数据类型普通数据库有整数、字符串、日期等类型PostGIS 新增 geometry平面几何和 geography球面地理可以存点、线、面。空间索引普通索引对空间数据无效。PostGIS 提供 GiST / R-Tree 索引专门加速附近有哪些谁和谁相交这类查询。它的原理是先为每个几何对象计算一个外接矩形bounding box再把这些矩形组织成树。查询北京市内有哪些道路时索引先用矩形快速排除明显落在北京市界之外的候选只对少数剩余候选做精确的几何相交判断。所以缩小候选范围发生在昂贵的几何计算之前。空间函数PostGIS 提供几百个以 ST_ 开头的空间函数。为什么这么多因为空间拓扑关系的种类是固定的——相交、包含、相离、接触、重叠、距离、缓冲区每种关系对应几个函数数量就累积起来了。用 OSM 数据举四个例子查北京市内所有餐厅用空间包含关系。查距离天安门 500 米内的地铁站用距离计算。查某条地铁线穿过哪些行政区用相交判断。计算鄱阳湖的面积用面积函数。2.4 PostGIS 的局限与 QLeverPostGIS 功能很强但有一个根本局限空间关系是查询时临时计算的。问哪些道路在北京市行政区内PostGIS 要把每条道路的几何形状跟北京市的边界做实时计算判断是否相交或被包含。空间索引能缩小候选范围但真正的拓扑判断仍发生在查询执行阶段。QLever 的做法QLever 是德国弗赖堡大学开发的开源 RDF 图数据库和 SPARQL 查询引擎官方 README 称其可在单台普通机器上处理超过一万亿条三元组 [3]。它的配套工具 osm2rdf 把 OSM 数据转换成 RDF 三元组triple即主语—谓语—宾语短句[1]。关键在一步osm2rdf 在导入阶段就预计算了常见的空间关系——比如区域 A 包含区域 B“道路 C 与区域 D 相交”——并把这些关系作为显式三元组直接存进数据库。RDF 和三元组的细节见同目录《地理空间智能前沿-背景知识-RDF与SPARQL查询》2.3 节本文不展开。两者的核心区别维度PostGISQLever数据模型关系型表 空间扩展RDF 三元组主语—谓语—宾语空间关系查询时临时计算导入时预计算并存储查询方式SQL 空间函数SPARQL擅长场景事务性强、复杂空间分析、需要 ACID大规模知识图谱、关系遍历、预存拓扑查询举例说明用 PostGIS 查汉堡市内所有街道数据库拿到汉堡市的多边形边界跟每条街道的几何形状逐一做包含判断这是计算密集型操作。用 QLever 查同样的问题osm2rdf 已经把汉堡市包含街道 X作为三元组预存好了查询时直接按图遍历不做任何几何计算。QLever 官方示例显示这类预计算后的拓扑查询比实时几何计算快得多 [2]。但不是替代关系PostGIS 和 QLever 是互补的需要强事务一致性、复杂空间分析缓冲区、叠加分析、坐标转换时PostGIS 更合适。需要在全球尺度的知识图谱里快速遍历拓扑关系时——比如查这个药店位于哪栋楼里这栋楼在哪个行政区这个行政区的人口是多少——QLever 的预计算方式更有优势。QLever 甚至支持联邦查询一条 SPARQL 语句同时查 OSM 和 Wikidata把地理信息和百科知识连起来。Takeaway行、记录、实例、实体、对象指的是同一件事列是属性。主键是唯一标识外键是跨表关联的桥梁。事务不限于增删改是一组要么全成功、要么全失败的操作单元。隔离性靠锁和版本控制实现持久性靠预写日志实现不是保存历史。关系型数据库适合纵向扩展NoSQL 更适合横向扩展。PostGIS 让关系型数据库获得地理空间能力但空间关系是查询时计算的。QLever 在导入时把空间关系预计算成 RDF 三元组在全球尺度知识图谱查询上远快于实时计算但两者适用场景不同。一句话收尾关系型数据库把对象封在行里RDF 把对象散在图里——理解了表才能看清图为什么快。参考文献[1] osm2rdf 转换工具。https://github.com/ad-freiburg/osm2rdf[2] QLever 文档。https://docs.qlever.dev/[3] QLever GitHub 仓库README 中的可扩展性说明。https://github.com/ad-freiburg/qlever版权声明本文为CSDN博主「LadiesAndGentlemen」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。原文链接https://blog.csdn.net/qiupingzhao/article/details/163625924 开源 github