Cassandra性能：列數越少列數越少，列數越少列數越多

我們正在評估是否可以從SQL SERVER遷移到cassandra for OLAP。根據內部存儲結構，我們可以有寬行。我們幾乎需要在日期之前訪問數據。我們經常需要在日期範圍內訪問數據，因爲我們有財務數據。如果我們使用日期作爲分區鍵來支持按日期過濾，我們最終會減少具有大量列的行。當我們每天處理數百萬筆交易時，如果我們將來有單列行密鑰有數百萬列，會不會妨礙性能？Cassandra性能：列數越少列數越少，列數越少列數越多

我們是否需要對訪問模式進行一些更改，以使每行的列數更少且行數更多。

需要一些有識之士表現在兩個方向上

來源

2015-06-19 107

採用寬行繼續是通常與卡桑德拉精細，都需要考慮然而幾件事情：

確保您沒有達到2在任何情況下都有數十億列的限制
整個寬行存儲在同一個節點上：它需要放在磁盤上。另外，如果您有一些日期被訪問的頻率比其他日期（例如今天）多，那麼您可以在存儲當天數據的節點上創建熱點。
非常寬的行可能會影響性能：但最後一個泡菜的Aaron Morton有一篇關於此的有趣文章：http://thelastpickle.com/blog/2011/07/04/Cassandra-Query-Plans.html 它有點舊，但我相信這些概念仍然有效。

對於一個好的餐桌設計決策，人們需要知道所有典型的過濾條件。如果您有其他任何您通常篩選的字段爲完全匹配，則也可以將它們添加到分區鍵。

來源

2015-06-19 17:27:24 medvekoma

感謝您的評論。達到20億列的上限是不太可能的。寬行不適合特定的磁盤可能是這種情況。 cassandra不處理這種行不適合磁盤的情況。它應該將數據傳輸到另一個節點，因爲選擇節點來保存該行是內部存儲引擎的決定。 – 107

Cassandra中的數據分區由分區鍵驅動：使用簡單快速的哈希算法Cassandra標識包含數據的節點。在這方面，寬行是一個單位，它不在節點之間分裂。最終嘗試將其他字段引入分區鍵（例如，金融產品的ID，年份或甚至月份，如果有意義的話）。 – medvekoma

如果散列算法識別最初不適合或適合行的節點，但隨着寬行最終增長，cassandra會將該行轉移到某個其他機器嗎？ – 107

Cassandra性能：列數越少列數越少，列數越少列數越多

回答

相關問題