Cassandra Query Timeout with small sets of data

我遇到了Cassandra 2.1.17的問題。我有一張大約40k「行」的桌子。我遇到問題的一個分區可能有5k條目。Cassandra Query Timeout with small sets of data

表是：

create table billing (
    accountid uuid, 
    date timeuuid, 
    credit double, 
    debit double, 
    type text, 
    primary key (accountid,date) 
) with clustering order by (date desc)

所以有很多插入，並從該表中刪除的。

我的問題是，它似乎變得腐敗，我認爲，因爲我不再能夠選擇數據超過某個分區的某個點。

從cqlsh我可以像這樣運行。

SELECT accoutid，date，credit，debit，type FROM billing WHERE accountid = XXXXX-xxxx-xxxx-xxxxx ... AND date < 3d466d80-189c-11e7-8a57-f33cbced2fc5 limit 2;

首先，我做了10000的選擇限制，最多可處理大約5000行通過它們的頁面，然後在最後它會出現超時錯誤。

然後我使用第二個從最後timeuuid並選擇限制2它將失敗限制1將工作。

如果我使用最後一次timeuuid作爲<並限制爲1，它也會失敗。

所以只是尋找我能做的事情我不知道什麼是錯的，不知道我如何修復/診斷髮生了什麼。

我已經厭倦了修復並強制壓實。但它似乎仍然存在問題。

謝謝你的幫助。

來源

2017-04-04 zooppoop

謝謝你的所有迴應。我發現這個鏈接，我們有點更詳細地瞭解我如何使用cassandra和一些選項中的這張表。一般來說，我認爲你們所有人都認爲墓碑是問題所在。如果不是這種情況，會嘗試回覆評論。這是我找到的鏈接。 https://lostechies.com/ryansvihla/2014/10/20/domain-modeling-around-deletes-or-using-cassandra-as-a-queue-even-when-you-know-better/ – zooppoop

在我看來，就像你在選擇時碰到很多墓碑一樣。事情是，當他們在那裏時，卡桑德拉仍然必須經過他們。可能有多種因素，比如插入語句的ttl，大量刪除，插入空值等。

我敢打賭，您需要調整桌面上的gc_grace_seconds並更頻繁地運行修復。但要小心，不要把它設置得太低（在這段時間之前必須完成一輪修復）。

這一切都很好地解釋在這裏： https://opencredo.com/cassandra-tombstones-common-issues/

來源

2017-04-04 08:11:38

我覺得你有這個分區太多的墓碑。

什麼是墓碑？

要記住一條記錄已被刪除Cassandra創建了一個特殊的值，稱爲「墓碑」。墓碑與任何其他值都具有TTL，但不像任何其他值那樣容易壓縮。卡桑德拉爲了避免數據重現出現這種不一致性，需要更長的時間。

如何看墓碑？

nodetool cfstats給你的，你有多少墓碑有平均每片

如何解決這個問題的想法？

墓碑的保存期限爲gc_grace_seconds。你必須減少它，然後運行重大壓縮來解決這個問題。

來源

2017-04-04 08:15:00 DineMartine

嘗試從在桌面上運行手動壓縮開始。
您可以在cassandra config中增加read_request_timeout_in_ms參數。
如果您正在進行大量的刪除和更新，請考慮轉向採用分級壓縮策略。

來源

2017-04-04 08:50:24 nevsv

謝謝你的建議將嘗試看看是否有幫助。是的，桌子上會有很多刪除。我想知道是否有辦法將這張表設置爲具有不同的壓縮時間表或其他類似的表格。目前該表正在像隊列一樣使用。 – zooppoop

STCS和LCS都可以使用參數。首先降低STCS中的壓實觸發器的閾值或LCS中的小表尺寸。 – nevsv

LeveldCompactionStrategy更適合這種用例，但如果您的墓碑太多（超過100 000個），它將無濟於事。 – DineMartine

Cassandra Query Timeout with small sets of data

回答

相關問題