hanyueqi的专栏

1、MongoDB Sharding基本共识随机I/O转为顺序I/O；步骤越少，查询越简单，性能越高。多做不如少做，少做不如不做；大数据查询，分布式并行查询能力高；三个注意事项插入文档必须带上sharding key不接受修改片键值（读取、删除、插入新文档）如果文档中包含不同类型的值，排序规则，按照类型排序，同类型与大家期望相同；ChunkSize选择

1、masterslave截图master配置文件：dbpath=../data_test/db/masterlogpath=../data_test/master.logport=8642logappend=trueoplogSize=2048storageEngine=wiredTigernojournal=trueslave配置文件：dbpath=

1、启动mongodb服务，查看使用mongofiles查看文件列表；之后分别存储mongod.pdb,spring-tool-suitXX，两个文件，文件大小分别为100M+，400M+；2、从日志中可以看出文件分别依次创建64M、128M、256M、512M大小的文件；3、连接Mongodb，查看fs文件内容：

MongoDB中基本的文件操作有put、get、list、search几种，可以很方便地进行文件存储于查找，以下是一个简单的示例。1、利用dd命令生成要求大小随机文件 2、使用put命令将生成文件依次写入mongodb中filetest数据库中3、使用list命令将数据库中文件列出4、使用get命令下载文件5、使用search命令查找文件

1、MongoDB在Linux下的安装配置应用shutdown kill -2/-4use admin； db.shutdownServer();kill -9 可能会导致数据丢失、文件损坏、之后需要进行修复；2、MongoDB体系结构解读跨平台数据库Linux、Unix、Max、Windows整体架构相同MongoDB Server实例、数据库

1、MongoDump      使用MongoDump进行数据导出，总是在导出某些集合的时候出现问题，意外终止，分析问题：      集合问题，是否是名称或集合里面数据有问题，经检验单独导出该集合没有任何问题；      Baidu，Google后均为果，只能自己思考。      比较诡异问题：每次dump必断，而且会搞垮整个mongodb服务器；      经排查，同事没有

1、软件方面MongoDB版本选择锁粒度Global（2.2-）DB锁（2.2+）Collection（2.4+）Document锁（2.6+）读写锁、写优先锁性能逐渐增强启发尽量选择新的稳定版本性能提升稳定bugs fixed索引创建设计不合理长索引字符串等idobjectid12字节应用程序替换月业务需要uid灵活

1、主要特性性能提升7-10倍；数据压缩率80%；减少95%运维成本；插件式存储引擎：Wired Tiger文件锁磁盘压缩可配置内存使用上限MMAPV1存储引擎优化库级锁到表级锁文档分配方式优化副本集优化、集群优化、其他优化2、MongoDB3.0部分性能测试情况写入特性数据压缩运维速率提升3、特点可插入新的存储引擎（Wired Tiger）文档级别锁S

什么情况下需要做版本升级稳定性提升MongoDB比较年轻，稳定性方面问题相对较多稳定性是什么进程崩溃进程异常系统上下文频繁切换，CPU占用率高MongoDB新版本稳定性提升线下充分的验证测试性能提升表现那些方面（相同条件下）吞吐量增加CPU占用量减少内存占用减少磁盘I/O利用率更高LOCK变少MISS减少FAULT较少MongoD

1、什么情况下需要进行扩容数据量接近单机磁盘总容量数据容量接近磁盘容量80% df内存使用量接近内存容量80% free访问量 iostat -xdk 1storage与datesize两倍左右关系2、常用的MongoDB集群扩容方案Scale UpScale Out读密集型单节点无法应对所有操作即便hotdate index已经加载到内存中

1、大量删除数据问题及解决方案在线消息定时删除请求量增加，垃圾数据需要进行删除离线批量删除msgidcontenttimestampflagobjectidfromto针对flag=1时进行删除时的问题，并非索引或者分片结果；更新方式业务层优化逻辑删除转为直接物理删除离线删除优化每晚定时从库导出要删除的数据通过脚本按照obje

1、监控的目的即使获取应用程序运行状态，问题出现时及时发现；被动、主动监控没有监控不能及时掌握运行情况问题不能及时发现、解决用户上报被动监控什么机器资源及时发现机器资源不足CPU、内存、硬盘I/O、网络I/O等；MongoDB应用程序进程管理重启aliveps -aux|跟人跑mongod语义监控进程管理是否正常工作模拟发

1、Collection Sharding是否靠谱Sharding key的一些烦恼；单一key可能导致分布不均匀；使用符合Sharding KEY复合sharding key也不是万能的；Count计算性不准确；Balancer不够智能，时间不确定；禁用Auto-Sharding功能不可靠（尤其是2.X版本）；线上禁用Auto-Sharding开启库级Sharding；固

1、游标关系型数据库：解决to many rows，cursor跟select语句捆绑（结果集放入游标区）；Mongdb游标：find()结果集，结果不会被掏空，通过haseNext()判断；limit(3),skip(3),sort({})；分页当skip数据量较大时，先选择然后再分类；Math.random()进行随机操作；max_scan;2、一致性查询（较长）