go 语言直接使用 map 和连接 Redis 后使用 Map 性能差别有多大
go 语言直接使用 map 很方便
map1 := make(map[string]int)
key1 := map1["str1"]
但是发现有些 go 项目源码偏向使用 Redis 等第三方的 map.
import (
github.com/go-redis/redis"
)
client := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Password: "",
DB: 0,
})
client.Ping()
client.HSet("myhash", "key1", "value1")
value1, err := client.HGet("myhash", "")
然后看到项目的 map 并不是并发使用的,数据量也不是特别大。(有些并没有持久需求的也在使用 redis )
go map 和 redis map 都是内存使用的,而且速度也很快。但是很多需要查找 hash 关系表的项目,偏向使用如 redis map 等第三方表。
我粗略测试了一下,没看出什么区别(可能我测试数据较小)。如果排除 go map 不能并发读写外与 Redis Map 使用性能差别有多大
我也想知道,等看结果
楼主可以贴下测试代码吗?直觉上 redis 应该会慢很多,毕竟隔了个 tcp 传输
这不是性能的问题吧,Redis 数据是可以持久的,你 go 内存里的重启了数据就都没了
- 你的例子过于简单,实际业务大多存储结构体,这就涉及编解码和序列化的 CPU 内存消耗。本地缓存无需。2. 你连接的是本地 redis ,连接耗时忽略,也不存在高峰期的网络波动。没有任何测试意义。
应该是内置的快,没有持久化需求直接用内置的 map
瞎猜一个一百倍。你可以自己测一下。
内置大概的微秒级,Redis 毫秒级
虽然不知道 go 原生 map 和用 Redis 的性能差异,即便是 Redis 更快,为什么只用 localhost:port 的 TCP 连接本地回环的方式来访问 Redis 呢?在 Linux 上使用 unix domain sockets 的方式不是会更快吗?根据 Redis 官方文档上的数据,unix sockets 的吞吐量能提高 50%。而不支持 unix sockets 的 windows 貌似用 Redis 本身就有性能瓶颈,感觉还不如直接用 go 原生 map 。
得看,看 key 的数量,结构,数据类型,操作方法。稍微读一下两个源码就知道
不是做二级缓存的话,在性能足够的情况下,用 redis 使应用无状态,有利于后续横向扩展
场景不一样,没什么可比性
微秒级和纳秒级,如果一个语言标准库 hash 表才有读 redis 的速度,那这语言太废了,没有 4 个数量级的差距说不定都是你用的有问题
再注意下,数据序列化/反序列化
你看的是什么项目?
大概 100ns/op 和 1ms/op 的差异
测试代码 Dictionary<int, int> dict = new() { { 1, 1 } }; Stopwatch stopwatch = Stopwatch.StartNew(); int i = dict[1]; stopwatch.Stop(); Console.WriteLine(stopwatch.ElapsedTicks); using ConnectionMultiplexer redis = ConnectionMultiplexer.Connect("localhost"); IDatabase database = redis.GetDatabase(); database.HashSet("key", 1, 1); stopwatch = Stopwatch.StartNew(); RedisValue redisValue = database.HashGet("key", 1); stopwatch.Stop(); Console.WriteLine(stopwatch.ElapsedTicks);
测试结果:74618209
一句话: 内存 map 快 25 倍
更新重复一万次测试结果 Dictionary<int, int> dict = new() { { 1, 1 } }; Stopwatch stopwatch = Stopwatch.StartNew(); for (int i = 0; i < 10000; i++) { int j = dict[1]; } stopwatch.Stop(); Console.WriteLine(stopwatch.ElapsedTicks); using ConnectionMultiplexer redis = ConnectionMultiplexer.Connect("localhost"); IDatabase database = redis.GetDatabase(); database.HashSet("key", 1, 1); stopwatch = Stopwatch.StartNew(); for (int i = 0; i < 10000; i++) { RedisValue redisValue = database.HashGet("key", 1); } stopwatch.Stop(); Console.WriteLine(stopwatch.ElapsedTicks);
输出12289577919
一句话: 内存 map 快 7800 倍
一个内存读,可能还用 cpu 缓存,一个跨网络读
肯定是本地快啊 没经过网络
这个测试没意义啊,redis 能持久存储,map 不行,redis 也有一些回收和超时策略,这两个都不是一个东西,使用场景不一样
这对比没意义,就像在问火车和远洋轮渡谁快
小系统可以考虑直接用 goframe 的 gmap, 当缓存, 系统启动的时候, 把所有数据读到 gmap 里面, 速度超级快, 还省了序列化的时间
举个例子你现在想去厕所去你家的厕所快还是去邻居家的厕所快
我嫉妒你的才华
如果性能一样的话,当然是 Redis 的更好,你可以把内存占用、自动超时等烦心事一股脑的扔给 Redis 去处理。但是性能是否一样,那还另说,不过这块我不擅长,不评论。再但是,性能是够用就好,不是越高越好。所以,只要性能差距对上层没那么敏感,还是以功能方便为首要选择依据。然而,借用 Redis 做 Map 是增加编码和运维复杂度的,所以一般场景的功能上也会偏向于使用内置 Map 。如果你发现一般场景都用 Redis Map 来取代内置 Map ,那很有可能是内置 Map 太烂了。
有没有一种可能....用 Redis 的人寻求的是一个 "既可快速读写" ,"又可以多个服务(同个服务多个副本)" 访问的 KV 存储....我看楼主的意思,应该没有多个副本吧,就一个普通的单实例应用
又没有可能是集群应用?
tcp 传输完内存都操作几百次,你说哪个快?
你说的这都不是一个事情吧,需求都不一样吧,内存只能单机用呀,会这样写,肯定是预留扩展吧
segmentfault.com/q/1010000022345062
redis 是数据库,跟本地操作怎么比,语言再拉跨也比网络快啊
本地 Map 强多了为什么会出现 Redis?为什么 Redis 功能这么强大还是会有本地 Map ? 先把这两个问题搞清楚吧。。 别一头雾水就提问
外部的服务缓存,怎么能跟本地内存比速度。一个网络耗时,就比本地内存数据速度慢几百倍
分布式缓存和内存缓存的应用场景完全不一样,对比无意义
集群应用只能存 redis 自带的再快也不行
一个是持久化 一个是不是 redis 要 io 耗时的啊 看应用场景分不同用法...如果是集群应用 那就要用到 redis
你还是停留在单机呀, 当你上集群的时候, 你还用 map 吗而且机器之间怎么交换数据, 缓存控制这些
哦。。那你这段数据同时被两个接口做 update ,请问阁下如何应对?
莫民奇妙的问题
莫名奇妙的问题
肯定是直接内存快
什么没头没尾的问题, 现在 go 程序员都这样?
有没有可能是为了用 redis
内置 map 肯定更快, 用 redis 是因为在分布式环境下可以共享, 以及可以持久化
这都没必要测试吧,网络 IO 怎么能和内存比
看了这个标题,眉头一皱,看了描述,眉头再皱,不知道具体想问什么问题。看了下面评论,眉头再一皱,还真有人在纠结讨论内置 map 和 redis 的性能。
不知道这个帖子想表达和讨论的是什么内容,一脸懵逼
这个看过吗?这里还没算本身的网络延迟,抽象点说,也就是 redis 和你程序的物理距离 github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md camo.githubusercontent.com/77f72259e1eb58596b564d1ad823af1853bc60a3/687474703a2f2f692e696d6775722e636f6d2f6b307431652e706e67
多台机器跑横向扩展的时候就知道了
这还用想,redis 有 IO 呀,当然是内存,
之前习惯了 python/js 这种语法,感觉很自然很方便。 今天看了下 MongoDB 官方的 Go 接口,哎呀,那交互方式,真的是痛苦。 例如查询用户为 1 的用户:{us…
原因应该都是 app 不支持 64 位,而安卓 14 不再支持 32 位应用。目前遇到:com.webank.wemoneycom.cmbchina.ccd.pluto.cmb…
不是第一次在 v 站看到 next.js 的帖子了,属于是一回生二回熟,到第三回第四回的时候确实有点感觉是不是有什么我不知道的技术潮流了 于是去查了一下,说实话并未感觉到有什么…