哪個數據庫適合這份工作？

我正在研究一個功能，並可以使用哪些數據庫來解決這個問題。哪個數據庫適合這份工作？

我們有一個使用MySQL的Rails應用程序。我們沒有MySQL的問題，它運行良好。但是對於一個新功能，我們正在決定是否保留MySQL。爲了簡化問題，我們假設有一個User和Message模型。用戶可以創建消息。該消息基於與海報的關聯被傳遞給其他用戶。

顯然有一種基於友誼的關聯，但根據用戶的個人資料，還有許多更多的關聯。我計劃存儲關於海報的一些元數據以及消息。這樣，我不必每次查詢消息時都要拉取元數據。

因此，消息可能是這樣的：

{ 
    id: 1, 
    message: "Hi", 
    created_at: 1234567890, 
    metadata: { 
    user_id: 555, 
    category_1: null, 
    category_2: null, 
    category_3: null, 
    ... 
    } 
}

當我查詢的消息，我需要能夠基於零個或多個元數據屬性進行查詢。這個呼叫需要很快並且經常發生。

由於元數據屬性的數量和任何數量都可以包含在查詢中，所以在這裏創建SQL索引似乎不是一個好主意。

就我個人而言，我有MySQL和MongoDB的經驗。我已經開始研究Cassandra，HBase，Riak和CouchDB。我可以使用一些可能已經完成研究的人的幫助，以確定哪個數據庫適合我的任務。

是的，消息表可以很容易地增長到數百萬或行。

來源

2011-08-19 Jey Balachandran

這是一個非常開放的問題，所以我們所能做的就是根據經驗給出建議。首先要考慮的是，如果決定使用之前沒有用過的東西是一個好主意，而不是使用你熟悉的MySQL。當你有機會時不使用光亮的新東西是無聊的，但請相信我，當你把自己塗在角落裏，因爲你知道新玩具會在盒子上做它所說的一切，這是很糟糕的。在博客文章中，沒有任何事情可以像它說的那樣工作。

我主要有MongoDB的經驗。除非你想花很多時間嘗試不同的事情並意識到他們不工作，否則這是一個糟糕的選擇。一旦你擴大了一點，你基本上不能使用像二級索引，更新和其他東西，這使得Mongo成爲一個非常好用的工具（其中大部分與它的全局寫鎖和磁盤上的數據庫格式有關）如果你刪除數據，基本上很容易併發和碎片）。

我不同意HBase是不可能的，它沒有二級索引，但是一旦你超過了一定的流量負載，你就無法使用這些索引。 Cassandra也是如此（這比HBase更易於部署和使用）。基本上你必須實現你自己的索引，這是你選擇的解決方案。

你應該考慮的是如果你需要在可用性方面保持一致，反之亦然（例如，如果消息丟失或延遲有多糟糕，如果用戶不能發佈或讀取消息有多糟糕消息），或者你會對數據進行更新（例如Riak中的數據是不透明的blob，爲了改變它，你需要讀取它並將其寫回，在Cassandra，HBase和MongoDB中，你可以添加和刪除屬性而無需一讀物體）。易用性也是一個重要因素，從程序員的角度來看，Mongo確實很容易使用，而HBase非常糟糕，但是花一些時間製作自己的封裝惡意內容的庫，這將是值得的。

最後，不要聽我說，嘗試一下，看看他們如何表現，感覺如何。確保你儘可能努力地加載它，並確保你測試你將要做的一切。我犯了一個錯誤，那就是當你在MongoDB中刪除大量數據並且爲此付出代價時，不會測試會發生什麼。

來源

2011-08-19 09:58:25 Theo

從我的經驗來看，Hbase並不是您的應用程序的良好解決方案。因爲：

不含默認輔助索引（你應該安裝插件或喜歡這些東西）。因此，您只能通過主鍵進行有效搜索。我已經使用hbase和其他表實現了二級索引。所以你不能在在線應用程序中使用這個，因爲爲了獲得結果你應該運行map/reduce作業，並且它將花費很多時間在數據上。
這是很難支持和調整這個分貝。對於有效的工作，您將使用HBAse和Hadoop，並且它是必需的強大計算機或多個計算機。
當您需要對大量數據進行彙總報告時，Hbase非常有用。看來你不需要。

來源

2011-08-19 08:02:44

我會建議看演示約Why databases suck for messaging這主要是針對這樣的事實，爲什麼你不應該使用的數據庫如MySQL的消息。

我認爲在這種情況下，CouchDB的changes feed可能會非常方便，雖然您可能還需要基於查詢消息元數據創建一些更復雜的views。如果速度至關重要，請嘗試查看redis，該功能非常快速，並具有pub/sub功能。 MongoDB及其即時查詢支持對於這種用例也可能是一個體面的解決方案。

來源

2011-08-19 08:25:52 yojimbo87

我認爲你在存儲元數據以及每條消息時都是獨一無二的！爲了更快的檢索時間而犧牲存儲空間可能是一條可行的路。請注意，如果您需要更改用戶的元數據並將其傳播到所有消息，它可能會變得複雜。你應該考慮這種情況的發生頻率，你是否真的需要更新所有的消息記錄，並且基於它是否值得付出代價來減少查詢的次數（這可能是值得的，但這取決於你係統的細節）。

我同意@Andrej_L Hbase不是這個問題的正確解決方案。卡桑德拉也因爲同樣的原因而陷入困境。

CouchDB 可能解決你的問題，但你將不得不爲任何元數據定義視圖（物化索引），你要查詢。如果在這裏不使用MySQL的要點是爲了避免索引所有內容，那麼Couch可能也不是正確的解決方案。

Riak會是一個更好的選擇，因爲它使用map-reduce查詢您的數據。這使您可以構建您喜歡的任何查詢，而不需要像沙發中那樣預先索引所有數據。百萬行不是 Riak的問題 - 沒有擔心那裏。如果需要，它也可以通過簡單地增加更多的節點來擴展（並且它也可以平衡自己，所以這實際上不是問題）。

所以根據我自己的經驗，我建議Riak。然而，與你不同的是，我對MongoDB沒有直接的經驗，所以你必須再次判斷它自己（或者其他人可以回答這個問題）。

來源

2011-08-19 08:29:11 Elad

最好的部分是，我不必擔心元數據更改。一旦使用元數據創建了一條消息，它就會爲該消息設置一條消息。 –

由於元數據屬性的數量和任意數量可以被包含在查詢，在這裏創建SQL指標似乎並不像一個好主意的事實。

聽起來好像你需要一個連接，所以你可以大多數人忘記CouchDB，直到他們對多工作的代碼進行了處理（不確定它是否還在工作）。

來源

2011-08-19 11:54:40

它只是一個關係。所以加入並不是唯一的選擇。您可以：a）將用戶的記錄＃嵌入到消息記錄中或b）嵌入元數據，因此您不必查找用戶記錄 – BenG

了Riak一樣快，你讓它查詢，取決於

蒙戈將讓你在任何領域創建一個索引，即使是一個數組

的CouchDB是非常不同的，它建立在節點上使用索引存儲的map-reduce（但沒有減少），他們所說的「視圖」

RethinkDB會讓你有SQL，但是要快一點 TokuDB將太

Redis的將殺死所有的速度，但它的ENTI依靠存儲在內存中

單層關係可以在所有的關係中完成，但每個關係都不同。

來源

2011-12-06 05:51:12 BenG

哪個數據庫適合這份工作？

回答

相關問題