siyuan-note
重构数据结构，并使用 sqlite 进行查询
该提交主要完成下面的工作：
- 重构了 cardsource、card 的结构
- 增加 history 和 reviewLog 结构，以满足撤回和导出复习历史的需要。
- 改为使用内存级sqlite进行 crud ，保存时导出为json。
- 目前已完成部分原有api，仍有一部分接口等待实现（另外感觉使用 sqlite 进行 CRUD 后一部分接口似乎不需要专门实现了？）
数据结构具体看代码，在 2万 cardSource 、10万 card 的性能如下所示：
其中
task init card and cardsource use time :29.8242217s
是测试生成待插入卡片的耗时。总体而言，我觉得足以满足闪卡系统的使用需求。
请 @88250 看一下这样做是否可以接受。
另外， 为了快速开发，使用了 modernc.org/sqlite （无cgo，提高打包速度）和 xorm.io/xorm （辅助CRUD），如果可行，可以替换回 kernel 使用的 github.com/mattn/go-sqlite3 并逐步去除 xorm的使用。
我更改了review的接口，使得它跟旧版更为相似。缺点是：
- reiview会使用更长时间。
- 撤回并重新复习的设计会更复杂一点。
不过我觉得批量复习的场景还是少见的，10万张卡片总用时16秒，相当于每张卡片0.16毫秒，性能再差几倍也不是太大问题。
之前的测试：
现在的测试：
当前的接口：
Review(cardID string, rating Rating)
当前版本增加了缓存，极大提升了查询性能和一般情况下的保存性能，可以在在600ms内返回10万卡片量级的结果。借用缓存也提升了 review 的性能，使其达到 api 修改前的速度。
@88250 测试dejavu的时候尝试了下跟sqlite的兼容性，发现情况如下：
在使用sqlite.db储存时，在写入的情况下，开启wal模式后，只要不读shm、wal就没多大问题。journal比较麻烦一点，写入太快了，在持续写入情况下，建立了快照后文件就更新了。在读的情况下，都没啥问题。所以sqlite作为储存方式对于dejavu是可行的，只不过最好在写入的时候获取filelock的锁。
