Golang 的 Map 可不可以存大量的数据？比如说几个 GB 的数据

[dw2693734d]

因为 map 是 O(1)的，我想用来当 key value 数据库，快速查询一些数据。

这样会不会有什么隐患问题？

[hhjswf]

@documentzhangx66 单论性能肯定吊打了，redis 至少得多经历一个网络 io

[dw2693734d]

@ccde8259 只读的，一次性加载进来，然后只读

[cabing]

找个包调用下~

[HankLu]

试试就知道了

[beijinglowb]

@documentzhangx66 历史遗留问题或者跟风呗，比 mysql 好的太多了，为啥那么多人用，还不是甩不掉

[ccde8259]

@dw2693734d
都是静态数据那完全没有线程安全问题
那用 map 方案规避 GC 的话估计得靠 Arena 分配一下内存就是了
用了 Arena 不被 GC 主要就关注一下会不会发生奇怪的内存泄露情况
现代操作系统反正内存基本上有 Swap 都是用不完的，但 Swap 是福也是祸
生产性能非预期就需要确定会不会因为 Swap 导致性能暴跌

[iseki]

@documentzhangx66 这都不是一种东西比啥啊

[dw2693734d]

@ccde8259 我把 swap 都关掉了，感觉 64g 够用了

[ccde8259]

然后是预期 hashmap 是 o(1)的，这么大的 map 就需要考虑是 key 量是多少，怎么分布。
hash 方案会不会导致某个 bucket 聚集了大量的 entry 。
如果 bucket 里面 entry 太多，由于 hash 冲突用的链地址法，会退化成 o(N)，N 是 bucket 里 entry 数量。
一次性放进去那么多数据会不会导致有未完成的扩容行为，冷起性能被拖累，需不需要 warm up 。
读取是全随机还是有特定热点的，在 hashmp 的基础上再套 LRU ，同样 o(1)但是收缩常数会不会更快？

[IDAEngine]

可以，毫无压力

[Vegetable]

当然没问题，启动时将大数据集加载到内存是很常见的操作，设计好数据结构别让数据膨胀太多就好。

[james122333]

我写 demo 的时候也都是这样搞 外部服务再快都不会比内部存取快
但正式时应该都不会这样搞 会怎么搞不告诉你

[djoiwhud]

@documentzhangx66

内置 map 肯定比 redis 性能好。就凭 tcp 的 io 毫秒级耗时，就压根不用比。

op 的问题要看业务场景。只要不出现雪崩，就没什么问题。

[standchan]

没试过，但是你最好一开始就指定好 map 的大小。golang 中 map 的扩增是耗费性能。自己玩无所谓，生产环境的话估计你这个方案通不过评审吧。

[cokyhe]

楼主的目的是 demo 不用装 redis 之类的
并且这个大数据不会再改变&&不能被对方拿到吧？

[webcape233]

我最近做的项目也用到这种了，从 sqlite 数据库拿出来缓存起来，不过量比你小

[webcape233]

我用的 sync map ，

[dw2693734d]

@cokyhe 对的

[wheeler]

golang 里面似乎 map 的 bucket 是不会缩容的

[PVXLL]

@documentzhangx66 不懂装懂