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 呀,当然是内存,
写了个 sh 内容如下 #!/bin/bash cd /srv/FileServerWeb nohup ./FileServerWeb > /dev/null 2>&1 & 在…
(感谢 @文艺复兴记(todd) 投递此文) 在编译理论中,通常将编译过程抽象为5个主要阶段:词法分析(Lexical Analysis),语法分析(Parsing),语义分析…
又不加钱又要办事,快顶不住了,以推荐系统的内核低于 6 拒绝了,还有什么理由? ==== 根据最新文件,必须使用国产化系统,禁止 Liunx 、Ubantu 、redhat 等…