本章內容
MongoDB的歷史、設計目標和關鍵特性
MongoDB Shell和驅動的簡要介紹
MongoDB的使用場景及其局限性
近幾年，如果構建Web應用程序，你可能會選擇關係型數據庫作為主要數據存儲方案，而且它的表現通常也能接受。大多數開發者都熟悉SQL，能體會到精心正規化（normalized）後的數據模型所散發出的美感，瞭解事務的必要性，知道持久化存儲引擎提供的保證。就算我們不喜歡直接和關係型數據庫打交道，也能找出很多工具幫助我們降低複雜度，上至管理控制台，下至對像關係映射器。簡言之，關係型數據庫十分成熟且有口皆碑。因此，當一小群有主見的骨幹開發者開始提倡另一種數據存儲時，便有人提出了關於這些新技術的可行性和實用性的問題。這些新數據存儲是關係型數據庫的替代品嗎？誰在生產環境中使用它們，為什麼選擇它們？在向非關係型數據庫的遷移過程中又要做哪些權衡？上述問題的答案都可以建立在這個問題的答案上：為什麼開發者對MongoDB感興趣？
MongoDB是一款為Web應用程序和互聯網基礎設施設計的數據庫管理系統。MongoDB的數據模型和持久化策略的設計目標是提供高讀寫吞吐量，在易於伸縮的同時還能進行自動故障轉移。無論應用程序只需要一個還是幾十個數據庫節點，MongoDB都能提供驚人的性能。如果你對擴展關係型數據庫的艱辛深有體會，一定會覺得這是個好消息。但並非每個人都需要擴展數據庫，也許需要的就只是一台數據庫服務器，那麼為什麼要使用MongoDB呢？
MongoDB之所以一下子這麼引人注意，並不是因為它的擴展策略，而是因為它那直觀的數據模型。假設基於文檔的數據模型可以表示豐富的、有層級的數據結構，那麼拋棄關係型數據庫所強加的複雜的多表關聯就成為了可能。舉例來說，假設你正在為一個電子商務網站做產品建模，如果使用完全正規化的關係型數據模型，任何產品的信息可能都會被打散到多張表中。如果想要從數據庫Shell裡獲得產品表述，我們需要寫一句由join堆砌而成的複雜SQL查詢。其結果就是，大多數開發者需要依賴軟件中的輔助模塊將數據組裝成有意義的東西。
相比之下，使用文檔模型的話，大多數產品信息都能放在一個文檔裡。打開MongoDB JavaScript Shell，可以輕鬆獲得產品的完整表述，所有信息都按層級用一種類似JSON1的結構組織在一起。對於這樣組織的所有信息，既可以做查詢，也可以做其他操作。MongoDB的查詢是專門為操作結構化文檔而設計的，因此從關係型數據庫切換過來的用戶能有與之前類似的查詢體驗。此外，大多數開發者現在都使用面向對象的語言，他們想要一個能更好地映射到對象的數據存儲。有了MongoDB，編程語言中定義的對象能被「原封不動」地持久化，消除掉一些對像映射程序的複雜性。
1. JSON是JavaScript Object Notation的縮寫。我們馬上就會看到，JSON結構由鍵和值組成，它們可以任意嵌套。JSON類似於其他編程語言中的字典（dictionary）和散列圖（hash map）。
如果你對表列數據（tabular）和數據的對象表示之間的區別還很陌生，那麼肯定會有很多問題。在本章末尾，我將給出MongoDB的特性和設計目標的完整概述，讓你更清楚地明白為什麼像Geek.net（SourceForge.net）和紐約時報（The New York Times）這樣的公司的開發者要在他們的項目中使用MongoDB。我們將瞭解MongoDB的歷史，認識它的主要特性。接下來，我們還要瞭解一些其他的數據庫解決方案和所謂的NoSQL運動2，我會解釋MongoDB在其中發揮的作用。最後，我還將概括說明MongoDB適用於哪些場景，在哪些場景下其他數據存儲又可能會更合適一些。
2. NoSQL這個詞出現於2009年，當時很多非關係型數據庫越來越流行，NoSQL是它們的總稱。