chore: new article written

Author: github-actions[bot]

src/content/blog/2025-04-27/index.md

@@ -0,0 +1,88 @@
+---
+title: "SQLite3 数据库分片策略与实践"
+author: "杨其臻"
+date: "Apr 27, 2025"
+description: "SQLite3 数据库水平分片策略与实现方案"
+latex: true
+pdf: true
+---
+
+
+随着数据量的爆炸式增长，传统单机数据库面临 IO 吞吐量瓶颈和内存限制的双重挑战。数据库分片技术通过水平扩展将数据分布到多个节点，成为提升系统并发能力和容灾能力的关键手段。SQLite3 作为轻量级嵌入式数据库的代表，虽然在小规模场景中表现出色，但在处理海量数据时仍需引入分片机制突破单文件性能天花板。
+
+## SQLite3 分片基础
+
+SQLite3 采用单文件存储模式，其写操作通过 WAL（Write-Ahead Logging）机制实现并发控制。但单个文件的锁竞争会直接影响吞吐量——当并发写入请求超过文件 IO 上限时，事务延迟将呈指数级增长。例如在物联网场景中，十万级设备同时上报数据可能导致 SQLite3 的写入队列堆积。
+
+分片与复制的本质区别在于数据分布策略：复制侧重冗余备份，而分片追求数据分区。SQLite3 分片的典型场景包括多租户系统按租户隔离数据、时序数据库按时间窗口切分等。设计时需权衡数据均匀性与查询效率，避免跨分片操作过多导致性能退化。
+
+## 分片策略设计
+
+水平分片的核心在于选择合适的分片键。以用户系统为例，采用用户 ID 作为分片键时，可通过哈希函数 $shard\\_id = hash(user\\_id) \mod N$ 确定数据归属。其中模数 N 的取值需考虑未来扩容需求，通常建议使用二次哈希减少扩容时的数据迁移量。
+
+垂直分片适用于业务耦合度低的场景。例如电商系统可将订单表与商品表分离到不同数据库，通过事务日志保证跨库数据一致性。此时需在应用层维护分片映射关系：
+
+```python
+class ShardMapper:
+    def get_shard(self, table_name):
+        if table_name == 'orders':
+            return self.order_shards[hash(user_id) % 3]
+        elif table_name == 'products':
+            return self.product_shards[hash(product_id) % 2]
+```
+
+路由策略的实现方式直接影响系统复杂度。客户端直连方案需要每个应用实例缓存分片配置，而代理层方案可通过中间件统一管理。例如使用 Go 语言实现代理路由：
+
+```go
+func RouteQuery(query string) *sql.DB {
+    shardKey := extractShardKey(query)
+    hash := fnv.New32a()
+    hash.Write([]byte(shardKey))
+    return shards[hash.Sum32() % uint32(len(shards))]
+}
+```
+
+## 分片实践与挑战
+
+数据迁移是分片实施的关键阶段。采用双写策略可保证平滑过渡：在迁移期间同时写入新旧分片，通过后台任务逐步同步差异数据。以下 Python 示例展示了数据同步的核心逻辑：
+
+```python
+def migrate_data(old_db, new_shards):
+    for row in old_db.iter_rows():
+        shard = select_shard(row.id, new_shards)
+        try:
+            shard.insert(row)
+            old_db.mark_migrated(row.id)
+        except Exception as e:
+            logger.error(f"迁移失败 : {row.id}")
+```
+
+跨分片事务是 ACID 合规性的主要挑战。最终一致性模型通过补偿事务解决部分问题。例如订单支付场景，可先扣减库存再生成订单，失败时执行反向操作：
+
+```sql
+-- 跨分片事务伪代码
+BEGIN;
+UPDATE inventory_shard SET stock = stock - 1 WHERE product_id = 123;
+INSERT INTO order_shard VALUES (...);
+COMMIT;
+
+-- 失败时执行
+UPDATE inventory_shard SET stock = stock + 1 WHERE product_id = 123;
+```
+
+## 工具生态与优化
+
+开源工具 rqlite 基于 Raft 协议实现了 SQLite 的分布式版本，其分片逻辑通过节点组管理实现。在自定义分片框架中，可扩展 SQLite 的 VFS 层，将分片逻辑下沉到存储引擎：
+
+```c
+// VFS 分片实现示例
+static int shardOpen(sqlite3_vfs* vfs, const char* zName, sqlite3_file* file, int flags, int* outFlags){
+    char* shard_name = determine_shard(zName);
+    return original_vfs->xOpen(original_vfs, shard_name, file, flags, outFlags);
+}
+```
+
+预分片技术通过提前创建虚拟分片减少扩容扰动。例如初始化时创建 1024 个逻辑分片，实际只部署 4 个物理节点，每个节点托管 256 个逻辑分片。扩容时仅需迁移部分逻辑分片到新节点。
+
+
+SQLite3 分片在十万级 QPS 场景中表现优异，但当数据规模达到 PB 级时，仍需考虑 TiDB 等分布式数据库。未来随着 WebAssembly 技术的发展，SQLite3 有望在边缘计算场景中实现更细粒度的分片部署。开发者应根据业务特征选择分片策略，在扩展性与复杂度之间寻找最佳平衡点。