卡桑德拉：哪個是手工索引的最佳選擇

首先，請原諒我的英文。這不是我的母語。我正在將SQL數據庫移動到Cassandra，但我有一個問題，我無法解決。假設我有一個存儲歌曲的SQL表。每首歌都有一個ID作爲主鍵，它允許訪問所有相關數據，這些數據存儲在由鍵給出的行的字段中。我也有一些索引使用一些不同的標準作爲作者，性別，標題...卡桑德拉：哪個是手工索引的最佳選擇

當我想到移動到卡桑德拉模式，我工作圍繞的想法，我可以創建一個等效的列家庭，其中歌曲ID是行鍵，歌曲屬性是列。然後，我可以創建5或6個手動索引來按作者，標題，性別等進行搜索。作者，標題...將作爲列鍵（添加一些額外的數據以使它們保持唯一性，使用複合列名稱），並且該值將是靜態列族中用於搜索的歌曲ID，其中每行由歌曲ID。

但我在這裏出現我的疑問。什麼更好：每個索引CF只存儲ID還是存儲所有屬性？第一個選項允許我減少必要的內存量，但是我需要（至少）2次讀取才能獲得每首歌曲的屬性。有了第二個選項，我需要更多的內存，因爲每個索引重複一次相同的信息，但通過一次讀取，我可以獲得我需要的所有屬性。我想我可以假設需要額外的內存，如果這將是一個更快的模式，但它會更快？擁有更大的數據庫不會使其工作變慢？或者較慢的操作是由於Cassandra存儲行的方式以及由於2次讀取而搜索由索引CF給出的每一行？我使用第二個選項（在CF中存儲所有作爲「索引」的屬性）計算出我比第一個選項需要大約80％的內存（CFs真的可以作爲索引來查找歌曲的「主要」CF中的正確數據）。

任何幫助將不勝感激。

在此先感謝！

來源

2013-01-15 Janbalik

你也想看看寬行模式。一些類似PlayOrm的庫爲你做了這種模式，這樣你就可以做一些類似可伸縮SQL的事情（即使用分區）。你可以擁有任意數量的分區。我確信將來會有越來越多的NoSql對象映射庫存在...... PlayOrm的wiki上還有一個模式頁面，它沒有Sql模式和PlayOrm模式......您可能想要檢出nosql的模式。

來源

2013-01-16 00:12:32

我的直覺說寬行是一種更好的方法，但我想知道一些經歷過類似情況的專家的意見。非常感謝你，Dean。我將檢查PlayOrm的wiki;） – Janbalik

寬行可以進入數百萬列。我肯定不會超過1000萬，也許不會超過幾百萬。我們做了100萬，沒有問題，PlayOrm的連接工作速度與hibernate + postgres一樣快（PlayOrm可以連接分區，分區通常不會超過數百萬行） –

當然。我們已經完成了2個設計，每個我們正在考慮的方法都有一個設計。基於寬行的（我提到的第二個選項）旨在將列數保持在100萬以下。最寬的行大約有100.000 - 200.000列，小於5MB。 – Janbalik

當然，在不同的數據模型中有各種各樣的權衡，但聽起來你最關心的是數據集大小和訪問速度。 Cassandra可以線性擴展的方式處理大量的數據，只要您可以爲其提供必要的資源來完成這項工作。另一方面，當你做鑰匙時，做兩次查找是非常便宜的。我的直覺是隻存儲ID，如果沒有其他原因，它會更容易更新您的屬性。然後，如果您發現查詢速度不夠快，您可以進行優化。不過，從RDBMS來看，我猜測它會很快。

來源

2013-01-15 19:30:29

謝謝rs_alt;）。你是對的，我擔心數據大小和訪問速度，但速度對我來說更重要，因爲我認爲我們可以成長起來並付錢。即使2次訪問速度很快，我仍然不太確定採用第一種方法。很多時候，我們不僅需要獲取一首歌曲，還需要基於搜索過濾器，而且我認爲這將是基於行鍵範圍的訪問。它的工作速度是否夠快？或者使用第二種方法，在每列中的所有歌曲數據的每個搜索條件中，我將有一個較寬的行，是更好的嗎？如果是這樣，我不介意大小。 – Janbalik

如果速度最重要，尺寸不是問題，並且如果您可以採取適當的策略保持屬性同步，那麼通過所有方法都可以在兩個位置寫入數據。卡桑德拉可以採取，如果你可以...:) –

嘿嘿，好點：如果我可以;） – Janbalik

卡桑德拉：哪個是手工索引的最佳選擇

回答

相關問題