充更多的钱好像有 8 小时的选项。我之前问正常问题在人少的时候置顶十分钟也有几个人回。我感觉那些推广的好像都是在人多的时候置顶比较多。周六周日人比较少。https://v2ex.ipen.ink/?r=2w 。着急的话去 nodeseek 试试？在 nodeseek 服务器相关的问题好像都可以讨论。另外你发的节点帖子太多了，不容易被订阅或者经常看某个节点的人看到。你那个帖子感觉放站长节点还算贴边。

不知道是不是一个问题。我用的是 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 ，还没有单独用一个表的快。不过可能是标签分布的原因。我测试的数据是所有标签的使用率应该都是二分之三。我还要进行很多无聊的性能测试。再次感谢吧，如果没有你的质疑我可能会很晚才发现问题。

@shendaowu #2 搜索时间达到（标签 id ，内容 id ）复合索引的二十分之一。不是速度。我怎么就管不住我这手呢？

@Ketteiron #1

我试过数组类型 + GIN 实现标签，效率跟（标签 id ，内容 id ）复合索引比效率好像没差多少。不知道是不是我没弄明白。或者你说的是用 jsonb ？

我也就现在时间多点，后期我就没多少时间开发网站了。后期我要搞钱养活自己，每天不会分出多少时间维护网站。所以我想让网站抗造一点。

@Ketteiron #1 我才发现我好像是轻信 deepseek 了，它给我的 SQL 代码里根本就没用 tag_content_bitmaps 。它给我解释说它用那个 tag_content_bitmaps 做索引我就信了，没细看。不过没索引查询速度也能达到（标签 id ，内容 id ）复合索引的二十分之一我也是醉了。这个时间的降低好像更麻痹我了。我再去拷问一下 deepseek 。感谢大佬。

@CEBBCAT #5

白皮书太高大上了，我感觉我写不出来。我看过一些白皮书。

但是我确实写过一些半系统的介绍我的点子的东西。有兴趣点我本站 ID 到我的 GitHub 首页上看我的那个 Pinned 的项目。我怕站长会自动统计每个用户经常发的链接，然后自动屏蔽那些链接甚至降权封号。我记得我好像发过几次了。

另外过了这么长时间我的很多构想都变了。GitHub 上的介绍有点过时了。我简单提几个。最重要的就是我目前基本确定要提高最大标签数限制了。因为 pg_roaringbitmap 的效果好像不错，不过我还不放心，还需要继续测试一下。然后就是推荐一系列相关的推荐的时候不会一点一点挤牙膏了，会一下子全推荐过去。前者实现起来太费劲，我可能是受推荐系统的影响，没转过来弯。还有一点是我现在明确区分了实际的现象和规律以及录入到网站的现象和规律。虽然我之前就感觉这二者不同，但是没有命名。

@CEBBCAT 你说像指的是形式上像还是内容上像？内容上像的话能谈谈吗？比如你后来为什么相信行不通的？形式和内容意会吧，我感觉跟网上搜到的意思差不多。我想不到更准确的词。

@CEBBCAT 很难醒了。我估计除了运营个十年也没什么效果我是不会醒的。另外不用担心我，我目前计划是尽快写出来，然后以后就用业余时间运营。我问过 deepseek ，它没说出跟我的想法类似的网站。

@AutumnVerse #11 问题是我的花活是一般人强烈不建议的。他要是个点查我才不会管。我怕它出现类似组合爆炸的问题。我只是个野生程序员，我的直觉和经验都不够，不敢猜和想。

@ntedshen #8 不是。我主要是怕我那个花活根本就支撑不了多大的数据量，我主要不是为了优化性能。我没说明白。