V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
aruisi
V2EX  ›  MySQL

100 万行数据,内存文本顺序读取和 MYSQL 索引读取哪个更快?

  •  
  •   aruisi · 2017-08-19 11:17:41 +08:00 · 8306 次点击
    这是一个创建于 2414 天前的主题,其中的信息可能已经有所发展或是发生改变。
    这是一个看似无聊的问题,但的确存在两种方案如何选择的问题。
    100 万行无分类数据,此业务需要高并发超低延迟响应读取,无写入量或写入量极低。要求任何负载情况下,读取延迟都不能超过 2ms。目前有两种方案:
    1.将数据以文本形式全部加载进内存( DDR4 2800 ),此种方式无需对软件做任何改造,读取方式应该是由软件在内存中顺序读取。
    2.改造软件,将数据导入 MYSQL 后建立索引(软件服务器与数据库服务器需分离,通过千兆内网连接),数据库服务器硬盘 IOPS 为 3000+

    数据无冷热之分,无法做到冷热分离。

    请问这两种方案哪种响应延迟更低?方案 2 的主要瓶颈是否在千兆内网上?
    34 条回复    2017-08-21 10:27:05 +08:00
    lishunan246
        1
    lishunan246  
       2017-08-19 11:22:38 +08:00
    用 MongoDB 存下?
    misaka19000
        2
    misaka19000  
       2017-08-19 11:23:03 +08:00
    2ms 磁盘可能满足不了需求吧
    decken
        3
    decken  
       2017-08-19 11:32:51 +08:00 via iPhone
    为了查询还是读取?
    willchen
        4
    willchen  
       2017-08-19 11:39:36 +08:00
    真的不考虑 NoSQL ?
    aruisi
        5
    aruisi  
    OP
       2017-08-19 11:41:10 +08:00
    @lishunan246
    @willchen 如果上数据库的,数据库服务器必须与主服务器分离,不能跑在一台机器上。这样是不是千兆带宽就是瓶颈?
    @decken 查询
    willchen
        6
    willchen  
       2017-08-19 11:45:26 +08:00
    @aruisi 网卡影响大不 数据吞吐量不大 主要是网络时延吧 2ms 感觉没问题
    aruisi
        7
    aruisi  
    OP
       2017-08-19 11:50:13 +08:00   ❤️ 1
    找到一张图,计算机各设备访问速度.

    按照这张图,内存顺序 1MB 数据需要 250µs,我这 100 万行文本数据大约是 60MB,1µs=1000ms,换算过来,100 万行数据在内存中顺序读取最大延迟大约为 15ms
    这个图是前几年的,现在的速度应该比这个快了些,这里的内存是什么规格什么频率没说,按照现在 DDR4 2800 算的话,应该比 15ms 要低。但是要达到 2ms 估计困难。
    libo26
        8
    libo26  
       2017-08-19 11:59:56 +08:00 via iPhone
    数据量不大,单机 /进程内缓存,2ms 应该无压力。数据库和服务分离部署,不能只看带宽,还要保证延迟稳定,这点不容易做到
    willchen
        9
    willchen  
       2017-08-19 12:00:26 +08:00
    @aruisi 顺序读取。。。起码要构造个搜索树吧 不过都到这步了 为什么不直接用 内存型的 k-v store
    decken
        10
    decken  
       2017-08-19 12:13:14 +08:00   ❤️ 1
    http://redisearch.io/Quick_Start/
    redis 下的全文索引, 可以装个测试下.

    solr 和 es 也是很合适的选择, 但是 java 天然的 gc 问题, 满足不了"任何负载情况下,读取延迟都不能超过 2ms"
    by the way, 不能超过 2ms 是啥场景?机器 网络也会抖动的,保证不了 100%的
    myliyifei
        11
    myliyifei  
       2017-08-19 12:16:26 +08:00 via Android
    @aruisi 万兆网卡延迟小很多
    otakustay
        12
    otakustay  
       2017-08-19 12:24:24 +08:00   ❤️ 1
    区区 100W 行不是应该直接放进内存搞个针对你的查询要求的数据结构吗
    sagaxu
        13
    sagaxu  
       2017-08-19 12:33:14 +08:00 via Android
    有哪些查询条件?结果集一般多大?一次读 100 万条,不管怎么优化也做不到 2ms。
    aruisi
        14
    aruisi  
    OP
       2017-08-19 12:52:28 +08:00
    @otakustay 这软件如果不做改造他只支持文本顺序读取。。囧

    @sagaxu 没有复杂查询条件,只要数据完全匹配就 ok,就是确认一下这个数据存不存在而已,也不是模糊查询。
    wangym5106
        15
    wangym5106  
       2017-08-19 13:35:00 +08:00   ❤️ 1
    @aruisi 只需要确定数据是否存在的话,可以用哈希表
    sagaxu
        16
    sagaxu  
       2017-08-19 13:38:09 +08:00 via Android   ❤️ 1
    @aruisi 这种情况没必要增加一台数据库服务器,放内存里就可以了,用 map 结构做查找,不用遍历 100 万条,遍历 100 万,2ms 可能不够
    nazor
        17
    nazor  
       2017-08-19 13:51:48 +08:00 via iPhone
    要是数据能比较先后关系,就用二叉树咯
    laxenade
        18
    laxenade  
       2017-08-19 14:25:51 +08:00
    只是对比的话,哈希表应该是最快的了。模糊查找的话,可以试试嵌入式内存数据库。尽可能不要依靠硬盘吧。
    Smartype
        19
    Smartype  
       2017-08-19 17:40:59 +08:00 via Android   ❤️ 1
    不是很懂。不觉得这个复杂在哪里。

    这个数据量当然是选择放内存里面, 方案比如 MySQL memory 引擎,redis, 自己定义数据结构放内存选择最适合的 hash 算法,Bloom filter 等。

    如果觉得性能还是不够, Seastar 相关方案, memcached, pedis,或者自己基于 seastar 实现适合需求的数据结构,查找算法,如果能做到线速,就没有什么好纠结的。

    楼主应该是没有很清楚的表述需求。
    FanWall
        20
    FanWall  
       2017-08-19 17:47:22 +08:00 via Android   ❤️ 1
    这个数据量 而且看题目意思内存足够 那还考虑什么数据库 在内存中用哈希表存储 直接读指针不比 socket 快多了…
    jhdxr
        21
    jhdxr  
       2017-08-19 17:57:30 +08:00   ❤️ 1
    确认是否存在如果允许 false postive 的话,bloom filter 应该非常适合了
    swulling
        22
    swulling  
       2017-08-19 18:01:35 +08:00 via iPhone
    挂内存盘,然后把 mysql 起在内存盘上,最快
    zqf01
        23
    zqf01  
       2017-08-19 18:05:30 +08:00   ❤️ 1
    这 100 万行有添加删除的需求吗?个人觉得 hash 之后应该是最快的,按 hash 之后 16 个字节来算,16*1000000/1024/1024 = 15.25M ,基本是你说的 60M 的四分之一,如果这 100 万行一直不变动,直接放内存中一个简单的搜索算法就可以了,如果有添加删除的要求,考虑下内存数据库。
    个人意见,仅供参考。
    fiht
        24
    fiht  
       2017-08-19 18:35:19 +08:00   ❤️ 1
    直接丢到 MySQL 里,加好索引 select 看一下,不能达到 2ms 再考虑其他的。
    如果 mysql 解决不了的话,直接进 redis,kv 对存储,看能不能到达 2ms,不能到达的时候再考虑其他的。
    如果 redis 解决不了的话,直接 k-v 对 load 进程序内存,看能不能到达 2ms,不能到达的时候再考虑其他的。
    例如 Python 的 dict,查找就是 o(1)的复杂度(我没理解错的话,理解错了请楼下给我指正)
    其实响应要求 2ms 的话我还是建议选择最后一种方案,直接 load 进内存,load 进内存之后所有的情况都是可控的(除了服务器内存不够引起的问题),通过网络传输可能有很多不可控的因素。
    aruisi
        25
    aruisi  
    OP
       2017-08-19 21:47:48 +08:00
    @zqf01
    @fiht
    @FanWall 这些数据是会每隔几天添加一部分的但不多,删除的更少。
    fiht
        26
    fiht  
       2017-08-19 21:51:45 +08:00
    @aruisi 你按照我说的做一下性能测试吧,可以从后往前做。MySQL 是不建议的,不太适用与这种场合
    aliipay
        27
    aliipay  
       2017-08-19 22:15:08 +08:00   ❤️ 1
    100 万行记录,hashmap 不管使用便捷性还是延时性能,都能秒杀 mysql 和各种 nosql 了
    akira
        28
    akira  
       2017-08-20 00:05:55 +08:00   ❤️ 1
    一行数据如果是 1k 左右的话,100w 行大约是 1GB 内存,直接丢内存无压力。
    如果一行数据是 100kb 的话,那就要想想别的方案了
    menc
        29
    menc  
       2017-08-20 00:35:12 +08:00
    @jhdxr
    百万还用什么 bloom filter 啊,一个 hash 函数都足够 handle
    zhx1991
        30
    zhx1991  
       2017-08-20 00:57:02 +08:00
    看一行大小, 不太大全放本地内存里肯定比数据库快
    Michaelssss
        31
    Michaelssss  
       2017-08-20 10:54:13 +08:00
    全部 load 内存,做布隆搜索
    zjqzxc
        32
    zjqzxc  
       2017-08-20 11:27:33 +08:00   ❤️ 1
    找一台单独的机器,全扔内存里加个索引或者用一种树结构存储,最好情况下时间复杂度 log ( 1000000 )=20,按照 7 楼的图,应该可以在几个微妙内完成
    如果考虑到 cpu 的缓存,有可能可以把时间压缩到 1 个微妙以内

    剩下的 2 毫秒基本上都算给网络延迟,应该够用了
    chzyer
        33
    chzyer  
       2017-08-21 08:35:14 +08:00 via iPhone
    真的想偷懒又不想走网络的话,试试支持内嵌的数据库?
    QQ2171775959
        34
    QQ2171775959  
       2017-08-21 10:27:05 +08:00
    这需要一台高性能的服务器来支撑。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2749 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 12:47 · PVG 20:47 · LAX 05:47 · JFK 08:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.