站长请问使用sqlite3作为数据库 适合中小论坛吗
我也在做一个前后端分离的二次元小论坛 开始也是准备用sqlite的 后来搜索了一些文章都不推荐 sqlite 然后就选择了mysql+redis 发现我的小项目用这个有点大材小用了 看到你的这个项目后 有点想换到sqlite了 对了你的项目提供完整的api文档吗 想参考一下 因为我的api 感觉写的好乱啊 什么地方该写聚合api 都很懵 很多地方都用了 多接口查询 导致了 一个页面需要用到很多接口来查询 第一次写论坛 感觉到处都是坑啊 一边学一边学的状态
还有一点，目前不止业务表我存到sqlite，目前网站上传的文件也存到了sqlite (为了方便迁移)，不过是分成两个sqlite 存的。
项目源码在 https://github.com/leancodebox/GooseForum
我目前机器压测状态下，cpu是跑不满的，带宽是瓶颈。目前带宽跑满的时候cpu才用了10%多一点，所以sqlite3是没有问题的，尤其是我用的还是 go-pure 版本的 sqlit ,比纯c的会性能略逊一筹。
其次针对查询，这边是做了两方面
1、sqlite是开启wal的，这个配置会增加并发写入能力。不过需要注意关闭程序的时候要记得刷入。
2、是做好数据处理时间换空间。量极小的数据可以做内存缓存，比如分类/类别/友情链接之类的。
一些需要统计的数据做好冗余字段，不用每次都计算。 还有一些计算严重的东西的可以直接存入db，比如详情页我这边是服务端存储量markdown解析后的内容，文章发布后直接存储解析内容，这样详情页直接插入就行了，不用做大量运算。
我认为合理的表设计，sqlite不会成为站点的瓶颈。
其次是做好备份。
我的网站是由一个定时任务每天3点都会把sqlite生成备份文件。
评论数之类的少量地方是mock的数据。目前mock的数据应该只有首页hero右侧内容和文章详情页的数量。还有一些比较深的地方使用的mock,占比已经很少。 基本都是真实数据。有一些地方加入了cache。后面会在保持性能的情况下优化这些数据