开篇有益:为什么选择MongoDB?

小雨点点789

为啥用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存储
  

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

• 使用关联表
  

• schema自由度有限，类型控制
  
• 更新频繁，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的一个参考。