王小美 @[email protected]

考虑再加一个clickhouse来记一下错误日志

感觉cached里面的数据其实完全不用迁移也行？至少media_attachments是这样

开了50个concurrency，服务器就卡死了
几千万个文件有点头疼啊

现在写Python有种写JavaScript的感觉，没有严格类型规范感觉很不习惯，真离不开ts🫣

笑死了

https://cr-ss-service.azurewebsites.net/api/ScreenShot?widget=summary&username=mashirozx

开源～Mastodon S3文件同步程序，基于数据库里面的记录同步文件，不用遍历对象储存，保护你的👛，还可以顺便清理数据库中已经没有记录的失效文件（Mastodon在一两年前加入了一个cache文件夹、一年前加了一个storage policy version，产生了一些失效但未删除的文件）

https://github.com/mashirozx/mastodon-s3-sync-tool

诶，勉强跑起来了

分享动态
//转发自: @半夜吃甜筒: toto观察红牛赛车被霍纳发现
-

https://t.bilibili.com/780585000307261440

早上为什么要闲得没事用Python，根本不会

Python的多线程怎么这么麻烦

要是Python的dict能像js那样用 . 调就舒服了…

脚本写好了，等下加个多线程，这几天就开始迁移了

所以这是本站第一张图片（activity record id上来说

mastodon（或者说gem paperclip）一个恶心的地方是储存媒体文件时要把activity record id拆分成了一大串子目录：如图1的文件，其原本的id是104530971904218116，最后被拆成了104/530/971/904/218/116 （：id_partition部分）

我想不出这样设计有什么意义，但是最终的结果是list对象储存时会产生大量性格最贵的C类请求。misskey是将所有文件储存在根目录，list n个文件产生n次C类请求，这是最理想的情况，但是同样的n个文件mastodon要产生n*(6+2)次C类请求，+2是因为104/530/971/904/218/116 下面还有original和small两个子文件夹。

打算趁这次重构的机会把这个地方改一下，直接把所有内容写在文件名上不就行了：

':prefix_url:class/:attachment/:id_partition/:style/:filename' -> ':prefix_url:class/:attachment/:id-:style-:filename'

Python的异步写起来极不顺手啊

chat gpt这打字效果快把我眼睛闪瞎了