前言

       

        在项目选型阶段，MongoDB被选中主要是基于其处理大规模数据集的能力，而当时并未深入探讨其他替代方案。此前，Redis被用于管理少量但访问频繁的热数据。目前，项目采用MongoDB存储百万级数据，预计未来数据量将增长至千万级甚至亿级。

        通常，Redis被定义为缓存系统，而MongoDB则被视为数据库系统，这种区分是有其合理性的。Redis将数据主要存储于内存中，其核心功能更偏向于缓存，数据操作简单快捷，类似于变量操作。相对地，MongoDB是一个功能全面的数据存储解决方案，支持复杂的增删改查操作，可通过多种条件进行数据筛选，其灵活性与传统SQL数据库相似，这一特点在技术面试中常被提及并受到重视。

比较

指标	MongoDB（v2.4.9）	Redis（v2.4.17）	比较说明
实现语言	C++	C/C++	-
协议	BSON、自定义二进制	类Telnet	-
性能	依赖内存，TPS较高	依赖内存，TPS较高	Redis优于MongoDB
可操作性	丰富的数据表达、索引；最类似于关系数据库，支持丰富的查询语言	数据丰富，较少的IO	MongoDB优于Redis
内存及存储	适合大数据量存储，依赖系统虚拟内存管理，采用镜像文件存储；内存占有率比较高，官方建议独立部署在64位系统（32位有最大2.5G文件限制，64位没有该限制）	Redis2.0后增加虚拟内存特性，突破物理内存限制；数据可以设置时效性，类似于memcache	不同的应用角度看，各有优势
可用性	支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制	依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制；不支持自动sharding,需要依赖程序设定一致hash机制	MongoDB优于Redis；单点问题上，MongoDB应用简单，相对用户透明，Redis比较复杂，需要客户端主动解决。（MongoDB 一般会使用replica sets和sharding功能结合，replica sets侧重高可用性及高可靠性，而sharding侧重于性能、易扩展）
可靠性	从1.8版本后，采用binlog方式（MySQL同样采用该方式）支持持久化，增加可靠性	依赖快照进行持久化；AOF增强可靠性；增强可靠性的同时，影响访问性能	MongoDB优于Redis
一致性	不支持事务，靠客户端自身保证	支持事务，比较弱，仅能保证事务中的操作按顺序执行	Redis优于MongoDB
数据分析	内置数据分析功能（MapReduce）	不支持	MongoDB优于Redis
应用场景	海量数据的访问效率提升	较小数据量的性能及运算	MongoDB优于Redis

生活中总是充满了各种选择，点餐纠结，出行选择，聚餐座位，团队投票结果不明，随机抽签一锤定音等等！为了解决这个问题，我开发了一款【随机选择决定转盘工具】微信小程序，随机做出决策！无论是随机抽选还是投硬币，都能轻松搞定。现在通过微信小程序二维码就能体验！快来试试吧，让选择变得更简单！