缓存、索引与数据结构的工程选择

摘要

工程中，算法不只是"选一个复杂度更低的数据结构"：还要看查询类型、更新频率、内存成本、结果是否会过期以及能否保持一致。本文用商品目录演示三种常见选择：用字典加速 SKU 精确查询，用有序索引加速价格区间查询，用有界缓存复用重复查询结果，并通过可运行代码观察更新与缓存失效的关系。

一、背景与问题

一个商品列表用循环查 SKU，数据量小时完全够用；当每个请求都要扫描数万条记录，查找成本就随数据量增长。换成字典后，精确查找通常很快，但它不擅长按价格范围取出一段有序数据。若重复计算热门区间，可以缓存结果；但商品更新后缓存没失效，就会把旧结果继续返回。

因此，不能只问"哪个结构最快"，还要先问：要做精确查询、范围查询、排序还是频繁更新？数据量有多大？是否允许缓存？更新后如何保持索引和缓存一致？

二、核心概念

需求	常见结构	查询特征	主要代价
按唯一键精确查找	`dict` / 哈希索引	平均 O(1)	占用额外内存；更新需同步索引
判断键是否存在	`set` / 哈希索引	平均 O(1)	不保留值映射；额外内存
按有序数值查范围	排序数组 + 二分	O(log n + k)	插入维护通常 O(n)
复用重复计算	有界缓存	命中时避免重复计算	占内存，必须定义失效策略
任意顺序全量扫描	`list`	O(n)	不额外建索引，数据小时简单直接

k 是范围查询实际返回的项目数。哈希结构的 O(1) 是常见情况下的平均复杂度，不代表任意输入下无条件恒定耗时；排序索引擅长范围检索，但写入并不免费。缓存不是权威数据，只是可丢弃的加速层。

三、工作原理

text 复制代码

SKU 精确查询：SKU → dict 哈希定位 → 商品记录

价格范围查询：有序 (价格, SKU) 索引
                  ↓ 二分找到左右边界
               只扫描命中的 k 项

重复范围查询：查询参数 → 有界缓存
                    ├─ 命中：返回已有结果
                    └─ 未命中：二分检索 → 保存结果

商品更新：重建索引 + 更新版本 + 清除缓存

Python 的 bisect 可在有序序列上查找插入位置，但向列表中插入元素仍需移动后续元素；用它做大量在线写入并不等同于 O(log n) 更新。functools.lru_cache 会缓存函数调用结果，maxsize 可以限制缓存条目数；缓存函数应尽量是相同输入得到相同输出的纯计算。

四、实战示例

下面保存为 catalog_index.py，只使用 Python 标准库。SKU 唯一，价格以整数分保存；价格索引以 (价格, SKU) 排序，因此相同价格的商品也有稳定顺序。

python 复制代码

from bisect import bisect_left
from functools import lru_cache


PRODUCTS = [
    ("A001", 1200),
    ("A002", 2500),
    ("A003", 1200),
    ("A004", 800),
    ("A005", 3200),
    ("A006", 2500),
]
CATALOG_VERSION = 0


def build_indexes(rows):
    by_sku = {sku: price_cents for sku, price_cents in rows}
    if len(by_sku) != len(rows):
        raise ValueError("SKU 必须唯一")
    if any(type(price) is not int or price < 0 for _, price in rows):
        raise ValueError("价格必须是非负整数分")
    price_index = tuple(sorted((price, sku) for sku, price in rows))
    return by_sku, price_index


BY_SKU, PRICE_INDEX = build_indexes(PRODUCTS)


def find_sku_linear(rows, target_sku):
    for sku, price_cents in rows:
        if sku == target_sku:
            return price_cents
    return None


def find_sku_indexed(by_sku, target_sku):
    return by_sku.get(target_sku)


def find_price_range(price_index, minimum, maximum):
    if minimum > maximum:
        return ()
    left = bisect_left(price_index, (minimum, ""))
    # 价格是整数分，maximum + 1 可作为闭区间右边界。
    right = bisect_left(price_index, (maximum + 1, ""))
    return tuple(sku for _, sku in price_index[left:right])


@lru_cache(maxsize=128)
def cached_price_range(version, minimum, maximum):
    # version 属于缓存键；索引更新时清缓存并递增版本。
    return find_price_range(PRICE_INDEX, minimum, maximum)


def replace_catalog(rows):
    global PRODUCTS, BY_SKU, PRICE_INDEX, CATALOG_VERSION
    new_by_sku, new_price_index = build_indexes(rows)
    PRODUCTS = list(rows)
    BY_SKU = new_by_sku
    PRICE_INDEX = new_price_index
    CATALOG_VERSION += 1
    cached_price_range.cache_clear()


assert find_sku_linear(PRODUCTS, "A002") == 2500
assert find_sku_indexed(BY_SKU, "A002") == 2500
assert find_sku_indexed(BY_SKU, "MISSING") is None
assert find_price_range(PRICE_INDEX, 1200, 2500) == (
    "A001", "A003", "A002", "A006"
)
assert find_price_range(PRICE_INDEX, 4000, 5000) == ()

first = cached_price_range(CATALOG_VERSION, 1200, 2500)
second = cached_price_range(CATALOG_VERSION, 1200, 2500)
assert first == second
assert cached_price_range.cache_info().hits == 1

replace_catalog(PRODUCTS + [("A007", 2100)])
updated = cached_price_range(CATALOG_VERSION, 1200, 2500)
assert "A007" in updated
assert cached_price_range.cache_info().misses == 1

print("SKU 索引、价格范围、缓存命中和更新失效验证通过")

运行：

text 复制代码

python catalog_index.py

精确查找对照了线性扫描与字典索引；区间查询测试了相同价格、闭区间边界和空结果；缓存重复调用会命中，目录更新后清理缓存并返回包含新商品的结果。实际写入系统时，索引重建与版本更新应在同一个受控发布流程中完成。

五、常见问题与实践建议

1. 字典查找不是排序索引

字典适合根据唯一键找一条记录，不适合直接回答"价格在 1200 到 2500 分之间的商品"。面对多个查询维度，可以按访问模式建立多个索引，但每增加一个索引都要承担内存和更新成本。

2. 有序列表更新为什么不是 O(log n)

二分能在 O(log n) 时间找到插入点，但 Python 列表要为新元素腾位置，移动元素的成本是 O(n)。批量导入时先排序通常更合适；读多写少适合静态有序索引，写入频繁则应考虑数据库 B-tree、树结构或分批重建。

3. 缓存何时失效

失效策略取决于数据变化方式：可以按版本号、TTL、显式清理或写入时主动更新。对权限、价格和库存等关键数据，必须优先保证正确性；缓存不应成为唯一数据来源。

4. 缓存是否一定更快

缓存有查找、存储与失效成本。只有计算成本较高、输入重复率足够、结果体积可控时收益才明显。用 cache_info() 观察命中率和当前条目数，再决定是否保留。

5. 缓存无界增长

长期服务不要轻率使用无界缓存。lru_cache(maxsize=128) 限制了条目数，但每个结果可能大小不同；若结果很大，还要评估总内存，并提供监控和清理手段。

六、进阶思考

从内存结构迁移到数据库索引。 当目录需要多人并发更新、持久化或跨进程查询时，内存字典无法提供事务与一致性。数据库索引能持久化并支持范围查询，但写入、索引维护、磁盘空间和查询计划也会产生成本。应根据真实查询条件建立索引，并用数据库执行计划验证，而不是给每个字段都加索引。

考虑读写比例与构建成本。 如果每次进程启动都要从百万行文件重建多个索引，查询虽快，启动成本可能成为新瓶颈。可持久化预计算结果、按分区构建，或迁移到能管理索引生命周期的数据存储。

定义一致性边界。 目录更新若同时影响 SKU 索引、价格索引和查询缓存，应把它们当成一个版本整体切换。并发环境可以构建新的不可变快照，再原子替换当前快照引用，避免请求看到一半新、一半旧的状态。

结论

工程中选择数据结构，应从查询与更新模式出发：精确键查找优先考虑哈希结构，范围查询考虑有序索引，重复且昂贵的纯计算才考虑有界缓存。最终方案还要验证内存、更新成本、失效逻辑和数据一致性。下一篇将把这些结构组合到一个任务调度与路径分析综合项目中。

缓存、索引与数据结构的工程选择