評論系統rdbms vs nosql

實現評論系統（大數據寫入）的最佳方式是什麼？評論系統rdbms vs nosql

1）使用RDBMS數據庫如MySQL，2桌一個主題，一個用於註釋優點是新評論的插入是快速，高效，簡單，高效的索引。缺點是縮小（水平縮放）很難。

2）使用的NoSQL數據庫，比如CouchDB的或MongoDB中，優點是向外擴展（水平縮放）很容易，支持龐大的數據寫入，無模式缺點我認爲新數據的插入是不如RDBMS快速高效

例如，要更新couchdb文檔，您需要獲取整個文檔，在本地進行更新，然後再次提交，文檔大小將會很大，因此會佔用帶寬。

而且我認爲，CouchDB的就地更新，MongoDB的更新將是緩慢的，不會有效，因爲在RDBMS

此外，當您想獲得各種主題的每個用戶的我覺得評論在RDBMS中搜索會比在nosql系統中更快。

也就是說CouchDB的數據庫文件的[文件樣本每個主題]樣品

{"_id":"doc id", 
"_rev":"45521231465421" 
"topic_title":"the title of the topic" 
"topic_body":"the body of the topic" 
"comments":[ 
      {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla1"}, {"user":"user1"} 
      {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla2"}, {"user":"user2"} 
      {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla3"}, {"user":"user3"} 
      {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla4"}, {"user":"user4"} 
      {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla5"}, {"user":"user5"} 
      {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla6"}, {"user":"user6"} 
      ] 
}

來源

2013-05-09 Michael harris

爲什麼你認爲CouchDB的或MongoDB中插入數據時速度較慢？你是用自己的基準來驗證它，還是隻是在聽你的直覺？ – Philipp 2013-05-09 20:29:15

要給couchdb文檔添加註釋，您需要獲取整個文檔，在本地更新它，然後再次提交，文檔大小將很大，因此會佔用帶寬。所以它會「慢」 – 2013-05-09 20:40:16

爲什麼你會將你的評論嵌入到博客文章中？你是否期望當你顯示博客帖子時，你還需要顯示它的所有評論？爲什麼你認爲RDBM中的搜索速度會比MongoDB更快？它們都使用索引，兩個結構索引都是B樹。你爲什麼不實際測試你預期使用的數據？ – 2013-05-10 05:23:57

我認爲新數據的插入並不快，高效爲

你碰到了什麼東西在那裏的RDBMS插入速度。 NoSQL數據庫依靠您的場景。我無法說清楚，很多人都希望MongoDB能夠以比SQL更快的速度執行，並且當它不適用於他們時會非常失望，事實上在此之前，MongoDB用戶的Google小組已經充滿了這些人。

例如更新的CouchDB

不僅如此，但CouchDB的還使用版本控制和JSON這是不一樣將其存儲在SQL作爲高效且將消耗每記錄更多的空間。

MongoDB的更新將是緩慢的，不會有效，因爲在RDBMS

架構，查詢，架構，查詢...

這就是它的含義。問自己一個問題。

我是否期待每個帖子有很多評論？

如果是這樣的內存（是的，在內存中）$push，$pull和其他子文檔運營商可能會得到一個大的子文檔慢（說實話，會）。

不僅如此，持續增長的文檔可能會成爲一個問題，並可能導致嚴重的碎片和空間使用，從而形成「瑞士奶酪」效果，從而大大減慢系統的速度（使其停頓）。此演示文稿應該有助於更多地瞭解存儲的真實工作原理：http://www.10gen.com/presentations/storage-engine-internals

因此，您已經知道，如果使用了錯誤，子文檔可能是一個糟糕的主意。這就是說，你可以用2種尺寸分配的力量來部分補救它：http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes但是如果你得到太多評論插入，那麼它不會有太大的幫助。

我個人不會嵌入這種關係。

所以，我會去作爲一個RDBMS相同的設置，現在你開始看到這個問題。如果不是用於MongoDB的fsync隊列，插入的速度可能會大致相同，這與SQL直接寫入磁盤的SQL不同。您可以使用日記寫入來設置MongoDB，但是在一天結束時，您可能會從SQL獲得與SQL相同的性能指標。

至於查詢，這是MongoDB仍然可以在上面提供的地方，提供你的工作集適合RAM。我不敢大膽，最後一點夠了！

與SQL不同，MongoDB將一切（您的整個數據）映射到虛擬內存，而不是RAM，絕對不會與RAM混淆。這對於更大的查找速度更快，對於小型查找，速度將大致相同，因爲兩者都將從內存緩存中提供。

此外，當您想要獲得每個用戶在各種主題中的評論時，我認爲RDBMS中的搜索速度要快於nosql系統。

如果主題ID在評論文檔中，它肯定會在MongoDB中更快，因爲您的工作集已準備好在RAM中。

工作集是什麼意思？這裏是一個很好的答案：What does it mean to fit "working set" into RAM for MongoDB?

希望這有助於

來源

2013-05-09 21:19:13 Sammaye

嗯，有人下來投票我的答案，我不知道他們是否有一個解釋？ – Sammaye 2013-05-10 07:06:03

我可以說只有約MongoDB的，你確實是錯了刀片。 Here不錯，Mongo與MSSQL的比較，Mongo比MSSQL好100倍。所以它非常適合大數據處理。搜索速度也要快得多（如果插入和搜索速度不會更快，NoSQL的全部重點是什麼？） - 但有一點需要注意，你不能在查詢中執行連接，你必須連接表在手動應用程序（但有建議報告的解決方法 - nested documents)

來源

2013-05-09 20:40:46

我會非常擔心依賴這樣的圖表，然後說MongoDB更快就是「事實」，即他只在那裏使用嵌入式架構，嵌入並不總是一個好主意，事實上它應該仔細考慮...... – Sammaye 2013-05-09 21:02:21

我並不是說嵌入總是一個好主意，但在一些（可能是大多數？）情況下它是可以接受的。如果沒有，你仍然可以手動加入，雖然這很痛苦（但這是NoSQL DB的價格）。但OP詢問了評論系統，所以在這種情況下嵌入似乎很好。 – 2013-05-09 21:12:23

這取決於查詢和意見，但是，似乎可以假設嵌入 – Sammaye 2013-05-09 21:25:55

評論系統rdbms vs nosql

回答

相關問題