开篇有益:为何选择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的一个参考。