Mongodb學習總結（2）——MongoDB與MySQL區別及其使用場景對比
對於只有SQL背景的人來說，想要深入研究NoSQL似乎是一個艱鉅的任務，MySQL與MongoDB都是開源常用資料庫，但是MySQL是傳統的關係型資料庫，MongoDB則是非關係型資料庫，也叫文件型資料庫，是一種NoSQL資料庫。它們各有優點，關鍵看用在什麼地方。
什麼情況下，MongoDB是最好的選擇?
很多人認為MongoDB難以置信的強大，是一個可擴充套件，介面互動友好的資料庫解決方案。當開發人員需要負責管理資料庫環境時，MongoDB是一個不錯的選擇。起碼在小型企業和初創公司，是這樣。MongoDB將資訊儲存在BSON(二進位制JSON)中。BSON是一種類JSON二進位制形式的儲存格式，簡稱Binary JSON，它和JSON一樣，支援內嵌的文件物件和陣列物件，但BSON有JSON沒有的一些資料型別，如Date和BinData型別。JSON很容易與其他程式語言關聯，許多開發人員都有使用JSON的經驗。
當你的程式有大量流量寫入時，MongoDB也是一個很好的選擇。這並不是說MySQL在處理頻繁寫入環境方面不是一個好的選擇，只是說MongoDB相對更容易一些。Facebook為寫負載過重的環境設計了RocksDB儲存引擎，效能還不錯(通過基準測試證明了這一點)。
當你需要一個無模式或模式靈活的資料結構時，MongoDB是一個不錯的選擇。MongoDB對資料結構的更改相對輕鬆和寬容，這是NoSQL解決方案的賣點。在MySQL世界中有許多改進使線上模式更改成為可能，只建立記錄而不定義結構增加了MongoDB的靈活性。
選擇MongoDB的另一個原因是它具有設定複製環境，內建分片和自動選擇方面的功能。在MongoDB中設定複製環境很容易，自動選擇過程允許從資料庫在主資料庫故障的情況下接管。內建分片允許簡單的橫向擴充套件。在MySQL環境中管理，設定和配置會很複雜。
什麼情況下不能選MongoDB?
對某些用例而言，MongoDB是不錯的選擇，但它也不是萬能的。當資料高度關係化和結構化時，MongoDB就不是最佳選擇。MongoDB不支援事務，但在文件級別，具有原子性。對於複製環境，有關寫入問題的配置注意事項都是以犧牲效能為代價的。寫入方面將驗證副本是否已寫入資訊，預設情況下，MongoDB將寫請求設定為僅從主計算機請求確認，而不是副本。因為如果副本有問題，就會導致一致性問題。
二者結構有何不同?
SQL中的許多概念都與MongoDB的文件結構相關。讓我們來看一個簡單的MongoDB環境結構，以更好地瞭解MongoDB的佈局。
下面的圖表涉及MySQL與MongoDB的不同點：
除此之外，另一個有趣的地方是mongod程序。這是一個處理資料請求的守護程序，與MySQL的mysqld程序大致相同，是監聽MongoDB請求並管理資料庫訪問的程序。和MySQL一樣，mongod程序有很多啟動選項。最重要的配置選項之一是config，它是專門用於mongod例項的配置檔案。與MySQL稍有不同，此檔案使用YAML格式。下面是MongoDB配置檔案示例。請注意，這是演示格式化，它並未針對任何生產資料庫進行優化。
根據定義，MongoDB是一個基於分散式檔案儲存的資料庫。可以立即將文件插入到集合中，而無需建立表和新增資料，無需定義結構。這是MongoDB與MySQL相比的優點之一，更加靈活。要注意，MongoDB提供的這種靈活性並不意味著組織一個功能強大的MongoDB資料庫毫不費力。選擇任何資料庫，都應該考慮資料庫的結構和目標。
# mongod.conf, Percona Server for MongoDB
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
engine: rocksdb
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
processManagement:
fork: true
pidFilePath: /var/run/mongod.pid
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1
注意：YAML格式化不處理選項卡，使用空格縮排。
查詢方式有何不同?
通過shell與資料庫互動與SQL略有不同，以下是從SQL翻譯為MongoDB的查詢示例，其中使用了一個只有使用者名稱和相關ID的使用者表。
In SQL:
select username from user where id = 2;
In MongoDB:
db.user.find({_id:2},{“username”:1})
在JSON格式中，我們指定要查詢的使用者集合，然後指定與我們感興趣的文件相關聯的ID。最後，指定從中獲取值的欄位，此查詢結果將是ID為2的使用者的使用者名稱。
總結
MongoDB不是MySQL的影子，也不是MySQL的替代品，隨著兩個資料庫的不斷髮展，它們的優劣慢慢融合在一起。MySQL使用者可以在MongoDB上測試各種例項，但不鼓勵盲目追求MongoDB的靈活性。儘管MongoDB在電子商務和遊戲世界是一個受歡迎的選擇，因為它能夠利用大量資料進行水平擴充套件。