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

[aruisi]

这是一个看似无聊的问题，但的确存在两种方案如何选择的问题。
100 万行无分类数据，此业务需要高并发超低延迟响应读取，无写入量或写入量极低。要求任何负载情况下，读取延迟都不能超过 2ms。目前有两种方案：
1.将数据以文本形式全部加载进内存（ DDR4 2800 ），此种方式无需对软件做任何改造，读取方式应该是由软件在内存中顺序读取。
2.改造软件，将数据导入 MYSQL 后建立索引（软件服务器与数据库服务器需分离，通过千兆内网连接），数据库服务器硬盘 IOPS 为 3000+

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

请问这两种方案哪种响应延迟更低？方案 2 的主要瓶颈是否在千兆内网上？

[jhdxr]

确认是否存在如果允许 false postive 的话，bloom filter 应该非常适合了

[swulling]

挂内存盘，然后把 mysql 起在内存盘上，最快

[zqf01]

这 100 万行有添加删除的需求吗？个人觉得 hash 之后应该是最快的，按 hash 之后 16 个字节来算，16*1000000/1024/1024 = 15.25M ，基本是你说的 60M 的四分之一，如果这 100 万行一直不变动，直接放内存中一个简单的搜索算法就可以了，如果有添加删除的要求，考虑下内存数据库。
个人意见，仅供参考。

[fiht]

直接丢到 MySQL 里，加好索引 select 看一下，不能达到 2ms 再考虑其他的。
如果 mysql 解决不了的话，直接进 redis，kv 对存储，看能不能到达 2ms，不能到达的时候再考虑其他的。
如果 redis 解决不了的话，直接 k-v 对 load 进程序内存，看能不能到达 2ms，不能到达的时候再考虑其他的。
例如 Python 的 dict，查找就是 o(1)的复杂度（我没理解错的话，理解错了请楼下给我指正）
其实响应要求 2ms 的话我还是建议选择最后一种方案，直接 load 进内存，load 进内存之后所有的情况都是可控的（除了服务器内存不够引起的问题），通过网络传输可能有很多不可控的因素。

[aruisi]

@zqf01
@fiht
@FanWall 这些数据是会每隔几天添加一部分的但不多，删除的更少。

[fiht]

@aruisi 你按照我说的做一下性能测试吧，可以从后往前做。MySQL 是不建议的，不太适用与这种场合

[aliipay]

100 万行记录，hashmap 不管使用便捷性还是延时性能，都能秒杀 mysql 和各种 nosql 了

[akira]

一行数据如果是 1k 左右的话，100w 行大约是 1GB 内存，直接丢内存无压力。
如果一行数据是 100kb 的话，那就要想想别的方案了

[menc]

@jhdxr
百万还用什么 bloom filter 啊，一个 hash 函数都足够 handle

[zhx1991]

看一行大小, 不太大全放本地内存里肯定比数据库快

[Michaelssss]

全部 load 内存，做布隆搜索

[zjqzxc]

找一台单独的机器，全扔内存里加个索引或者用一种树结构存储，最好情况下时间复杂度 log （ 1000000 ）=20，按照 7 楼的图，应该可以在几个微妙内完成
如果考虑到 cpu 的缓存，有可能可以把时间压缩到 1 个微妙以内

剩下的 2 毫秒基本上都算给网络延迟，应该够用了

[chzyer]

真的想偷懒又不想走网络的话，试试支持内嵌的数据库？

[QQ2171775959]

这需要一台高性能的服务器来支撑。