開篇有益:為什么選擇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的一個參考。