WMS系统中计算值应存入数据库还是实时计算？

核心结论 #

结合你年数据1200万条、读取极频繁、数据基本无修改的场景，优先选择预存计算值（打破部分范式是合理的空间换时间策略）。但可以分阶段优化，先尝试实时计算的数据库层优化方案，达不到性能要求再切换到预存模式。

一、实时计算的可行性与优化边界 #

直接在Python层逐行计算（比如拉取所有筛选后的记录循环计算利润）肯定不行，1200万级数据会导致内存溢出和超长响应时间，但如果把计算逻辑推到PostgreSQL层面，仍有一定优化空间：

• 用Django ORM的annotate/aggregate直接在数据库做计算和聚合，避免把全量数据拉到Python内存。比如：

  # 直接在数据库层面计算单条订单利润并聚合
  from django.db.models import F, Sum
  
  daily_profit = OrderItem.objects.filter(
      order_date__range=[start_date, end_date]
  ).annotate(
      profit=F('sell_price') - F('cost_price') - F('tax_amount')
  ).aggregate(total_profit=Sum('profit'))
  

• 针对报表常用的筛选维度（时间、产品类别、客户）建立联合索引，加速数据过滤。比如给order_date和product_id建联合索引：

  class OrderItem(models.Model):
      # ... 其他字段
      class Meta:
          indexes = [
              models.Index(fields=['order_date', 'product_id']),
          ]
  

• 用only()/defer()限制查询字段，减少数据传输量；复杂报表直接用原生SQL或RawSQL，避免ORM生成低效查询。

但实时计算的瓶颈很明显：当筛选后的数据量达到百万级，聚合计算的耗时会随数据量线性增长，多维度组合查询时延迟会超过用户可接受范围（比如>2s）。

二、预存计算值的优势与落地方案 #

因为你的数据基本不会修改，预存计算值能彻底解决读取性能问题，以下是几种落地方式：

1. PostgreSQL生成列（推荐） #

用PostgreSQL的存储型生成列，在数据库层面自动计算并存储值，写入时计算一次，读取直接取存储值，完全保证一致性：

-- 给order_item表新增存储型利润列
ALTER TABLE order_item 
ADD COLUMN profit NUMERIC(10,2) 
GENERATED ALWAYS AS (sell_price - cost_price - tax_amount) STORED;

Django模型中可以直接映射这个字段：

class OrderItem(models.Model):
    # ... 基础字段
    profit = models.DecimalField(max_digits=10, decimal_places=2, editable=False)

2. 预聚合物化视图 #

针对高频报表的聚合维度（比如按日/产品的营收、利润总和），建立物化视图预存聚合结果：

CREATE MATERIALIZED VIEW daily_product_sales AS
SELECT 
    DATE(order_date) AS sale_date,
    product_id,
    SUM(sell_price * quantity) AS total_revenue,
    SUM(profit * quantity) AS total_profit,
    SUM(tax_amount * quantity) AS total_tax
FROM order_item
GROUP BY DATE(order_date), product_id;

可以通过django-materialized-views库在Django中管理物化视图，或者手动写迁移创建。由于数据基本不修改，只需在初始数据导入或偶尔修改时刷新视图：

REFRESH MATERIALIZED VIEW daily_product_sales;

3. Django信号同步计算 #

如果数据存在少量修改可能，用post_save信号在数据创建/更新时自动计算并保存：

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=OrderItem)
def update_order_item_profit(sender, instance, created, **kwargs):
    if created or instance.sell_price != instance.__original_sell_price:
        instance.profit = instance.sell_price - instance.cost_price - instance.tax_amount
        instance.save(update_fields=['profit'])

（注：需要重写模型的__init__方法记录原始字段值，用于判断是否需要更新）

三、分阶段实施步骤 #

1. 第一阶段：实时计算优化
   用ORM的annotate/aggregate配合索引优化查询，测试核心报表的响应时间。如果能稳定在1s以内，可暂时维持此方案。
2. 第二阶段：引入生成列
   当实时计算延迟超标时，给单个记录的计算字段（如利润、单条营收）添加存储型生成列，降低单条记录的计算成本。
3. 第三阶段：预聚合物化视图
   针对高频聚合报表（如月度营收趋势、产品利润排行）建立物化视图，前端直接查询预聚合结果，实现毫秒级响应。

注意事项 #

• 存储成本：1200万条记录的计算字段（如Decimal类型）总存储量仅几十GB，PostgreSQL完全可以承受。
• 一致性：生成列和物化视图由数据库维护，无需担心数据不一致；信号方案需注意事务原子性。
• 维护成本：预存字段和物化视图需要在模型迁移时同步修改，增加少量维护工作，但换取的性能提升远大于维护成本。

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