屌丝论坛

多标签搜索想法

传统：找到每个标签对应的所有行，将所有行进行交集，输出结果。

问题：当行数非常多的时候，内存开销极大。

希望：维持低内存占用，可以加长访客查询等待时间，如此做法是否可行？

想法：

1. 假设用户查询 A B C 三个标签，每个标签各有 200W 100W 50W 行结果。

2. 从结果最少的 C 标签取 1W 行。

3. 将1万行的ID分别带入AB对应索引进行查询，若行中ABC标签均存在则保留。

4. 计算是否满足分页所需数量（如100条），若不满足则输出当前已有结果，继续查找。

5. 可在查询到部分行数后实时输出，此处过程用前端AJAX交互并计入URL参数效果最佳。

土鳖老旧写法，不适用于AI、大数据等牛逼的现代化数据计算方式。

建议：为了访客体验和最佳性能，最好还是不用多标签交集查询。

C
C

所以你怎么知道标签C结果最少[em_24]

D
doi

要注意下分页的问题，对于你的取  标签过滤后最少的结果集  作为初始过滤数据集 而言，要想办法记录每页 起始/结尾 在初始过滤数据集（C表结果）中是第多少条，这样用户按顺序翻页会快一些

这样查询后面的页，不存在 执行了多个数据集间取交集 才能跳过前面的页 的问题，但是这个过程中数据源发生更改会导致结果数据有一点小问题

缓存的K-V可以为  [标签A-标签B-..... = C表]  [标签A-标签B-.....-16页结尾 = 366条]

W
wxjv99
doi
引用
所以你怎么知道标签C结果最少[em_24]
冰雪殇璃陌梦 所以你怎么知道标签C结果最少[em_24]

他是用时间换空间，也就是先把每个标签的数量都查出来，再取一部分去做后面的交集查询，这样不用同时查询和处理所有数据

W
wxjv99
doi
引用
所以你怎么知道标签C结果最少[em_24]
冰雪殇璃陌梦 所以你怎么知道标签C结果最少[em_24]

每个标签做下统计，写进表里

C
C
wxjv99
引用
冰雪殇璃陌梦所以你怎么知道标签C结果最少[em_24] 他是用时间换空间，也就是先把每个标签的数量都查出来，再取一部分去做后面的交集查询，这样不用同时查询和处理所有数据
wxjv99 他是用时间换空间，也就是先把每个标签的数量都查出来，再取一部分去做后面的交集查询，这样不用同时查询和处理所有数据

对的对的，就是用最烂的机器也能实现百万结果查询，只要用户等得起。标签数量是写进缓存的，不用多一次查询。大不了给用户排队，每个人每次查询10分钟完事这样。大佬上面那段待会再看

C
C
wxjv99
引用
要注意下分页的问题，对于你的取 标签过滤后最少的结果集 作为初始过滤数据集 而言，要想办法记录每页 起始/结尾 在初始过滤数据集（C表结果）中是第多少条，这样用户按顺序翻页会快一些 这样查...
wxjv99 要注意下分页的问题，对于你的取  标签过滤后最少的结果集  作为初始过滤数据集 而言，要想办法记录每页 起始/结尾 在初始过滤数据集（C表结果）中是第多少条，这样用 ...

没那么复杂，我是直接把最后处理的ID返回给用户，下次查询时直接从这个ID开始找就可以了。我的翻页逻辑和常见的页数不一样，我是按时间戳来分页的，下一页=上次时间戳后的结果集，所以这个问题比较好解决。

C
C
C
引用
冰雪殇璃陌梦所以你怎么知道标签C结果最少[em_24] 每个标签做下统计，写进表里
C 每个标签做下统计，写进表里

懂了，确实这样内存占用会稳定一些 

D
doi
doi
引用
C每个标签做下统计，写进表里 懂了，确实这样内存占用会稳定一些
冰雪殇璃陌梦 懂了，确实这样内存占用会稳定一些

这是在拉屎的时候想到的，因为多标签交集这个问题一直很困扰，如果每个标签对应的有100万数据，即便只把ID查出来取交集也会内存爆炸。于是我就想，能不能像拉屎一样，一截截地把数据挤出来，返回给用户？于是就想到了这种方法……

C
C

给你推荐个算法外的解决方案 sonic 他将 搜索条件-ID 缓存起来，可以看作轻量化的 elasticsearch ，应该能满足你的需求，功能更全面

W
wxjv99
wxjv99
引用
给你推荐个算法外的解决方案sonic他将 搜索条件-ID 缓存起来，可以看作轻量化的elasticsearch，应该能满足你的需求，功能更全面
wxjv99 给你推荐个算法外的解决方案 sonic 他将 搜索条件-ID 缓存起来，可以看作轻量化的 elasticsearch ，应该能满足你的需求，功能更全面

感谢，这个老早看过了。主要是需要空间还是蛮大的，等于每次搜索把交集做一次索引存入，我在想怎么能在1G内存的垃圾VPS上面搞第三方多标签搜索[em_23]

C
C
C
引用
冰雪殇璃陌梦懂了，确实这样内存占用会稳定一些 这是在拉屎的时候想到的，因为多标签交集这个问题一直很困扰，如果每个标签对应的有100万数据，即便只把ID查出来取交集也会内存爆炸。于是我就想，能不能...
C 这是在拉屎的时候想到的，因为多标签交集这个问题一直很困扰，如果每个标签对应的有100万数据，即便只把ID查出来取交集也会内存爆炸。于是我就想，能不能像拉屎一样，一截截地把数据挤出来，返回给用户？于是就 ...

100万个int32类型的ID，也就3.8M，加上 占大头的搜索条件 应该不超过百M，主要还是数据库在查找和处理数据时内部算法占用了大量内存，可以看看上面的方案，sonic比elasticsearch占用少的多

W
wxjv99
wxjv99
引用
给你推荐个算法外的解决方案sonic他将 搜索条件-ID 缓存起来，可以看作轻量化的elasticsearch，应该能满足你的需求，功能更全面
wxjv99 给你推荐个算法外的解决方案 sonic 他将 搜索条件-ID 缓存起来，可以看作轻量化的 elasticsearch ，应该能满足你的需求，功能更全面

我突然想到我这玩意拿MapReduce做特别合适！

随着数据量增加，处理时间会增加，但复杂度不会增加，这种用MapReduce分摊到集群最合适了。

C
C
C
引用
wxjv99给你推荐个算法外的解决方案 sonic 他将 搜索条件-ID 缓存起来，可以看作轻量化的 elasticsearch ，应该能满足你的需求，功能更全面 我突然想到我这玩意拿MapRe...
C 我突然想到我这玩意拿MapReduce做特别合适！ 随着数据量增加，处理时间会增加，但复杂度不会增加，这种用MapReduce分摊到集群最合适了。

你要的不是先分片然后顺序计算减少处理器和内存压力么，上并行和集群这怎么像是反向操作。。。

W
wxjv99

还是不做多标签的好

L
laogesix
wxjv99
引用
C我突然想到我这玩意拿MapReduce做特别合适！ 随着数据量增加，处理时间会增加，但复杂度不会增加，这种用MapReduce分摊到集群最合适了。 你要的不是先分片然后顺序计算减少处理器和内...
wxjv99 你要的不是先分片然后顺序计算减少处理器和内存压力么，上并行和集群这怎么像是反向操作。。。

把一个标签交叉任务分散给很多台服务器来做，减少压力。不过最开始几百万标签的时候根本用不到这种

C
C
laogesix
引用
还是不做多标签的好
laogesix 还是不做多标签的好

单向固定标签，对用户分类整理的细度要大很多了。

C
C
1
屌丝论坛