14
[碎唸] 如果讓我再來一次,我會選 PostgreSQL。 (bone.twbbs.org.tw)
popcorny 積分 11 編輯於

其實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的情況下,那他的特色就不是特色了。反而是他沒有的反而是他的負面特色。

IngramChen 積分 8

這位同學未來的命運會更慘,要維護 nodejs 的callback hell 程式碼,還有會掉資料的 mongodb...

popcorny 積分 5

對於所有需要DB的系統第一個建言: 所有系統都需要一個RDBMS

等到你某些需求在原本的RDBMS做不到的時候,再來想說用其他類型的Storage來解決。

s10g 積分 0

看完只有一個想法:Oldies but goodies.

Kcars 積分 0

這邊也有類似的狀況,只是把MongoDB換成Cassandra......
SQL碰久了後整個轉不過來...