shendaowu

不知道是不是一个问题。我用的是 VMWare ，虚拟机和宿主机都是 Win 11 。今天虚拟机里突然无法联网了。重启一下宿主机的 VMware NAT Service 服务就好了。

@Ketteiron #9

我之前还真尝试看过 danbooru 的代码。不过我放弃了，看不懂 Ruby ，尝试让 GitHub Copilot 给我找标签搜索相关的代码好像也不太对劲。ehentai 对搜索的标签数量有很大的限制吧？我希望搜索就算不到 100 个最少也得 50 个比较好，而且还是全 OR 连接的比较多。再加上单个内容最大三万标签，我怕这个组合会出现非线性的资源需求增长，就是横纵扩展服务器都难以解决。那样的话初期用户很开心，并且用习惯了的话，后期数据量大了用户变得失望我感觉我的站就会烂掉了。

在这种事上我不太敢乐观，毕竟我没见过类似像我这么用的，而且如果最终出岔子了，我的整个站都可能会出问题。所谓的如果失败的损失很大就悲观，如果失败的损失不大就乐观。公开下载数据这种大杀器我还是不太想用。就算我基本不想赚钱，这招也会有其他的坏处。

ehentai 开源吗？我没搜到。或者有点大致的实现思路的也行，这个我也没搜到。

我之前对 deepseek 的回答一般都是比较怀疑的，不过我以后还是听你的减少问这种设计方面的技术问题吧。但是类似找轮子之类的问题我还是比较信任 deepseek 的，它都不知道的话我自己基本就不会找了。

@Ketteiron #6

大佬如果你愿意回复的话别回复我 7 楼问的那些问题了。我又改变主意了。我想目前只关注传统的（内容 id ，标签 id ）的实现方式了。更高效的搜索以后再说。因我我发现 deepseek 说 intarray 实现的标签系统也不支持频繁的写入。然后我前面说的后期没多少时间也许可以通过敏捷开发解决一点。实在不行我还有大杀器，公开下载数据，允许用户本地给自己搜索或者帮别人搜索。我基本没有靠这个赚钱的想法，所以应该有更多的应对方法。

我现在主要想知道为了高效实现复杂标签查询，有哪些可以 tradeoff 掉的特性？我问过 deepseek 了，它给了一些东西： https://chat.deepseek.com/share/0nxwlfnzszgo9ps8va 。不知道大佬有没有什么补充的？或者能不能给个比较好的 tradeoff 方案？如果不能的话，我就只能各种方案同时测试试出比较好的方案了。我目前比较看好的是 pg_roaringbitmap 放到从服务器上，然后从服务器可写，deepseek 说从服务器可以写。然后每天夜里自动将前一天更新的（内容 id ，标签 id ）内容批量写入到一个带 roaringbitmap 的表里。deepseek 说可以。

@Ketteiron #6

大佬不想回就不用会了，一直白嫖你的回复挺不好意思的。

大佬你把我 san 值搞低了。因此我基本决定将来把这东西搞到一个单独的服务器里跟其他实验性的功能坐一桌了。我计划主服务器只放置一些核心、稳定的功能。实验性的服务器放置一些非核心、不稳定的功能，并进行名声最不好的那种敏捷开发。

我的需求复杂读确实多，写应该也不少。但是我刚才测试 update 只有五毫秒，这应该不算高吧？ 3333 行，每行的 roaringbitmap 三万元素。元素代表的标签一共 4500 种。deepseek 说一到十秒都正常，我没搜到多少正常。我懒得自己测试所谓的正常更新时间，感觉变数太多。

我没用 intarray 插件，就是普通的 integer[] 类型加个 GIN 索引。我先去测试 intarray 插件的性能了。另外看你的回复我隐约觉得 intarray 只擅长查询全部包含一系列标签的内容。我会测试这个。我之前别的测试完全没测试这个，看来大概率要全重测一遍。

另外附上我计划的一种查询（ AI 生成的）：

WITH target_tags AS (
SELECT tag_bitmap FROM content_tag_bitmaps WHERE content_id = 123 -- 这个忘了让 AI 限制搜索的元素的个数了，不过我记得好像加不加限制速度都差不多。
)
SELECT
content_id,
rb_cardinality(rb_and(tag_bitmap, (SELECT tag_bitmap FROM target_tags))) AS common_tag_count
FROM
content_tag_bitmaps
WHERE
content_id != 123
AND rb_and_cardinality(tag_bitmap, (SELECT tag_bitmap FROM target_tags)) > 0
ORDER BY
common_tag_count DESC
LIMIT 10;

@Ketteiron #1 我问过 deepseek 了，它说 content_tag_bitmaps 不用索引全表扫描也会比（标签 id ，内容 id ）复合索引快。确实快了，某种数据分布只有二十分之一。不同的数据分布指每个内容的标签量，内容量和独立标签量。内容数量和每个内容的标签量的乘积是固定的，独立标签量是内容最大标签量的 1.5 倍。某种数据分布（标签 id ，内容 id ）复合索引 11 秒多，pg_roaringbitmap 598 毫秒。不过我才反应过来这个优势好像没什么用？是我不想用的数据分布。我想用的数据分布 pg_roaringbitmap 好像还比符合索引慢点？我这坑爹的脑子之前怎么没发现这个问题？我用了它给的同时用两个表的 SQL ，还没有单独用一个表的快。不过可能是标签分布的原因。我测试的数据是所有标签的使用率应该都是二分之三。我还要进行很多无聊的性能测试。再次感谢吧，如果没有你的质疑我可能会很晚才发现问题。