基于SQLite如何设计应用程序，拆散，散，还的散！

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

非常感谢大家的支持，关注SQLite的人非常多，让我真的没有想到，公司的需求和大家的支持，让我有了更多工作的动力。今天我们来说说深入的部分就是SQLite开发需要注意什么，基于SQLite上的开发需要注意什么。

首先我们需要确认一个事情，SQLite服务的场景，数据库应对不同的场景，选错场景将直接让你的应用和数据库都成为互相怒视的彼此。

那么SQLite适合什么情况的开发或者业务

1 SQLite适合多种操作系统下部署的业务，比如IOS,Android,Linux ,Windows,甚至是一些国产操作系统。所以他的适应面非常广，为什么我们抛弃了PostgreSQL,也是这个原因，在不同的操作系统上PostgreSQL表现方式和安装的难易程度都相对SQLite "不可控"。

2 针对SQLite 我们并不能完全把他当成一个数据库库，或者传统数据库使用，SQLite是一个临时存储数据，或者面对个人操作，或者非高并发的应用环境来进行数据写入的数据库系统。

3从程序的设计理念上，针对SQLite的应用我们要有更多的注意，以及设计上思路的转变。

1 多读单写，让应用程序设计抛弃一个库承载数据的
基于PostgreSQL 基于SQLite

上图就是使用SQLite 和 PG在终端应用程序设计的不同点，使用PostgreSQL 会让应用程序设计的更加的简单，PG本身是支持高并发的数据库产品，读写高并发，在线下终端使用，那是完全够用一库能顶住。

而如果更换为sqLite，那么情况就变化了，你可以返现整体的设计中，一个应用逻辑一个实例，甚至有的原来应用要进行拆分，对于需要并发写的应用，针对表可能还要拆分，把他们放到不同的SQLite的实例中，因为SQLite 不是表锁，是库锁，也就是只要你表里面有一个表进行数据的写入，必然就加文件锁，加完后，你的其他表也不能写入数据。

下面就进入到这个程序设计的重点：

SQLite 的锁是数据库文件级别的。只要在一个表上发生写入 ------ 整个数据库文件都会进入 RESERVED/EXCLUSIVE 锁状态，其他写入就只能排队。

如果真正需要并发的情况

1 原来放在一张表里的数据，现在可能要拆成多张表、多库文件才能提高并发

2 原来一个进程可以处理的业务，现在要拆成多个进程/微服务式的小模块

3 原来 PostgreSQL 一个库足以支撑完整业务的数据模型，现在 SQLite 下可能要拆分成 N 个 SQLite 文件实例，才能保证业务在高峰时不会出现"写锁卡死所有人"的情况。

使用SQLite 的应用程序在设计中，必须考虑并发写的问题，如果不考虑会导致，即使非常短的写操作之间也会互相阻塞，用户界面会出现卡顿，无响应，一些之前没有延迟的数据显示，可能会有延迟的可能性。

然后开发如何，进行拆库，拆表，拆字段的，在非常熟悉业务的情况下，如何控制并发的，基于此的开发方式就要提升技能了。

问题	原因	SQLite 常见解决方式
写入卡顿、界面阻塞	文件锁	分库拆文件、异步写
数据热点表冲突	写锁竞争	拆业务模块
日志与主数据打架	共享文件锁	日志单独 SQLite
并发量大时延迟上升	单写者模型	写入队列化
跨模块引用关系复杂	多库拆分	业务层做"多库管理器"

所以考虑到这里，没有十全十美的数据库，只有适合业务场景的数据库的产品。PG单机市场和终端市场中的问题，主要在于运维，因为个人的终端是不会给你vacuum的时间，做大库备份的时间，那些终端说关机就关机，没有人会考虑你，突发断电和关机时的数据丢失的问题，以及开机数据回滚需要的时间，所以这也是为什么此次移动端抛弃了使用这么多年的PostgreSQL的根本原因，简单，能在简单，是终端对数据库的一个要求，下期我们来说说SQLite中的表设计的问题。

顺便说一句，SQLite 默认可不是并发读，单线程写，默认是单线程读，单线程写，具体如何配置看上一篇里面的配置信息。