V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wuhao1  ›  全部回复第 1 页 / 共 7 页
回复总数  128
1  2  3  4  5  6  7  
代理商朋友们, 有 比 阿里 99 续费 99 更好(更具有性价比)的 吗
阿里 这个还不限制 流量
目前看了大部分 可能价格更便宜,但是都只有 1 年,然后还有流量限制(可能自己的小破站也达不到限制的量
看了一圈, 很多都是 1 年的 ,意味着可能 1 年后又要搬家 ^_^
还有就是带宽小还有流量限制
阿里 续费同价的 那款,带宽小也不限制流量
如果没有更划算的还是 倾向阿里 99 的
15 天前
回复了 falser101 创建的主题 Linux Linux 微信 4.0 来了!牛逼
用火星应用商店 来 装 最省事

https://www.bilibili.com/video/BV1bRDGYpEoR/
@wxf666 硬盘的话 , 基本只有存储,一般和应用在同一台 ecs 直接读取,没有流量,即使需要共享给其他服务器 可以走内网
@wxf666 目前的方案就是 采用 oss 存储章节内容, 遇到密集操作整本书的时候巨慢,单章的读写没什么问题,目的就是要生成一本新的书,所以边看边拆不现实,再说边看边拆,不好控制需要不断记录拆的位置然后要截断的位置,不如全本全局的拆。我们目前并没有压缩内容,读取内容更方便。


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

其实可以搞成 oss 和磁盘共存 (某一项用做备份,需要密集操作 调磁盘,效率高,一般的章节读写 oss 磁盘都可以。
@biubiuF 目前是 第一次读整本书的时候存 redis 缓存, 后面的访问都是访问 redis ,但是 第一次也还是很慢
44 天前
回复了 wuhao1 创建的主题 MySQL 老生常谈 关于 子查询的应用
如果 一条一条的执行, 也会频繁调用数据库可能会执行 6 次查询
加上网络 io 。 子查询不一定会慢的,利用好子查询更有利于性能的提升。
当然 我所说的是适当的使用子查询更有利于性能的提升。
44 天前
回复了 wuhao1 创建的主题 MySQL 老生常谈 关于 子查询的应用
其实 是 一条 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 书少确实存数据库, 但是海量的书存数据库就不合适宜了, 主要是数据库的存储太贵了
59 天前
回复了 wuhao1 创建的主题 MySQL 老生常谈 关于 子查询的应用
来分析下 如果没有用子查询 或者 连接查询 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 并不少
71 天前
回复了 ggp1ot2 创建的主题 程序员 mac 上 sublime 公司不让用,有啥替代品?
zed 现在还不够稳定,
运行一段时间后 代码提示,错误提示,跳转到定义等功能会突然失效
然后日志也很大
如果 买 epson 的话 这个可能用的着 https://opensoft.pw/archives/312/
然后无线打印的方案是买了个 30 块的网心云,刷成 armbian 安装上驱动 打印机 插 网心云 usb
目前稳定运行
1  2  3  4  5  6  7  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3151 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 12:21 · PVG 20:21 · LAX 04:21 · JFK 07:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.