首頁  >  問答  >  主體

關於MongoDB使用場景的疑問

目前網站的資料庫是MYSQL,裡面儲存了許多歌曲資訊記錄。

我在想如果把歌曲查詢部分做成從MongoDB裡查詢,速度是不是會快一些?

以後對歌曲資訊的增刪寫的時候,同時要跟MongoDB同步一下,是這樣吧?沒有NOSQL的經驗,請各位指點下,謝謝。

滿天的星座滿天的星座2701 天前713

全部回覆(4)我來回復

  • 给我你的怀抱

    给我你的怀抱2017-05-02 09:27:47

    很多問題並非只有一個解決方案的,這意味著你既可以使用這種技術,也可以使用那種技術。學習目的隨便怎樣都可以,但是真實生產環境中強烈建議簡化你的複雜度,用最簡單的,你自己最熟悉的方式解決問題。思考一下是否真的有必要使用2個資料庫來解決同一個問題。

    我在想如果把歌曲查詢部分做成從MongoDB裡查詢,速度是不是會快一些?

    可能會,也可能不會。取決於你有多少資料量,使用MongoDB的資料模型設計是否合理,以及…你打算投入多少硬體資源在上面。 NoSQL更專注於水平擴展,就是說在資料量不斷增加的情況下,仍然能夠保持查詢速度在一定的水平上。個人的經驗,如果有個幾千萬,上億的數據,MongoDB可能才會真正發揮優勢來。在資料到達這個量級之前,如果只是從速度上考慮我認為沒有很大的必要引入額外一個資料庫。它帶來的收益跟對你造成的複雜度對比起來,只能說性價比不高。

    以後對歌曲資訊的增刪寫的時候,同時要跟MongoDB同步一下,是這樣吧?

    資料同步的問題取決於你對「一致性」的要求有多高。在強一致的情況下,這就是一個分散式事務,恐怕對效能不是一件好事,違背了你想加快速度的初衷。如果是考慮最終一致性,可以看各種MySQL到MongoDB的ETL工具,例如Pentaho。當然自己透過程式碼實現也是可能的,只是考慮好各種容錯問題並不是一件容易的事情。

    回覆
    0
  • 世界只因有你

    世界只因有你2017-05-02 09:27:47

    首先,你要知道清楚一點,MongoDB 是 NoSQL 的一種具體實現,不同於 Redis,其儲存的資料結構是文件式的。

    其次,查詢速度是很難在產品與產品或引擎與引擎的差異中做武斷地決定,需要根據實際使用情況進行權衡,不僅如此,存儲什麼信息,如何存儲也是要做些分析的(如果只是練習實踐的話過程上可以簡單點)。


    之前也是只學了 MySQL,因為儲存的某些資料的結構的不確定性或複雜性,要單用 MySQL 來儲存就要使用許多表格和設定外鍵,所以也學習了 MongoDB 來解決需求。

    我做的是一個圖書的練習實踐,某種角度和歌曲有些相似。例如,圖書的作者可能不只一個,如果用MySQL,簡單的方法則會使用分隔符號來實作一個欄位內儲存多個作者,後期做查詢會有一定的問題(判斷條件的複雜甚至效能),而一首歌曲的演唱者也可能不只一個。

    我的實作是 MySQL + MongoDB,當然只用 MongoDB 也是可以實現的,不過認為具體需求要對應分析。我的綜合練習實踐還在繼續,可以隨時交流,以上提供的一種想法。

    回覆
    0
  • 世界只因有你

    世界只因有你2017-05-02 09:27:47

    Elasticsearch 做查詢更快,而且還不影響mysql效能

    回覆
    0
  • 世界只因有你

    世界只因有你2017-05-02 09:27:47

    我猜你可能需要根據歌詞來尋找歌曲等功能。上面提到的Elasticsearch就很好,還有一個選擇sphinx,做全文檢索也很不錯。

    回覆
    0
  • 取消回覆