Jangogo : 

第一条:划分shard,使用replSet,保证服务不会全部失效,存储容灾很关键。

第二条:大表要分表,划分ReplSet之后,表还是只存在于一个shard中。小表看需要。

第三条:良好的键值设计,字段名称要短,不要用传统的数据库方式思考。一切能key-value的就不要考虑条件查询神马。索引再好也是比较,能定位到就不要比较,可以通过限制一些功能的方式来满足。

第三条:关于写可靠性问题。尽量不要开启获取写结果,MongoDB是锁库写,同步获取结果会对全库的其他操作有影响。

第四条:索引很好,但还是要减少它的使用,不要为了一些低频度非关键功能设计额外索引。海量数据下,索引占用空间也是非常可观的,更主要的是它占的是内存空间。这本身会造成热点数据的减少。

第五条:MongoDB总连接数的控制,Linux下一个连接大约堆栈开10M空间,这里如果连接数很多的话,建议把堆栈大小设小。

第六条:MongoDB能嵌套的地方尽量不要整引用,完全杜绝跨库引用。简单是数据可靠高效的前提。海量背景下,简单就会意味着高效、可靠。

第七条:MongoDB java client端每个应用服务器一个Mongo实例就足够,其内置了连接池,只需要对其进行配置即可满足并发场景支持,单机一般不超过100,其实多实例场景50-70绰绰有余。池化的思想到哪都不会错,只要不用错。

第八条:读写配置可分开,老版本slaveOk就可以,新版本的话有个ReadPreference.SECONDARY,配置后即可简单的读写分流了。

第九条:数据库统计数据很重要,MongoDB支持的非常好,java client端通过mongo实例获得全库的数据描述,也可以获得某个collection的数据描述,时时关注比le it alone要好很多。

第十条: 不要怕手工方案麻烦,演练好预案,任何未经严格验证+线上复杂场景的自动化方案都是不靠谱的,多做容灾,异常备案比神马都好。

文档中心
可上传附件
选择
同时转发此条
回复
1楼
Jangogo: 
mongodb查询速度慢是什么原因? 通过mongodb客户端samus代码研究解决问题 最近有项目需要用到mongodb,于是在网上下载了mongodb的源码,根据示例写了测试代码,但发现一个非常奇怪的问题:插入记录的速度比获取数据的速度还要快,而且最重要的问题是获取数据的速度无法让人接受。 测试场景:主文档存储人员基本信息,子文档一存储学生上课合同数据集合,这个集合多的可达到几百,子文…【更多】
Copyright © 2000-2016 粤ICP05021785号
地址:广州市天河区员村二横路8号全丰商业大厦808室 邮编:510600