基于 ~~raft~~ 实现的高可用的 sqlite 数据库服务
- 通过 raft 实现 wal 拷贝性能与预期出入较大, 考虑通过其他方式实现高可用
  
  启用 vfs wal in memory 连续插入每秒约 12000
  
  启用 raft wal replication 连续插入每秒约 35
  
  启用 raft sql statement replication 连续插入每秒约 270
  
  以上结果在 apple m1 中执行
支持多节点多数据库创建与访问
支持事务操作、支持事务隔离
支持每个库单独回快照、回滚操作
支持 S3 协议作为持久层
多操作系统支持: linux、windows、mac
跨平台支持: x86、arm

进度

为什么需要再造一个数据库的轮子

契机

工作中现有的业务背景引发的思考，在重前端复杂业务场景(如:在线协作的原型设计工具figma)下，我可能需要一个轮子用于降低前后端对接成本、更容易的实现基于状态驱动、更容易实现多人协作

业务背景

一个类似三维数据管理的saas平台，任何人都能创建项目加入三维数据(点云、网格、全景、绘制)，经过对齐堆叠后放在地图上(可选)，这个过程与很多GIS相关的项目很像。然后进行一系列针对三维数据的编辑操作，数据裁剪/绘制仿真模型/创建标注热点/编辑故事版视图/编辑漫游路径/导出报表/渲染输出视频/作为大屏背景等一系列操作

我们已经实现了上述所有功能，基于 webgl + react 实现的状态驱动编辑器，但是在Web前端保留的状态太多了而且都需要跟后端频繁交互。

举个例子：一个标注点存在三个元素(ICON、文本、引线), 可修改属性达100+(引线颜色、高度、起始点位置、文本字体、文本大小、文本居中方式、文本区域背景、文本描边属性、ICON地址、ICON尺寸、是否需要开启遮挡、是否使用近大远小、启用避免文本ICON区域重叠等) 当然，一般情况下，大部分属性都是使用默认值并且不会发生变化，但是在产品设计上，依旧允许调整这么多的属性。在前端渲染的属性面板中，用户拖动活动条导致一个属性发生变化时，webgl 中渲染的内容需要同步发生变化，而且前端渲染的属性面板可能不止一个，是的，他们都要同步发生变化。（这个过程像blender这样的软件，一个大窗口内能创建多个小窗口，但是都是在维护同一个项目）现在我们基于一个自己实现的前端Store状态分发实现, 支持复杂的JSON树结构(中间可能嵌套多层数组)，能够校验到最小节点的变化事件然后应用至 webgl 中。麻烦的是，属性修改后，用户如果点击取消，需要回滚状态。但如果点击确定或者直接关闭，需要将变化的内容调用接口增量更新至后端。后端定义的数据结构通常是为了更好的存储，这往往与前端定义的结构不一致，前端需要筛选哪些属性发生变化并将他转换为后端的结构。

按照这个描述实现，会有几个显而易见的问题：

为了提高数据编辑的效率，同一个项目不同的人都打开进行操作，如果不小心操作了相同的数据，这是个灾难。
后端把数据分散的存放在各个表中，每个更新动作为真实更新，如果有错误操作想要回滚到某个历史版本或者基于历史版本创建一个新的项目会非常麻烦。关于第一点，你可能会很快会想到创建一个 websocket 链接，来推送其他用户更新的数据。这个过程比较像figma或者在线协作文档等与后端通讯的过程。后端把数据分散的存放在各个表中，现有的接口调用方式需要去监听一堆表数据的变化非常麻烦，而且实现快照回滚等功能也同样繁琐。

比较理想化的交互方式

前端已经需要维护一个 Store, 那如果我们把 Store 的实现调整为基于 Sqlite，后端实现调整为一个项目即为一个 Sqlite db。 sql.js 支持内存数据库及触发器能够监听到属性变化可用于前端 Store 底层实现，当监听到内容变化后自动同步至 webgl / 属性面板 / 后端后端部分单库作为文件存储，同样可快速实现快照等功能，并且支持以S3协议作为数据的持久层。数据结构通过 json schema 约束。