多标签搜索想法

C 2022-6-16 2544

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

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

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

想法:

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

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

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

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

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

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

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

最新回复 (17)
  • doi 2022-6-16
    2

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

  • wxjv99 2022-6-16
    4

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

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

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

    这家伙太懒了,什么也没留下。
  • wxjv99 2022-6-16
    5
    冰雪殇璃陌梦 所以你怎么知道标签C结果最少

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

    这家伙太懒了,什么也没留下。
  • C 2022-6-16
    6
    冰雪殇璃陌梦 所以你怎么知道标签C结果最少

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

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

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

  • C 2022-6-16
    8
    wxjv99 要注意下分页的问题,对于你的取  标签过滤后最少的结果集  作为初始过滤数据集 而言,要想办法记录每页 起始/结尾 在初始过滤数据集(C表结果)中是第多少条,这样用 ...

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

  • doi 2022-6-16
    9
    C 每个标签做下统计,写进表里

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

  • C 2022-6-16
    10
    冰雪殇璃陌梦 懂了,确实这样内存占用会稳定一些

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

  • wxjv99 2022-6-16
    11

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

    这家伙太懒了,什么也没留下。
  • C 2022-6-16
    12
    wxjv99 给你推荐个算法外的解决方案 sonic 他将 搜索条件-ID 缓存起来,可以看作轻量化的 elasticsearch ,应该能满足你的需求,功能更全面

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

  • wxjv99 2022-6-16
    13
    C 这是在拉屎的时候想到的,因为多标签交集这个问题一直很困扰,如果每个标签对应的有100万数据,即便只把ID查出来取交集也会内存爆炸。于是我就想,能不能像拉屎一样,一截截地把数据挤出来,返回给用户?于是就 ...

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

    这家伙太懒了,什么也没留下。
  • C 2022-6-21
    14
    wxjv99 给你推荐个算法外的解决方案 sonic 他将 搜索条件-ID 缓存起来,可以看作轻量化的 elasticsearch ,应该能满足你的需求,功能更全面

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

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

  • wxjv99 2022-6-22
    15
    C 我突然想到我这玩意拿MapReduce做特别合适! 随着数据量增加,处理时间会增加,但复杂度不会增加,这种用MapReduce分摊到集群最合适了。

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

    这家伙太懒了,什么也没留下。
返回
发新帖