为什么选择MongoDB?

为什么选择MongoDB?

阅读目录

• 开始
• 为啥用MongoDB？
• 原来的架构
• 新需求
• 如何解决?
• 新思路
• 选型条件
• 一些候选者
• 最初的选择
• 代价
• 新的候选者
• 重新选择
• 胆子大一点
• 胆子再大一点
• 胆子再更大一点
• MongoDB,就是它了

回到顶部

为啥用MongoDB？

赶NoSQL时髦? 
Auto-shard等激动人心的特性? 
•No! 08年，还都是浮云。 
最初的想法是寻找一个可靠的分布式K/V解决MySQL的问题。

NoSQL(NoSQL = Not Only SQL )，意即反SQL运动，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

所以说，NoSQL不仅仅是产品，更是一项运动!

回到顶部

原来的架构

•MySQL（Percona），

Master-Master-Slaves

•HA:MMM

回到顶部

新需求

• 能够适应多数据源
• 需要灵活，不确定的schema：不同模型的字段不定，属性不定
• 属性更新频繁
• 服务器等硬件资源有限

回到顶部

如何解决?

原有MySQL的方案：

• 使用文本字段，JSON存储

1. schema自由度高
2. 更新容易，直接检索困难

• 使用关联表

1. schema自由度有限，类型控制
2. 更新频繁，query缓存失效

回到顶部

新思路

继续使用Memcached？

• 缓存失效，内存不足

决定：寻找Memcached替代品

• 能够持久化的分布式KV

回到顶部

选型条件

• 同时有PHP/Perl/DotNet/JAVA的良好客户端支持
• 性能和Memcached相差不要太
• 支持分布式集群
• 低碳环保，节约资源
• 文档清晰，有成功案例

回到顶部

一些候选者

• Flare
• Repcached
• Redis
• TC/TT

回到顶部

最初的选择

选中Flare：

• 内置cluster看起来很美好,可靠性有保 
  证
• 使用Memcached协议，现有改动小

回到顶部

代价

项目开发1个月后：

• 官方更新显示似乎并非如此可靠
• 水土不服：

（1）个人能力有限，无法解决一些灵异事件

（2）没有开发者社区

（3）不懂日文

回到顶部

新的候选者

• Cassandra：技术实力无法支撑，用不起
• CouchDB：灵活，但性能口碑似乎不佳

回到顶部

重新选择

MongoDB：

• 读写性能中庸，比Redis逊色
• Document模型令人满意
• 内置操作没有Redis惊喜，基本够用
• MySQL类似的集群机制,上手方便
• 某些MySQL的优化部署经验可以复用

回到顶部

胆子大一点

MySQL ＋MongoDB?

• 多余：很多MySQL的操作MongoDB均 
  可实现
• 同时维护MySQL <=> MongoDB 的数 
  据，代码逻辑有些复杂
• 人员流失，培训新人表示鸭梨大

回到顶部

胆子再大一点

能否彻底抛弃MySQL?

• Transaction？可以没有
• Joins？ 原本少用，可以没有
• 数据一致性：不太高

回到顶部

胆子再更大一点

好吧，试试：

• 拿一个旧项目开刀
• 1人1个星期完成90%代码移植
• 原有35个table => 10 collection
• 开发过程很happy!

回到顶部

MongoDB,就是它了

一举两得的加分项：GridFS

• 简单，符合我们的要求
• 无需再考虑分布文件系统
• 放弃了原来的MogileFS，减轻运维压 
  力

综上原因，选对了!

• SourceForge等一些大站应用增强信心
• 分享的信息逐渐丰富
• 10gen核心团队在mailing-list快速响应， 
  有问必答
• NoSQL开始受到追捧，MongoDB的口 
  碑良好

本文参收集网络资料整理，作为我选择MongoDB的一个参考。