在离线优先、多端数据同步以及本地缓存加速等场景中，SQLite和DynamoDB分别承担着不同的职责。SQLite以文件形式嵌入应用，适合存储结构化数据并提供复杂查询；DynamoDB作为全托管的键值存储，擅长高可用、自动扩展和低延迟访问。把两者结合，本质是让本地关系型引擎与云端键值服务各司其职，而不是试图用其中一方替代另一方。
一个典型例子是移动记账应用：本地SQLite负责记录每一笔订单、客户和库存变化，保证断网时也能正常操作；当网络恢复后，应用只把发生变化的数据同步到DynamoDB，供其他设备或后台服务读取。这样既能避免每次操作都请求云端造成的延迟和流量开销，又能利用DynamoDB的弹性能力承接跨端共享和查询需求。
一、为什么要把SQLite和DynamoDB键值存储放在一起设计？
SQLite的优势在于本地事务、复杂SQL查询、无需网络连接以及零运维。对于桌面工具、移动应用或边缘设备，它可以提供毫秒级的数据访问，并且支持多表联合、聚合、排序等关系型操作。但SQLite本质上是一个单机文件数据库，无法原生解决多设备之间的数据共享和云端持久化问题，一旦设备丢失或文件损坏，数据可能无法恢复。
DynamoDB则刚好相反，它是一款全托管的键值存储服务，具备自动分片、跨可用区高可用、按需扩展和低延迟访问能力。但它的查询能力受限，尤其是复杂的关系型查询需要借助索引或额外设计，而且每次访问都会产生网络请求和费用。如果应用把所有读写都放在DynamoDB上，断网场景直接不可用，成本也会随请求量上升而快速增长。
把两者结合，相当于构建一个本地优先的混合存储架构：SQLite作为应用的主数据源，负责日常读写和复杂查询；DynamoDB作为同步目标，保存需要跨端共享或云端备份的数据。这种设计在IoT设备、移动端应用、桌面端工具以及边缘计算场景中非常实用，既能保证离线可用，又能控制云端成本。
二、数据模型映射：把关系表转成键值结构
SQLite的数据模型以表、行、列为基础，每张表通常有一个主键，列之间有明确的关系约束。DynamoDB则基于项目（Item）和属性（Attribute），每个项目必须包含一个唯一的分区键，可以额外定义排序键。一个常见的映射原则是：把SQLite表的主键直接作为DynamoDB项目的分区键，把需要按时间排序的更新戳作为排序键，把其他列打包成项目的普通属性。
以下是一个订单表的SQLite定义，以及对应的DynamoDB项目结构。需要注意的是，DynamoDB的数字类型需要以字符串形式传入或使用专用数值类型，这里为了展示清晰，将金额和更新时间统一用字符串或数字表示。
CREATE TABLE orders (
order_id TEXT PRIMARY KEY,
customer_id TEXT NOT NULL,
amount REAL NOT NULL,
status TEXT NOT NULL,
updated_at INTEGER NOT NULL
);
{
"order_id": {"S": "ORD-1001"},
"customer_id": {"S": "CUST-88"},
"amount": {"N": "129.5"},
"status": {"S": "paid"},
"updated_at": {"N": "1716019200"}
}
如果SQLite中存在多对多关联表，通常不建议在DynamoDB中原样保留关系。更合适的做法是进行扁平化处理，比如把关联关系冗余到主项目中，或者使用不同的分区键设计配合全局二级索引（GSI）来支持反向查询。这样虽然会牺牲一部分规范化，但换来了键值存储的高性能和可预测扩展性。
另一个重点是属性命名。DynamoDB的属性名会占用存储空间并影响读容量计算，因此在同步前可以对频繁使用的短字段保留原名，对长字段名进行缩写映射，同时在SQLite中维护一份映射表，避免同步后无法还原可读性。
三、增量同步与冲突处理策略
全量同步虽然实现简单，但每次都要扫描整张表并逐条写入DynamoDB，不仅耗时，还会产生大量不必要的读写容量消耗。更合理的方案是增量同步：在SQLite中为需要同步的表增加updated_at字段和deleted标记位，每次插入或更新时刷新该字段，每次删除时只打标记而不物理删除。同步任务只读取本地时间戳大于上次同步时间点的记录。
拉取远端变更同样可以使用增量方式。客户端记录一个last_sync时间戳，向DynamoDB查询updated_at大于该值的项目，再写入本地SQLite。查询时最好配合GSI，使用Query而不是Scan，避免全表扫描造成成本上升。同时要注意设备时钟可能不准，尽量使用服务端返回的时间作为同步锚点，或者使用NTP校准。
处理冲突时，如果业务可以接受最后写入者胜出（LWW），直接比较updated_at即可。如果数据一致性要求更高，可以引入版本号字段，在DynamoDB条件写入时校验版本号，失败则拉取最新数据进行合并。以下代码展示了本地更新后写入同步队列的基本逻辑。
import sqlite3
import time
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
def update_order_status(order_id, new_status):
now = int(time.time())
cursor.execute(
'UPDATE orders SET status = ?, updated_at = ? WHERE order_id = ?',
(new_status, now, order_id)
)
conn.commit()
# 把变更写入outbox表，供后续同步任务读取
cursor.execute(
'INSERT INTO sync_queue (item_id, table_name, updated_at) VALUES (?, ?, ?)',
(order_id, 'orders', now)
)
conn.commit()
这种outbox模式的好处是本地业务操作和同步记录在同一个SQLite事务内完成，能够保证数据变更不会丢失。后续同步任务只需要查询sync_queue中pushed等于0的记录，逐条推送到DynamoDB，成功后标记pushed为1。
四、代码实战：SQLite本地缓存与DynamoDB双向同步
下面使用Python和boto3实现一个简化的双向同步脚本。推送函数从sync_queue中读取未同步记录，根据表名到SQLite中查询最新数据，再调用DynamoDB的put_item写入远端。拉取函数则根据last_sync时间戳从DynamoDB获取增量项目，使用INSERT OR REPLACE更新到本地。
import boto3
import sqlite3
import time
from boto3.dynamodb.conditions import Attr
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('orders')
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
def push_local_changes():
rows = cursor.execute('SELECT * FROM sync_queue WHERE pushed = 0').fetchall()
for row in rows:
item_id, table_name, updated_at = row[0], row[1], row[2]
if table_name == 'orders':
order = cursor.execute(
'SELECT order_id, customer_id, amount, status, updated_at FROM orders WHERE order_id = ?',
(item_id,)
).fetchone()
if order is None:
continue
table.put_item(
Item={
'order_id': order[0],
'customer_id': order[1],
'amount': str(order[2]),
'status': order[3],
'updated_at': order[4]
}
)
cursor.execute('UPDATE sync_queue SET pushed = 1 WHERE item_id = ?', (item_id,))
conn.commit()
def pull_remote_changes(last_sync):
response = table.scan(
FilterExpression=Attr('updated_at').gt(last_sync)
)
items = response.get('Items', [])
for item in items:
cursor.execute(
'INSERT OR REPLACE INTO orders (order_id, customer_id, amount, status, updated_at) VALUES (?, ?, ?, ?, ?)',
(item['order_id'], item['customer_id'], float(item['amount']), item['status'], int(item['updated_at']))
)
conn.commit()
return int(time.time())
示例代码中为了保持简洁使用了scan，实际项目中如果订单表数据量大，应该为updated_at创建GSI，使用Query配合KeyConditionExpression来精确获取某个时间点之后的项目。这样既能减小响应体积，也能明显降低读取容量消耗。批量写入时可以使用DynamoDB的batch_writer接口，将多个put_item合并为一次批量请求。
另外，同步任务需要处理网络失败和部分写入成功的情况。建议在sync_queue中记录重试次数和最后错误信息，不要因为单条失败阻塞整个队列。对于DynamoDB写入返回的成功响应，要确认项目确实被持久化；如果返回未处理的项目列表，需要在下一次循环中重试。
五、成本控制与常见误区
DynamoDB的费用主要来自读写容量单元（RCU/WCU）、存储量和数据传出。频繁的全表Scan是成本失控的常见原因之一，因此同步逻辑必须优先使用Query和索引。批量写入虽然可以降低写容量消耗，但单次批量请求的项目总量不能超过16MB，单个项目不能超过400KB。如果SQLite中有大文本或二进制字段，应该考虑将内容放入对象存储，只在DynamoDB中保存引用和元数据。
另一个容易踩坑的地方是删除同步。如果本地执行物理删除后直接让远端也删除对应项目，一旦其他设备还保留旧数据，反向同步时又可能把已删除的记录拉回来。正确做法是使用逻辑删除，在SQLite中标记deleted等于1并同步该标记到DynamoDB，查询端过滤掉已标记项目，定期由后台任务统一清理。
时间同步也是需要特别注意的环节。使用本地设备时间作为updated_at来源，在设备时间不准或用户手动修改时钟的情况下，会造成增量同步遗漏或错误覆盖。建议在本地写入变更前，先向服务端获取可信时间，或者使用DynamoDB写入时由服务端自动填充的写入时间作为参考。冲突处理策略要提前确定，避免在数据已经不一致后再追加版本逻辑。
整体来看，SQLite与DynamoDB键值存储的配合并不是简单的数据搬运，而是需要在模型映射、同步策略、冲突处理和容量规划上做细致设计。只要把本地事务、outbox队列、增量拉取和批量写入这些点落实到位，就能用较低成本实现一个稳定可靠的混合存储方案。