超大规模数据库下Django filter查询优化及地理空间数据存储方案咨询

查询语句优化 #

• 你当前使用的datetime__date=requested_date写法会触发数据库对datetime字段做函数运算，无法命中普通索引，导致全表扫描。将查询改为范围匹配即可规避这个问题：

  from datetime import timedelta
  Model.objects.filter(
      datetime__gte=requested_date,
      datetime__lt=requested_date + timedelta(days=1)
  )
  

  该写法直接走datetime字段的B树索引，无需额外计算，查询性能可提升5-10倍。
• 冗余存储日期字段：新增DateField类型的record_date字段，写入时直接存入对应日期值，给该字段加索引后直接用filter(record_date=requested_date)查询，性能最优，额外写入开销可忽略。
• 新增联合索引：如果业务中经常同时按空间范围+日期筛选，直接建(空间字段, datetime)的联合索引，PostGIS原生支持GIST类型的时空联合索引，可大幅降低扫描行数。
• 热点数据缓存：将高频查询的日期结果存入Redis，按数据更新频率设置过期时间，避免重复查库。

存储架构优化建议 #

• 首选存储组合为PostgreSQL + PostGIS，是当前开源生态对时空数据支持最成熟的方案，原生支持空间索引、空间算子，6000万级点位数据优化后查询延迟可控制在百毫秒以内。
• 按日期做表分区：将数据按天/月做范围分区，查询指定日期时仅扫描对应分区，无需遍历全表。Django 3.2及以上版本原生支持PostgreSQL分区表，业务代码改动极小。
• 时序场景优先选TimescaleDB：基于PostgreSQL开发的时序扩展，完全兼容PostGIS，自带自动分区、数据压缩、降采样能力，针对时序+空间的点位场景优化比原生PostgreSQL高3-5倍，6000万级数据查询可做到几十毫秒返回。
• 冷数据归档：超过业务高频访问周期的历史数据可压缩归档到离线存储，冷数据查询走异步任务返回，避免占用在线库资源。

内容的提问来源于stack exchange，提问作者Riverendell