大容量的Dictionary用什么技术可以尽可能小的降低内存消耗
1
所有回答(7)
1
不要放程序中了，找个memcache或者redis都很容易实现这需求。
考虑到数据更新量大网络IO的问题，为了实现速度，我们不适用redis等
@水帘洞行者孙: 这种量的数据放程序里是不合适的，如果你程序跪了重新初始化这些数据的成本你考虑过没？
这种数据如果丢redis中，以hash为例，每秒100K的ops是没什么问题的，时间复杂度不管是读还是写都是O（1）（当然前提是你后面的value不能太大）
如果你那list<T>不是很大，但已经超过1K条而且T的实际类型属性很多的话可以考虑自定义序列化反序列化，比如粗暴点的自定义格式（23:张三:true对应user对象的年龄姓名和性别）
如果List<T>很长或者属性很多就算使用上述序列化方式还是无法将写入redis中的数据量降到KB级别的话可以做分片后写入不同的redis实例中确保redis性能
如果再大，比如List<T>已经到了MB甚至更大的话就需要考虑其他方案了（使用nosql存储数据，List<T>中每个写一条数据，按照普通查询来进行了。）
PS:如果使用redis记得预先估计redis容量（内存），如果没有合适的硬件条件的话只能采用分片
0
哪有那么大的内存给你浪费啊，考虑数据库存储吧。
0
70G内存 你们好牛逼!为什么不放缓存服务器里.
0
建议用redis缓存，我们之前就有类似的坑，后来接手以后搭了台redis的服务器，将它拆解放到redis缓存中，速度也特别快，而且也不会影响到主服务器。不过我们之前占的内存最多就几个G，70G还真没见过
1
Dictionary不是存在内存里的吗？你的内存有70G?
0
技术问题都好解决，能不能把70g内存拍个照，想看看有多大
0
系统自带了内存压缩。
先把量算好，被虚拟内存化了性能就差了。
redis的性能跟Dictionary直接内存根本不是一个数量级的效率，如果是时序数据不怕麻烦可以考虑用链表实现，数据区自行考虑是否用压缩算法以及用什么压缩算法，如果这样做，那么确定要bin化的，不怕麻烦就手写翻译，能节约到位就不要到int，整体最好以计算机内存最小存储单位作为倍数的定长块，怕麻烦用现成的，尽量不用非string这类变长类型。
务必注意int支撑问题，一定要计算好，通常主流都是int最为index或者长度。
索引也是一样，反正比如8个字节能解决3个数字问题就不要用3个int。
