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

[aruisi]

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

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

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

[lishunan246]

用 MongoDB 存下？

[misaka19000]

2ms 磁盘可能满足不了需求吧

[decken]

为了查询还是读取？

[willchen]

真的不考虑 NoSQL ？

[aruisi]

@lishunan246
@willchen 如果上数据库的，数据库服务器必须与主服务器分离，不能跑在一台机器上。这样是不是千兆带宽就是瓶颈？
@decken 查询

[willchen]

@aruisi 网卡影响大不 数据吞吐量不大 主要是网络时延吧 2ms 感觉没问题

[aruisi]

找到一张图，计算机各设备访问速度.

按照这张图，内存顺序 1MB 数据需要 250µs，我这 100 万行文本数据大约是 60MB，1µs=1000ms，换算过来，100 万行数据在内存中顺序读取最大延迟大约为 15ms
这个图是前几年的，现在的速度应该比这个快了些，这里的内存是什么规格什么频率没说，按照现在 DDR4 2800 算的话，应该比 15ms 要低。但是要达到 2ms 估计困难。

[libo26]

数据量不大，单机 /进程内缓存，2ms 应该无压力。数据库和服务分离部署，不能只看带宽，还要保证延迟稳定，这点不容易做到

[willchen]

@aruisi 顺序读取。。。起码要构造个搜索树吧 不过都到这步了 为什么不直接用 内存型的 k-v store

[decken]

http://redisearch.io/Quick_Start/
redis 下的全文索引, 可以装个测试下.

solr 和 es 也是很合适的选择, 但是 java 天然的 gc 问题, 满足不了"任何负载情况下，读取延迟都不能超过 2ms"
by the way, 不能超过 2ms 是啥场景?机器 网络也会抖动的,保证不了 100%的

[myliyifei]

@aruisi 万兆网卡延迟小很多

[otakustay]

区区 100W 行不是应该直接放进内存搞个针对你的查询要求的数据结构吗

[sagaxu]

有哪些查询条件？结果集一般多大？一次读 100 万条，不管怎么优化也做不到 2ms。

[aruisi]

@otakustay 这软件如果不做改造他只支持文本顺序读取。。囧

@sagaxu 没有复杂查询条件，只要数据完全匹配就 ok，就是确认一下这个数据存不存在而已，也不是模糊查询。

[wangym5106]

@aruisi 只需要确定数据是否存在的话，可以用哈希表

[sagaxu]

@aruisi 这种情况没必要增加一台数据库服务器，放内存里就可以了，用 map 结构做查找，不用遍历 100 万条，遍历 100 万，2ms 可能不够

[nazor]

要是数据能比较先后关系，就用二叉树咯

[laxenade]

只是对比的话，哈希表应该是最快的了。模糊查找的话，可以试试嵌入式内存数据库。尽可能不要依靠硬盘吧。

[Smartype]

不是很懂。不觉得这个复杂在哪里。

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

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

楼主应该是没有很清楚的表述需求。

[FanWall]

这个数据量 而且看题目意思内存足够 那还考虑什么数据库 在内存中用哈希表存储 直接读指针不比 socket 快多了…