目标
为了防止出现 XY 问题，先说一下目标。要是有人感觉我的解决方案不对，可以指出来。
我并不是为了给内容添加标签，而是为了用标签这个技术实现用很多现象（就是一段描述性的没有主语的话，主语就是用户，比如喜欢猫，大五开放性为很高等）来尽量详尽地描述一个人，以更好地实现个性化推荐。现象一般都是用户自己给自己添加的。不过我设想的网站更有特色的地方是推荐方法，而不是一般的推荐内容，虽然也能推荐内容。我假设不同方法依赖的特征可能是有限的，所以至少在知道方法依赖的特征的时候不需要匹配非常多的标签。
类比标签系统中的内容，我设想的系统中有现象箱子的概念。将不同现象放到不同现象箱子中主要是为了方便管理和搜索。比如上一段提到的有助于推荐方法的现象主要放到“我的个人成长现象箱子”中。而有助于推荐 ACG 音乐的现象放到“我喜欢的 ACG 音乐有序列表”中。这二者都保存到一个数据库表中。表模式：（主键，现象箱子 ID ，现象 ID ），然后在（现象 ID ，现象箱子 ID ）上建立复合索引。
如果现象箱子的现象最大数量比较小的话，那么相关的现象就必须放到不同的现象箱子中。这样的话搜索的时候会相当麻烦，不光我写代码麻烦，用户理解起来可能也会更麻烦。如果不同的现象箱子有相同的现象的话，维护一致性也是个问题。
我估计一般不会所有人都会在现象箱子中添加三万的现象，至少初期应该不会。
基本可以确定是用 PostgreSQL 实现。
具体搜索方式
我计划一次只搜索五个现象以下可以立即返回结果。至于更多的，则需要排队，在半夜没人的时候集中批量搜索。大概最多不可以超过一百个现象。
还有搜索的时候我会对标签进行或组合，我记得 DeepSeek 好像说过或比与更耗时。就是搜索设置了现象 1 或现象 2 或现象 3 的用户。与组合也会用，还有与和或组合。
为什么不自己去测试性能
我自己试过，好像一万个标签性能也没差到哪去，对我来说可以接受。但是我不知道这里还会有什么其他的问题。要是没人理我我只能自己去测试了。还有自己测试太费劲了。
通过推理来证明我也基本能接受
比如既然 ElasticSearch 能做到，规模大了之后应该也不会是问题吧？不过我问了一下 DeepSeek ，它说 ElasticSearch 对文章长度很长的数据集索引和搜索效率都会降低，最好是拆分成小文档。当然最好还是有谁实际搞过，没遇到什么大问题。
我知道的实现我的目标的据说更好的实现方法
向量数据库。这个应该是需要选出一个子集，因为动态添加维度好像不容易。
位图索引数据库。好像也要选出一个子集，也是因为好像动态添加列不方便。
ElasticSearch 。吃内存。据说至少要 4 GB 到 8 GB 的内存。我初期估计也就能用个 2 GB 到 4 GB 的服务器。
为什么是三万
这节很玄乎，没坚实的根据，没兴趣别看。
我搜过基因最多的生物，其基因大概是三万左右。另外 DeepSeek 说一个复杂系统的子系统的类型的数量一般是存在最优值的，更多更少可能都会降低适应性。然后我感觉三万没准是子系统类型的上限。很二的逻辑是吧？我也感觉很二。我其实也想过怎么才能把现象盒子分层，不过没什么比较好的点子。目前感觉还凑合的方法是将现象箱子相互关联起来。搜索的时候会自动探索相关的现象箱子。不过实现起来没什么头绪。还有就是按身份、目标、难以改变的现象、容易改变的现象给现象箱子分类，并通过这个优化搜索。但是实现还是很麻烦。如果三万没什么特别大的问题我还是想以后再优化。初期先凑合着，反正我设想的这个网站也不一定真有用。
1
Select Language