约1亿条记录,每条1k左右,key=>value形式,用于前台查询,选择什么作为存储方案比较合适呢,要求效率比较高并且相对稳定可靠?
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了约1亿条记录,每条1k左右,key=>value形式,用于前台查询,选择什么作为存储方案比较合适呢,要求效率比较高并且相对稳定可靠?,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1927字,纯文字阅读大概需要3分钟。
内容图文
![约1亿条记录,每条1k左右,key=>value形式,用于前台查询,选择什么作为存储方案比较合适呢,要求效率比较高并且相对稳定可靠?](/upload/InfoBanner/zyjiaocheng/209/d236574ce2f74c06a8d3a9533f1d33b2.jpg)
回复内容:
对于这个小问题, 如果 key 比较小, 可以将所有 key-pos 放内存, pos 为文件中 value 的偏移, 每次访问只需要一次磁盘seek.用 protocol-buf 或 thrift 架成网络服务, 还可以加一层proxy, 按 key hash 分发到不同的服务器来减小压力.
嗯, 好像这些, beansdb 都已经做好了. 数据之间没有强关联,这种情况下用mongo+redis是比较合适的,热点数据保留在redis里,其他数据md5分散到若干台mongodb. 然后请求分散到不同的mongodb上.
扩展也方便 1.总元数据量是100G不到,加上主键索引的话,预计100G-120G
2.每天需要从文件导入一次,目前想到使用mysql分表存储,不知道有没有更好的办法 ?这个不太清楚,是当下已经有1亿条记录,还是每天累加在一起之后,可能为1亿条记录
这个非常关键,若是每天累计在一起是1亿条记录,且是按PK查询查询的话,没有必要分表
3.非常关键的一点,只有查询 还是可能也提供其他的操作,比如UPDATE,INSERT,一定要确认清楚
4.查询的话是按PK单条的方式,还是大批量的读出,关键点是否需要GROUP BY 统计,ORDER BY 分页
5.主键是否简单比如1个或2个整型字段的模式
6.采用MySQL的话,若是非常简单的查询,且按PK,可以考虑采用Handlersocket的模式,对于复杂的建议走SQL协议...
推荐handlersocket的技术文章资料:
HandlerSocket的原理等系列篇章
http://www.mysqlops.com/2011/10/19/handlersocket-principle.html
1. mongodb+redis
更酷,且对于你的场景来说,没有风险(即使丢失1天数据,也可以重新导入),成熟可靠.
mongodb存储数据(须使用主从or replication set),redis做cache.
2. mysql+memcached.
毫无疑问可以实现你的需求. 倒入之后只读的?用 java 随便写一个就可以了吧。index 放在内存,数据放在硬盘。如果访问有冗余,加个 cache 就好了。 使用Redis+Mysql吧,Mysql作磁带,Redis做前台的查询,比较合适。稳定,快速。 推荐用redis,它把k-v数据缓存在内存里面,性能很高,技术成熟稳定好,支持主从同步 http://www.thuir.org/thuirdb/
刚在微博上看到的,非常符合你的需求。
当然,不推荐使用不成熟的技术。 mark mysql用来存数据,redis用来查询,纯内存操作,速度绝对快!
缺点是硬件投入较大,1亿条数据全得存到redis服务器的内存里,redis里用不上的功能,全部不用。
内容总结
以上是互联网集市为您收集整理的约1亿条记录,每条1k左右,key=>value形式,用于前台查询,选择什么作为存储方案比较合适呢,要求效率比较高并且相对稳定可靠?全部内容,希望文章能够帮你解决约1亿条记录,每条1k左右,key=>value形式,用于前台查询,选择什么作为存储方案比较合适呢,要求效率比较高并且相对稳定可靠?所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。