過去一年，重新投入軟體開發的懷抱，因為工作需要，有很多時間都需要接觸MongoDB，遙想四年前，還是各家NoSQL大戰，在那個勝負不明的時期，就有小試了一下MongoDB，只是沒想到他能夠撐那麼久，並且讓那麼多公司採用，還頗讓人驚訝的。
MongoDB是NoSQL中偏向document-level的一隻， 先講講優點好了
1. scheme-less 算是他最大的好處，以往開發程式，為了決定資料的scheme，常常要花一番工夫，而當之後要改scheme，又是另外一個麻煩的事情，更者關聯式資料庫常常會陷入要不要正規化的矛盾中，對於一些小型程式要做快速開發算是額外的overhead。
2. 容易上手，MongoDB的query的語法設計的非常好，加上對於不同程式語言的Driver都有一定要求，簡單的command如find，update，delete都非常容易實現，而且也不容易有SQL injection的問題，不過使用PHP或Perl的人可能會詬病使用 $ 當作運算元。
3. 容易水平擴充，由於一開始的設計就是為了能夠很好的scale，MongoDB在處理replica（複製），sharding（資料庫分割）方面算是下了不少工夫, 在sharding部分採用自己設計的Bson index, 而不像一般資料庫用incremental的id，就是為了能夠很好的自動處理sharding， 雖然早期被人詬病auto sharding很不給力，不過到了2.4後多了hash index，成功地解決了這個問題。
4. Fail over的機制完備，在使用官方推薦的replica set狀態下，三台機器中，當Primay機器下線後，會自動選出新的Primary機器。
接著是討論一下缺點
1. scheme-less聽起來好像很不錯，但是其實scheme-less是scheme-plus，需要在每個document中塞入data的scheme，相對上面是浪費空間，所以MongoDB官方才會推薦，要把key設越短越好，以節省硬碟還有記憶體的使用量。
2. 不同的scheme塞入同一張collection內，容易造成Disk和Memory的Fragmentation，進而使效率降低，不同版本的資料還需要在程式邏輯端去避開，強烈建議scheme在脫離prototype後，一定要有固定的格式。
3. Mongodb完全靠Mmap處理檔案操作，並沒有對Disk IO操作或是容量有什麼過多的設計，而對於硬碟空間就是浪費過多，加上Index tree是傳統B-tree結構，在硬碟的讀寫上沒有做任何優化，導致request增加，就需要對硬體做升級。
4. 一樣是B-tree的問題，當資料量大到一定時，讀寫就會變慢，就不得不做sharding或是將硬體升級，另外range query並沒有辦法做最佳化，需要常常做range query操作的資料，要好好考慮是否使用MongoDB
5. 目前2.4支援collection lock，lock系統也是MongoDB的濫傷，從一推出的Global lock，過了四五年了，還沒進化到document level的lock，就寫入而言就是只有悲劇可言，目前的Roadmap是說2.8就會把這個解掉。
MongoDB是NoSQL中偏向document-level的一隻， 先講講優點好了
1. scheme-less 算是他最大的好處，以往開發程式，為了決定資料的scheme，常常要花一番工夫，而當之後要改scheme，又是另外一個麻煩的事情，更者關聯式資料庫常常會陷入要不要正規化的矛盾中，對於一些小型程式要做快速開發算是額外的overhead。
2. 容易上手，MongoDB的query的語法設計的非常好，加上對於不同程式語言的Driver都有一定要求，簡單的command如find，update，delete都非常容易實現，而且也不容易有SQL injection的問題，不過使用PHP或Perl的人可能會詬病使用 $ 當作運算元。
3. 容易水平擴充，由於一開始的設計就是為了能夠很好的scale，MongoDB在處理replica（複製），sharding（資料庫分割）方面算是下了不少工夫, 在sharding部分採用自己設計的Bson index, 而不像一般資料庫用incremental的id，就是為了能夠很好的自動處理sharding， 雖然早期被人詬病auto sharding很不給力，不過到了2.4後多了hash index，成功地解決了這個問題。
4. Fail over的機制完備，在使用官方推薦的replica set狀態下，三台機器中，當Primay機器下線後，會自動選出新的Primary機器。
接著是討論一下缺點
1. scheme-less聽起來好像很不錯，但是其實scheme-less是scheme-plus，需要在每個document中塞入data的scheme，相對上面是浪費空間，所以MongoDB官方才會推薦，要把key設越短越好，以節省硬碟還有記憶體的使用量。
2. 不同的scheme塞入同一張collection內，容易造成Disk和Memory的Fragmentation，進而使效率降低，不同版本的資料還需要在程式邏輯端去避開，強烈建議scheme在脫離prototype後，一定要有固定的格式。
3. Mongodb完全靠Mmap處理檔案操作，並沒有對Disk IO操作或是容量有什麼過多的設計，而對於硬碟空間就是浪費過多，加上Index tree是傳統B-tree結構，在硬碟的讀寫上沒有做任何優化，導致request增加，就需要對硬體做升級。
4. 一樣是B-tree的問題，當資料量大到一定時，讀寫就會變慢，就不得不做sharding或是將硬體升級，另外range query並沒有辦法做最佳化，需要常常做range query操作的資料，要好好考慮是否使用MongoDB
5. 目前2.4支援collection lock，lock系統也是MongoDB的濫傷，從一推出的Global lock，過了四五年了，還沒進化到document level的lock，就寫入而言就是只有悲劇可言，目前的Roadmap是說2.8就會把這個解掉。
