Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
dict太占内存，有啥优化的方法么？
263 views
Skip to first unread message
frank的爱情故事不会再改变
Jun 7, 2012, 11:59:42 AM6/7/12
to
为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
尝试numpy，但是没有好的方法解决查找效率。。
--
[36m※ 修改:·shinn 于 Jun 7 23:59:42 2012 修改本文·[FROM: 114.250.95.*] [m
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 114.250.95.*] [m
尝试numpy，但是没有好的方法解决查找效率。。
--
[36m※ 修改:·shinn 于 Jun 7 23:59:42 2012 修改本文·[FROM: 114.250.95.*] [m
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 114.250.95.*] [m
wkm
Jun 7, 2012, 12:15:20 PM6/7/12
to
用第三方库
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [34m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.207.43.*] [m
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [34m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.207.43.*] [m
望夜空，意踌躇
Jun 7, 2012, 12:48:18 PM6/7/12
to
大不了用C写
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 58.208.255.*] [m
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
普洛米·我们的民族从来不缺乏苦难
Jun 7, 2012, 6:33:31 PM6/7/12
to
什么样的数据？什么样的key？不说清楚别人怎么知道怎么“优化”
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [1;33m※ 来源:·水木社区 newsmth.net·[FROM: 209.249.197.2] [m
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
frank的爱情故事不会再改变
Jun 7, 2012, 9:19:32 PM6/7/12
to
有什么样的第三方库呢？
【 在 wkm (wkm) 的大作中提到: 】
: 用第三方库
--
[m [1;31m※ 来源:·水木社区 newsmth.net·[FROM: 64.104.125.*] [m
【 在 wkm (wkm) 的大作中提到: 】
: 用第三方库
--
[m [1;31m※ 来源:·水木社区 newsmth.net·[FROM: 64.104.125.*] [m
frank的爱情故事不会再改变
Jun 7, 2012, 9:33:23 PM6/7/12
to
好吧。。。
情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
一个{'name':'aa','status1':bb,'status2':cc...}
在程序运行过程中，我需要从外部接受更新数据（更新的数据包含'name'信息和部分新'status'的值），然后尽可能快的更新数据表。
我想最快速的方法应该是建一个大的字典，name做key，然后更新的时候
dict['name']['statusx'] = xxx
但是python的dict太费内存，我40w个dict内存大概就占10g以上了，而实际上dict的数据转成文本存在硬盘上也就是几十兆。
我的question是：python是否有优化的dict提供呢？或者有没有更好的方式来解决这个问题？
【 在 pulo (普洛米·我们的民族从来不缺乏苦难) 的大作中提到: 】
: 什么样的数据？什么样的key？不说清楚别人怎么知道怎么“优化”
--
[36m※ 修改:·shinn 于 Jun 8 09:33:22 2012 修改本文·[FROM: 64.104.125.*] [m
情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
一个{'name':'aa','status1':bb,'status2':cc...}
在程序运行过程中，我需要从外部接受更新数据（更新的数据包含'name'信息和部分新'status'的值），然后尽可能快的更新数据表。
我想最快速的方法应该是建一个大的字典，name做key，然后更新的时候
dict['name']['statusx'] = xxx
但是python的dict太费内存，我40w个dict内存大概就占10g以上了，而实际上dict的数据转成文本存在硬盘上也就是几十兆。
我的question是：python是否有优化的dict提供呢？或者有没有更好的方式来解决这个问题？
【 在 pulo (普洛米·我们的民族从来不缺乏苦难) 的大作中提到: 】
: 什么样的数据？什么样的key？不说清楚别人怎么知道怎么“优化”
--
[36m※ 修改:·shinn 于 Jun 8 09:33:22 2012 修改本文·[FROM: 64.104.125.*] [m
www.koubuyi.com
Jun 7, 2012, 9:41:50 PM6/7/12
to
尝试用 memcache
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 好吧。。。
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行
--
[m [33m※ 来源:·水木社区 http://newsmth.net·[FROM: 116.228.233.*] [m
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 好吧。。。
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行
周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: 一个{'name':'aa','status1':bb,'status2':cc...}
: ...................
: 一个{'name':'aa','status1':bb,'status2':cc...}
--
[m [33m※ 来源:·水木社区 http://newsmth.net·[FROM: 116.228.233.*] [m
蛋蛋
Jun 7, 2012, 9:52:35 PM6/7/12
to
40w的字典，为何不考虑用类似Redis类的内存数据库了？
这要是直接优化的话，需要花很大的时间和精力。。。
[m [35m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.127.133.*] [m
这要是直接优化的话，需要花很大的时间和精力。。。
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。
。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
~蛋蛋~
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。
。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [35m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.127.133.*] [m
Kneo Fang
Jun 7, 2012, 10:51:15 PM6/7/12
to
数据多就上数据库。
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 好吧。。。
: 一个{'name':'aa','status1':bb,'status2':cc...}
: ...................
--
[m [32m※ 来源:·水木社区 http://newsmth.net·[FROM: 222.65.244.*] [m
: ...................
--
@arp
Jun 7, 2012, 10:52:08 PM6/7/12
to
{'name':'aa','status1':bb,'status2':cc...}
dict['name']['statusx'] = xxx
上面这两行怎么矛盾呢？
不是应该是 dict['name'] = "new_aa" 这样吗？
还是里面的key其实是 'name''aa'?
如果是这样的话，memory就花在这个两级的dict上面
不要用两级的dict
做成这样子，dict['name' + '-' + 'aa'] = value
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 标 题: Re: dict太占内存，有啥优化的方法么？
: 发信站: 水木社区 (Fri Jun 8 09:31:09 2012), 转信
:
: 好吧。。。
:
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: 一个{'name':'aa','status1':bb,'status2':cc...}
: 在程序运行过程中，我需要从外部接受更新数据（更新的数据包含'name'信息和部分新'status'的值），然后尽可能快的更新数据表。
:
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: 一个{'name':'aa','status1':bb,'status2':cc...}
:
: 我想最快速的方法应该是建一个大的字典，name做key，然后更新的时候
: dict['name']['statusx'] = xxx
:
: 但是python的dict太费内存，我40w个dict内存大概就占10g以上了，而实际上dict的数据转成文本存在硬盘上也就是几十兆。
:
: 我的question是：python是否有优化的dict提供呢？或者有没有更好的方式来解决这个问题？
:
:
:
: 【 在 pulo (普洛米·我们的民族从来不缺乏苦难) 的大作中提到: 】
: : 什么样的数据？什么样的key？不说清楚别人怎么知道怎么“优化”
:
:
: --
:
: [36m※ 修改:·shinn 于 Jun 8 09:33:22 2012 修改本文·[FROM: 64.104.125.*] [m
: [m [1;31m※ 来源:·水木社区 newsmth.net·[FROM: 64.104.125.*] [m
--
: 我想最快速的方法应该是建一个大的字典，name做key，然后更新的时候
: dict['name']['statusx'] = xxx
:
: 但是python的dict太费内存，我40w个dict内存大概就占10g以上了，而实际上dict的数据转成文本存在硬盘上也就是几十兆。
:
: 我的question是：python是否有优化的dict提供呢？或者有没有更好的方式来解决这个问题？
:
:
:
: 【 在 pulo (普洛米·我们的民族从来不缺乏苦难) 的大作中提到: 】
: : 什么样的数据？什么样的key？不说清楚别人怎么知道怎么“优化”
:
:
: --
:
: [36m※ 修改:·shinn 于 Jun 8 09:33:22 2012 修改本文·[FROM: 64.104.125.*] [m
: [m [1;31m※ 来源:·水木社区 newsmth.net·[FROM: 64.104.125.*] [m
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 116.197.180.*] [m
cwc
Jun 7, 2012, 11:35:42 PM6/7/12
to
redis
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [1;36m※ 来源:·水木社区 newsmth.net·[FROM: 60.194.14.*] [m
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
爱生活 爱c 爱python
Jun 8, 2012, 1:09:51 AM6/8/12
to
这种东西放数据库里比较好吧~
python 作为前端代码调用后台数据库
python 作为前端代码调用后台数据库
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 61.51.67.*] [m
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
frank的爱情故事不会再改变
Jun 8, 2012, 1:48:15 AM6/8/12
to
考虑过数据库，但是存取比内存直接读效率差太多。。。
【 在 CPYTHON (爱生活 爱c 爱python) 的大作中提到: 】
: 这种东西放数据库里比较好吧~
: python 作为前端代码调用后台数据库
--
[m [1;33m※ 来源:·水木社区 newsmth.net·[FROM: 221.216.86.*] [m
【 在 CPYTHON (爱生活 爱c 爱python) 的大作中提到: 】
: 这种东西放数据库里比较好吧~
: python 作为前端代码调用后台数据库
--
[m [1;33m※ 来源:·水木社区 newsmth.net·[FROM: 221.216.86.*] [m
Kneo Fang
Jun 8, 2012, 2:04:18 AM6/8/12
to
对性能的需求有多大？实际的速度有多少？
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 考虑过数据库，但是存取比内存直接读效率差太多。。。
--
[m [32m※ 来源:·水木社区 http://newsmth.net·[FROM: 222.65.244.*] [m
麻吉
Jun 8, 2012, 2:24:54 AM6/8/12
to
redis + redis-py
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [35m※ 来源:·水木社区 http://newsmth.net·[FROM: 202.108.130.*] [m
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
cndenis
Jun 8, 2012, 2:46:12 AM6/8/12
to
dict是以空间换时间，假设一层dict的空间利用率有50%，则二层dict只有25%，三层就只有12.5%……
多层嵌套是很费空间的
试试用内存版的sqlite吧，python自带，要求不高的话是最方便了的
【 在 shinn 的大作中提到: 】
--
Dropbox推荐注册链接：
http://db.tt/HIUr0ez
最优秀的云同步、备份工具
[m [35m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.108.133.*] [m
多层嵌套是很费空间的
试试用内存版的sqlite吧，python自带，要求不高的话是最方便了的
【 在 shinn 的大作中提到: 】
: 好吧。。。
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: 一个{'name':'aa','status1':bb,'status2':cc...}
: ...................
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: 一个{'name':'aa','status1':bb,'status2':cc...}
--
Dropbox推荐注册链接：
http://db.tt/HIUr0ez
最优秀的云同步、备份工具
[m [35m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.108.133.*] [m
xpay
Jun 8, 2012, 2:50:19 AM6/8/12
to
屌都笑歪了！
http://www.newsmth.net/bbscon.php?bid=109&id=37828
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
住她的房，上她的床，开她的车，泡别的妞
[m [32m※ 来源:·水木社区 http://newsmth.net·[FROM: 117.104.188.*] [m
http://www.newsmth.net/bbscon.php?bid=109&id=37828
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [32m※ 来源:·水木社区 http://newsmth.net·[FROM: 117.104.188.*] [m
爱生活 爱c 爱python
Jun 8, 2012, 3:00:31 AM6/8/12
to
你这个是单机查询 还是要提供给多个人查询？
如果是单机的话 肯定sqlite等比你python 要好得多
如果是单机的话 肯定sqlite等比你python 要好得多
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 考虑过数据库，但是存取比内存直接读效率差太多。。。
--
[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 61.51.67.*] [m
: 考虑过数据库，但是存取比内存直接读效率差太多。。。
--
revising hgext.inotify
Jun 8, 2012, 3:31:15 AM6/8/12
to
用('aa', 'status1')做key也不错。可能比拼接字符串效率高一点？
【 在 arp (@arp) 的大作中提到: 】
: {'name':'aa','status1':bb,'status2':cc...}
: dict['name']['statusx'] = xxx
［河中之水歌］ 萧衍
河中之水向东流，洛阳女儿名莫愁。莫愁十三能织绮，十四采桑南陌头。
十五嫁为卢家妇，十六生儿字阿侯。卢家兰室桂为梁，中有郁金苏合香。
头上金钗十二行，足下丝履五文章。珊瑚挂镜烂生光，平头奴子擎履箱。
人生富贵何所望，恨不早嫁东家王。
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 117.104.188.*] [m
【 在 arp (@arp) 的大作中提到: 】
: {'name':'aa','status1':bb,'status2':cc...}
: dict['name']['statusx'] = xxx
: 上面这两行怎么矛盾呢？
: 不是应该是 dict['name'] = "new_aa" 这样吗？
: 还是里面的key其实是 'name''aa'?
: 如果是这样的话，memory就花在这个两级的dict上面
: 不要用两级的dict
: 做成这样子，dict['name' + '-' + 'aa'] = value
--
: 不是应该是 dict['name'] = "new_aa" 这样吗？
: 还是里面的key其实是 'name''aa'?
: 如果是这样的话，memory就花在这个两级的dict上面
: 不要用两级的dict
: 做成这样子，dict['name' + '-' + 'aa'] = value
［河中之水歌］ 萧衍
河中之水向东流，洛阳女儿名莫愁。莫愁十三能织绮，十四采桑南陌头。
十五嫁为卢家妇，十六生儿字阿侯。卢家兰室桂为梁，中有郁金苏合香。
头上金钗十二行，足下丝履五文章。珊瑚挂镜烂生光，平头奴子擎履箱。
人生富贵何所望，恨不早嫁东家王。
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 117.104.188.*] [m
平静的接受失败
Jun 8, 2012, 4:12:12 AM6/8/12
to
你这个里面说的东西是真的假的?
感觉上不可能啊,5G--> 60M,压缩比80:1,还无损
还能高效查找?
【 在 xpay (xpay) 的大作中提到: 】
: 屌都笑歪了！
: http://www.newsmth.net/bbscon.php?bid=109&id=37828
--
I as principal am responsible for the problem, and for the solution.
[m [1;33m※ 来源:·水木社区 newsmth.net·[FROM: 59.108.126.*] [m
感觉上不可能啊,5G--> 60M,压缩比80:1,还无损
还能高效查找?
【 在 xpay (xpay) 的大作中提到: 】
: 屌都笑歪了！
: http://www.newsmth.net/bbscon.php?bid=109&id=37828
--
I as principal am responsible for the problem, and for the solution.
[m [1;33m※ 来源:·水木社区 newsmth.net·[FROM: 59.108.126.*] [m
@arp
Jun 8, 2012, 4:14:50 AM6/8/12
to
nice
【 在 FlyingBoy (revising hgext.inotify) 的大作中提到: 】
: 用('aa', 'status1')做key也不错。可能比拼接字符串效率高一点？
--
[m [1;32m※ 来源:·水木社区 newsmth.net·[FROM: 116.197.180.*] [m
奥路菲
Jun 8, 2012, 5:13:41 AM6/8/12
to
可能是类似LC-trie或者LPC-trie的算法
【 在 hrpenf 的大作中提到: 】
: 你这个里面说的东西是真的假的?
: 感觉上不可能啊,5G--> 60M,压缩比80:1,还无损
: 还能高效查找?
: ...................
--
[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 211.144.202.*] [m
【 在 hrpenf 的大作中提到: 】
: 你这个里面说的东西是真的假的?
: 感觉上不可能啊,5G--> 60M,压缩比80:1,还无损
: 还能高效查找?
: ...................
--
[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 211.144.202.*] [m
Kneo Fang
Jun 8, 2012, 5:19:40 AM6/8/12
to
萬一
Jun 8, 2012, 5:41:55 AM6/8/12
to
可以考虑改成dict[("name", "status")] = "value"这种方式，空间效率估计可以好不少。
【 在 shinn 的大作中提到: 】
: 好吧。。。
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: 一个{'name':'aa','status1':bb,'status2':cc...}
: ...................
--
[m [31m※ 来源:·水木社区 http://newsmth.net·[FROM: 123.117.75.*] [m
【 在 shinn 的大作中提到: 】
: 好吧。。。
: 情况是这样，我需要在内存中维护一个40w条左右的数据表，数据表大小在整个程序运行周期基本不变。每条数据是一个比较简单的数据结构，我们可以想象成
: ...................
--
[m [31m※ 来源:·水木社区 http://newsmth.net·[FROM: 123.117.75.*] [m
frank的爱情故事不会再改变
Jun 8, 2012, 5:53:21 AM6/8/12
to
感谢这位大侠和上面另外一个兄弟的思路，也感谢大家的回复，感觉这个方法最为靠谱，回头试试。。。
【 在 lOOOO (萬一) 的大作中提到: 】
: 可以考虑改成dict[("name", "status")] = "value"这种方式，空间效率估计可以好不少。
--
[36m※ 修改:·shinn 于 Jun 8 17:53:21 2012 修改本文·[FROM: 64.104.94.*] [m
[m [1;34m※ 来源:·水木社区 newsmth.net·[FROM: 64.104.94.*] [m
【 在 lOOOO (萬一) 的大作中提到: 】
: 可以考虑改成dict[("name", "status")] = "value"这种方式，空间效率估计可以好不少。
--
[36m※ 修改:·shinn 于 Jun 8 17:53:21 2012 修改本文·[FROM: 64.104.94.*] [m
[m [1;34m※ 来源:·水木社区 newsmth.net·[FROM: 64.104.94.*] [m
平静的接受失败
Jun 8, 2012, 6:10:20 AM6/8/12
to
现在的url已经是非常杂乱,没有规律,80:1的压缩比例太恐怖了
希望这位兄弟能具体说说,让长长见识
【 在 Orpherus (奥路菲) 的大作中提到: 】
: 可能是类似LC-trie或者LPC-trie的算法
希望这位兄弟能具体说说,让长长见识
【 在 Orpherus (奥路菲) 的大作中提到: 】
: 可能是类似LC-trie或者LPC-trie的算法
阿水
Jun 8, 2012, 10:20:31 AM6/8/12
to
我想问你一个问题，这么大的数据量你为啥要一次运算，或者为啥不放数据库里面……
【 在 shinn 的大作中提到: 】
【 在 shinn 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
:
--
[m [35m※ 来源:·水木社区 http://newsmth.net·[FROM: 59.40.231.*] [m
: 尝试numpy，但是没有好的方法解决查找效率。。
:
--
据说是小 X
Jun 10, 2012, 12:16:13 AM6/10/12
to
re redis
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
【 在 shinn (frank的爱情故事不会再改变) 的大作中提到: 】
: 为了查找效率问题，建了一个大约40w key左右的一个大型字典。。内存果断上10g了。。有什么好方法解决？
: 尝试numpy，但是没有好的方法解决查找效率。。
--
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 59.78.37.*] [m
: 尝试numpy，但是没有好的方法解决查找效率。。
--
0 new messages