其實MongoDB剛出來的時候有幾點有吸引到我

1. Schemaless: 不得不說有些應用用這個很好用。例如你的資料來源本身就是json，並且可能偶而會在來源端修改Schema。例如，Facebook Feed。在之後分析的時候，可以透過特殊的Query語法來達到in json document的query。而且可以針對Document裡面的一個path去做index，甚至可以對array做index，這點那時候的確讓我驚艷。
2. Sharding: RDBMS這個真的不容易做的好，因為需要Join。而且要怎麼設定Partition key本身就不易。所以NoSQL在這邊比較容易做得好。

但是我覺得最令我詬病的是

1. Query很難用。永遠背不起來的query語法。而且用json格式真的很難寫。Aggregation pipeline跟sql group by比起來真的難寫爆多的。更何況無法做類似subquery跟join。
2. 部署困難。如果資料量大到需要Sharding，部署成本難超多。若是要再加上replica set。那更是超難運作。我相信沒有幾個人會想這樣部署。

所以MongoDB對我來想，目前最好的地位是分析資料庫。也就是你可以把一堆的JSON資料塞進去，然後在裡面去做你想要的AdHoc Query。所以對於分析統計semi-structured的資料我想是目前最適合他的角色。但是PostgreSQL9.4出了以後jsonb，又有json的query好處，又可以做傳統的table join，那真的是又比MongoDB更實用，重點是有SQL。

如果往上看收集raw log的需求，MongoDB還是Row-based DB。這種型態的DB就是CRUD都是對同樣一個地方去做存取。就會遇到Data Fragmentation的問題，所以資料量一大，一定會遇到越來越慢。雖然可以透過定時去rebuild database。但是跟cassandra/hbase這種bigtable-like的還是不能比。所以真的有更大資料量的需求，我建議直上cassandra/hbase。或是更極端的用HDFS或是雲端Storage(首推AWS S3, Azure BlobStorage，因為這些Hadoop有內建FileSystem)。

Anyway，MongoDB 3.0雖然改善了很多Storage的效能問題。但是本質上的問題沒有解決，那就是沒有SQL，沒有Reliational的功能，再來是Row-based的本質跟RDBMS差距不大。但在RDBMS越做越強，主流DB都開始支援JSON的情況下，那他的特色就不是特色了。反而是他沒有的反而是他的負面特色。