@上善若水,感谢回复。我去看了下:
RaptorDB:需要 .NET 环境,只能 C# 等编程使用?
TinyDB:只能 Python 编程使用?而且直接读写 Json 文件,怕是更新、追加数据都很慢噢。。
前两个参考链接无效。
第三个参考链接是 LiteDB,但决定不考虑这个了。
给的 11 种数据库里,好像只有一个是小型的,且是上面提过的 RaptorDB,但决定不考虑这个了。
第五个参考链接是 MongoDB,但决定不考虑这个了。
@希望自己长胖胖,会不会搞得老虎不好意思升级网站样式了
@森森,那个知乎回答里,大佬有打包好的完整 PyQT5 环境
可下载后,逐一尝试裁剪某些模块。最精简时,只需 14MB。
@森森,我看原文,好像不是很复杂?(如果只是减少体积)
主要就是试试,哪些 dll 能被删掉,要花几分钟?
@森森,120 MB。。是不是有点大了
@㝶芾厶眵攴䭡,Emm。。是没考虑到。
仔细想想,这部分占用的服务器资源应该不大?
因为最繁重的汇集各处来源信息,以及构造维护消息队列,已经完成了,充其量只是再多分发几次?
直播弹幕、音视频流等,分发给全国观众都不成问题。这点文本分发,相信也不会太为难腾讯的服务器?
@老虎会游泳,让我理理:
- QQ群聊:用户发消息 -> 最近服务器 -> 群所属中继服务器 -> 其他所有成员所在服务器 -> 其他成员接收
- 直播弹幕:用户发弹幕 -> 最近服务器(可能随机丢弃) -> 直播间所属弹幕服务器(只需处理一次,可裁剪弹幕) -> CDN -> 观众
所以,QQ群聊的每一条消息,服务器都要针对每个成员单独处理,无法重用。
如果一个人平均会加入 X 个群,平均每个群有 Y 个成员,平均每人每天发 Z 条消息,则一天消耗 用户数XY*Z 次服务器资源。
要节省服务器开支,则 X、Y、Z 都要限制?
而直播弹幕,对于某一个直播间,服务器可收集用户发送的全部/部分弹幕,并裁剪成如每秒最多 1000 条弹幕,再分发?
即,可针对所有观众统一处理弹幕,重用性贼高?
@老虎会游泳,那个收弹幕的中心服务器,性能一定很强吧,要接收全国这么多用户的弹幕。。
说来也是,直播的数据量比聊天、弹幕大多了,基本也都全送达了
直播弹幕嵌在视频里,这想法挺新奇啊。
就是设置 全屏/半屏/四分之一屏弹幕、弹幕关键字屏蔽 等功能会不会不方便了。。
@老虎会游泳,不是发一个弹幕,就要转发给其他 几十成百上千万用户 咩。。
@老虎会游泳,那直播弹幕那种呢?几十成百上千万用户直播间那种。。
@希望自己长胖胖,我是真人呀,不是机器人,是不是 @ 错了。。
@老虎会游泳,我记得 GPT4 发布会上就演示过这个功能了。只是不知道 GPT4 用户现在可以用了没
@老虎会游泳,现在 GPT4 支持,识别一个前端设计草稿图,生成整个前端工程代码,了吗?
喊 GPT 帮写试试?
@HongKongDoll,也就是说,这个小鸡的内存读写都会非常慢?
程序以为自己在读写内存,实际上是在读写硬盘?
根据其中一个脚本说 ,一台2g美国服务器,不考虑宽带比较垃圾点应该也20左右一个月,年付200吧
保守点应该开6g虚拟内存,一共8g了
8g 可以开100台 75m内存左右mini NAT小鸡,一台卖3.5, 100*3.5=350
@零玖,现在 bug 还在么