【IT168 評論】對于只有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在電子商務和游戲世界是一個受歡迎的選擇,因為它能夠利用大量數據進行水平擴展.