为了防止出现 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 说一个复杂系统的子系统的类型的数量一般是存在最优值的,更多更少可能都会降低适应性。然后我感觉三万没准是子系统类型的上限。很二的逻辑是吧?我也感觉很二。我其实也想过怎么才能把现象盒子分层,不过没什么比较好的点子。目前感觉还凑合的方法是将现象箱子相互关联起来。搜索的时候会自动探索相关的现象箱子。不过实现起来没什么头绪。还有就是按身份、目标、难以改变的现象、容易改变的现象给现象箱子分类,并通过这个优化搜索。但是实现还是很麻烦。如果三万没什么特别大的问题我还是想以后再优化。初期先凑合着,反正我设想的这个网站也不一定真有用。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.