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