用火星应用商店 来 装 最省事

https://www.bilibili.com/video/BV1bRDGYpEoR/

@wxf666 硬盘的话 ， 基本只有存储，一般和应用在同一台 ecs 直接读取，没有流量，即使需要共享给其他服务器 可以走内网

@wxf666 目前的方案就是 采用 oss 存储章节内容， 遇到密集操作整本书的时候巨慢，单章的读写没什么问题，目的就是要生成一本新的书，所以边看边拆不现实，再说边看边拆，不好控制需要不断记录拆的位置然后要截断的位置，不如全本全局的拆。我们目前并没有压缩内容，读取内容更方便。


@niubee1 就是普通的 付费小说 平台，类似与阅文，点众这样的

其实可以搞成 oss 和磁盘共存 （某一项用做备份，需要密集操作 调磁盘，效率高，一般的章节读写 oss 磁盘都可以。

@biubiuF 目前是 第一次读整本书的时候存 redis 缓存， 后面的访问都是访问 redis ，但是 第一次也还是很慢

如果 一条一条的执行， 也会频繁调用数据库可能会执行 6 次查询
加上网络 io 。 子查询不一定会慢的，利用好子查询更有利于性能的提升。
当然 我所说的是适当的使用子查询更有利于性能的提升。

其实 是 一条 sql 包含了 4~5 个 子查询 那么 一次性执行完毕

@wxf666
@niubee1
是这样的 ， 比如 为了某种需求 ， 需要对整本书 做一些操作， 比如 拆章 ， 将之前 3000 字一章的 拆成 1500 字（甚至更少）左右 1 章 ， 那么就需要先将整本书读完， 然后在做操作， 如果是存 oss 那么读整本书的等待时间， 就很煎熬了。

@niubee1 收费，免费都有， 所以就按收费来 ， 免费的收费为 0 ，加密这个之前搞过不过算法也在 js 里 可以破解， 后面索性不加密了，哈哈
@winglight2016 是的 按章节 收费，也有按本收费 的，看大神回复的 很多都是 按整本 （适合免费小说的 方案 ，付费的确实 不适合。
oss 看起来确实不失为一个好的方案， 但应用下来， 在应对 密集操作 就是灾难， 网络 io 太大，请求一整本书的时候会很慢， 不得已需要将书存到缓存来缓解这种缺点

@ytmsdy OSS 应对密集操作不友好，网络 IO 太高

oss 确实不失是一个好方法，但是在集中密集操作就暴露缺点了，如果我要读完整的一本书的内容， 网络开销太大了

还有就是如果是免费小说那么静态化再加上 CDN 毫无压力， 可是如果是收费呢？

总结： 把磁盘和 oss 的优点集中起来， 既存 oss 又存磁盘， 有没有就好很多 ……^_^

不存数据库的话全文检索又是一个问题。

oss 对于密集操作，很不友好，网络 IO 开销太大了

@Kinnice 暂时没有分布式要求
@dynastysea 磁盘只要存 章节内容就行了， 章节的元数据存数据库

@MoYi123 用磁盘主要是 方便 和 性能的考虑
@shadowyue oss 其实成本应该比磁盘贵

@13240284671 书少确实存数据库， 但是海量的书存数据库就不合适宜了， 主要是数据库的存储太贵了

来分析下 如果没有用子查询 或者 连接查询 join
某些情况 join 比子查询可能效率更高
select uid,

(select wechat from member_a where tuid=m.tuid)wechat,

(select name from admin_user where id =(select opuid from link where id=ldid))fzr

,no,ctime,

(select ctime from member where id=uid)uctime,

ldid,adid,rmb,

(select count(id) from money_o where uid=m.uid and ctime < m.ctime)readin,

(select count(id) from money_o where uid=m.uid and ctime > m.ctime)readout

from money m where

ldid in(select id from link where qd=666 and ctime>$tms) and status=1 and ctime>=$czs having ctime> uctime and (ctime-uctime<480);

如果采用 程序 来集合数据那么可能组要查询 4 次左右 再把数据组合 效率上是否没有一次查询高？

@cccvno1 如果就按程序逻辑来组合数据其实也是一样的，如果其中一个子查询有异常 修复这个异常就好了
@encounter2017 确实某些场景下 子查询或者 join 可能会更高效
@sagaxu 同意，复杂的需求 往往在管理后台。
@ldx78203199 sql 也可以写注释的
@liangdi 某些人可能连视图也不会让你用， 因为也隐藏了一些逻辑，降低了可读性。
@WashFreshFresh 子查询 和 分开查 SQL 并不少

zed 现在还不够稳定，
运行一段时间后 代码提示，错误提示，跳转到定义等功能会突然失效
然后日志也很大