喜讯:100万数据快速分页测试成功!

C 2月前 1199

前情摘要:https://assbbs.com/thread-36208.htm

看到NodeSeek分页限制在100页,手贱点进去还把他们网站搞到503崩了。

传统的MySQL分页模式,在offset跳过数据过大的时候,就会变慢。

因此我采用了B+树磁盘存储,把key链表顺序缓存到内存。

100万条数据测试结果:

B+树读取链表到内存,用时213ms。

按阅读权限写入两个Map列,数据合计无误。

取第888888条数据,几乎没有任何分页时间。

(不到1ms,理论上1亿数据速度也相差不大)

按此分页key中的数据,从SQLite加载行即可。

image.webp

试验可行,明天就把数据融合到程序中去。

测试数据样例:

image.webp

最新回复 (17)
  • cn 2月前
    2

    太棒了

  • C 2月前
    3
    cn 太棒了

    昨天技术群里发了个,收到些反馈,还可以再优化。去掉中间层缓存,速度还能提升很多。

  • cn 2月前
    4
    C 昨天技术群里发了个,收到些反馈,还可以再优化。去掉中间层缓存,速度还能提升很多。

    技术群可以推一下吗 看看

  • C 2月前
    5
    cn 技术群可以推一下吗 看看

    私信了,群主相当牛逼,全球第二的帝国理工CS科班

  • cn 2月前
    6
    C 私信了,群主相当牛逼,全球第二的帝国理工CS科班

    好咧感谢

  • 袁某人 2月前
    7

    我实测过5000w数据,用索引分页响应速度没啥变化

  • C 2月前
    8
    袁某人 我实测过5000w数据,用索引分页响应速度没啥变化

    看怎么分的,如果传入参数 index>=* 这类的,那定位很快的。

    因为都是B+Tree,找到其中一项时间是O(1),后续只要通过左右数值游标找就行了。

    如果你5000万数据用 OFFSET 40000000, LIMIT 10 这种方式,在 OFFSET 大的时候会很慢。

  • NeKoYun 2月前
    9

    这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]

  • 呆哥 2月前
    10
    NeKoYun 这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]

    扎心了

  • C 2月前
    11
    NeKoYun 这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]

    [em_3]

  • 倒霉蛋 2月前
    12
    NeKoYun 这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]

    我可以不用,但是我不能没有[em_20]

  • 不会飞的鸟 2月前
    13
    NeKoYun 这论坛总共就几个活人 动不动几百万几千万数据用得到吗[em_37]

    技术佬的执着 [em_14]

  • NeKoYun 2月前
    14
    呆哥 扎心了

    呆哥 来个邀请码

  • maggch 2月前
    15

    更新复杂度多少,你这更新要遍历链表吧