Операция удаления Cassandra иногда не работает, можно выбрать данные после удаления

У меня есть две таблицы

CREATE TABLE IF NOT EXISTS QueueBucket (
    queueName   text,
    bucketId    int,
    scheduledMinute timestamp,
    scheduledTime timestamp,
    messageId   uuid,
    PRIMARY KEY ((queueName, bucketId, scheduledMinute), scheduledTime, messageId)
)  WITH compaction = { 'class' :  'LeveledCompactionStrategy'  } AND speculative_retry='NONE' ;

CREATE TABLE IF NOT EXISTS InDelivery (
    queueName       text,
    nodeId        uuid,
    dequeuedMinute    timestamp,
    messageId       uuid,
    bucketid        int,
    dequeuedTime    timestamp,
    PRIMARY KEY ((queueName, nodeId,bucketId, dequeuedMinute),dequeuedTime, messageId)
);

В коде я выполняю вставку в QueueBucket и удаление из недоставки в пакетном режиме (в журнале). Но во время нагрузочного тестирования иногда не работает удаление из недоставки, хотя вставка в QueueBucket работает. Чтобы подтвердить это, применяется проверка чтения из недоставки, сразу после которой прочтение удаленного messageId, если messageId все еще существует, распечатывает журнал WARN.

    queueDao.insertMsgInfo(queueName, bucketId, QueueUtils.getMinute(scheduledTime), scheduledTime, messageId);
    queuDao.deleteInDelivery(queueName, nodeId, bucketId, bucketMinute, dequeuedTime, messageId);
    if(queueServiceMetaDao.hasIndeliveryMessage(inDeliveryPK)) {
        log.warn("messageId  {} of queue {} bucket {} with node {} dequuedTime {} dequeud minute {} could not get deleted from indelivery.",
                messageId,queueName,bucketId, nodeId,QueueUtils.dateToString(dequeuedTime),QueueUtils.dateToString(bucketMinute));
        }

в методах insertMsgInfo и deleteInDelivery я повторно использую подготовленный оператор.

"INSERT INTO queuebucket (queuename, bucketid , scheduledminute, scheduledtime, messageid ) VALUES ( ? , ? , ? , ? , ? );"
"DELETE FROM indelivery WHERE queuename = ? AND nodeId = ? AND bucketId=? AND dequeuedMinute=? AND dequeuedTime =? AND messageId=? ;"

в hasIndeliveryMessage я передаю те же значения, упакованные в inDeliveryPrimaryKey, которые я передал для удаления данных о недоставке в методе moveBackToQueueBucket.

"SELECT messageId FROM indelivery WHERE queuename = ? AND nodeId = ? AND bucketId=? AND dequeuedMinute=? AND dequeuedTime=? AND messageId=? ;"

Я не понимаю, почему я вижу несколько предупреждений "не удалось удалить из-за недоставки". . Пожалуйста помоги

Я использую cassandra версии 2.2.7, это кластер cassandra с 6 узлами с коэффициентом репликации 5, а используемая согласованность чтения и записи - QUORUM.

Я также просмотрел ссылку Cassandra - удаленные данные все еще там и https://issues.apache.org/jira/browse/CASSANDRA-7810, но эта проблема исправлена. давным-давно. в 2.0.11.

Дальнейшее обновление Согласно Cassandra - Delete not working, я также запустил nodetool ремонт, но проблема не устранена. Следует ли мне также работать компактно?

Дальнейшее обновление: я больше не использую пакет, я просто вставляю его в очередь и удаляю для недоставки, а затем читаю данные, но проблема все еще сохраняется.

Добавление журналов:

2016-07-19 20:39:42,440[http-nio-8014-exec-12]INFO  QueueDaoImpl -deleting from indelivery queueName pac01_deferred nodeid 1349d57f-28f5-37d4-9fe1-dfa14dba4a9f bucketId 382 dequeuedMinute 20160719203900000 dequeuedTime 20160719203942310 messageId cc4fb158-f61e-345b-8dcf-3f842fe52d50:
2016-07-19 20:39:42,442[http-nio-8014-exec-12]INFO  QueueDaoImpl -Reading from indelivery : queue pac01_deferred nodeId 1349d57f-28f5-37d4-9fe1-dfa14dba4a9f dequeueMinute 20160719203900000 dequeueTime 20160719203942310 messageid cc4fb158-f61e-345b-8dcf-3f842fe52d50 bucketId 382 indeliveryRow Row[cc4fb158-f61e-345b-8dcf-3f842fe52d50]
2016-07-19 20:39:42,442[http-nio-8014-exec-12]WARN  QueueImpl -messageId  cc4fb158-f61e-345b-8dcf-3f842fe52d50 of queue pac01_deferred bucket 382 with node 1349d57f-28f5-37d4-9fe1-dfa14dba4a9f dequuedTime 20160719203942310 dequeud minute 20160719203900000 could not get deleted from indelivery .

Стоит ли пробовать ВСЕМ согласованность ???


person Laxmikant    schedule 19.07.2016    source источник
comment
проверьте, синхронизируются ли временные метки между всеми узлами   -  person undefined_variable    schedule 19.07.2016
comment
Все узлы кассандры находятся в одном часовом поясе.   -  person Laxmikant    schedule 19.07.2016
comment
Указываете ли вы отметки времени для операций вставки и удаления? Это хорошая практика, чтобы избежать неправильного порядка операции мутации в Cassandra. Пожалуйста, проверьте подробности datastax.github.io/java-driver/2.1.7/features/query_timestamps   -  person Mikhail Baksheev    schedule 19.07.2016
comment
Большое спасибо за ответ. Нет, я не указываю какие-либо временные метки при вставке и удалении из таблицы недоставки. Поскольку я новичок в cassandra, я хочу понять его значение и тоже буду применять его ... давайте посмотрим, решит ли он мою проблему. Если возможно, предоставьте такую ​​же хорошую ссылку, чтобы понять концепцию отметки времени.   -  person Laxmikant    schedule 19.07.2016
comment
@Laxmikant, planetcassandra.org/blog/ вот хорошее объяснение меток времени   -  person Mikhail Baksheev    schedule 19.07.2016


Ответы (2)


Прежде всего, использование Cassandra для поддержки очередей или структур, подобных очереди, является известным анти-шаблоном. Если ваша очередь имеет дело с высокой пропускной способностью, вам придется бороться с надгробиями и снижением производительности запросов.

Что касается вашей реальной проблемы, я видел, как это происходило раньше с моделями, которые используют временные метки в качестве ключей. Как вы создаете значения отметок времени для dequeuedMinute и dequeuedTime?

Если вы сами ставите метки времени, их будет легко удалить. Однако, если вы создаете их с помощью dateOf(now()) или Java.Util.Date, тогда в ваших временных метках будут храниться миллисекунды. Хотя cqlsh замаскирует это от вас:

INSERT INTO InDelivery (queuename, nodeid, bucketid , dequeuedMinute, dequeuedTime, messageid )
VALUES ('test1',uuid(),2112,dateof(now()),dateof(now()),uuid());

INSERT INTO InDelivery (queuename, nodeid, bucketid , dequeuedMinute, dequeuedTime, messageid )
VALUES ('test1',a24e056a-94fa-4aee-b3a7-a8df6060091a,2112,'2016-07-19 09:57:16-0500','2016-07-19 09:57:16-0500',uuid());

SELECT queuename,nodeid,dequeuedMinute,blobasbigint(timestampasblob(dequeuedMinute)),             
dequeuedTime,blobasbigint(timestampasblob(dequeuedTime)),messageid
FROM InDelivery;

 queuename | nodeid                               | dequeuedMinute                | blobasbigint(timestampasblob(dequeuedMinute)) | dequeuedTime             | blobasbigint(timestampasblob(dequeuedTime)) | messageid
-----------|--------------------------------------+-------------------------------+-----------------------------------------------+--------------------------+--------------------------------------+---------------------------------------------
     test1 | a24e056a-94fa-4aee-b3a7-a8df6060091a | 2112 2016-07-19 09:57:16-0500 |                                 1468940236000 | 2016-07-19 09:57:16-0500 |                               1468940236000 | 7ca1f676-9034-45ba-bb3f-377ba74cc5c0
     test1 | a24e056a-94fa-4aee-b3a7-a8df6060091a | 2112 2016-07-19 09:57:16-0500 |                                 1468940236641 | 2016-07-19 09:57:16-0500 |                               1468940236641 | 9721d96e-d6f5-43a7-9ba4-18ef4d54ab8a
(2 rows)

Эти отметки времени выглядят одинаково, верно? Но применение blobasbigint(timestampasblob( вложенных функций показывает разницу (000 против 641 миллисекунды).

Обратите внимание, что если я изменю свой SELECT для фильтрации по 641 миллисекундам (последние 3 цифры в столбцах blobasbigint(timestampasblob(), я получу строку с миллисекундами.

SELECT queuename,nodeid,dequeuedMinute,blobasbigint(timestampasblob(dequeuedMinute)),             
dequeuedTime,blobasbigint(timestampasblob(dequeuedTime)),messageid
FROM InDelivery
WHERE queuename='test1' AND bucketid=2112 
AND nodeid=a24e056a-94fa-4aee-b3a7-a8df6060091a
AND dequeuedMinute='2016-07-19 09:57:16.641-0500';

 queuename | nodeid                               | dequeuedMinute                | blobasbigint(timestampasblob(dequeuedMinute)) | dequeuedTime             | blobasbigint(timestampasblob(dequeuedTime)) | messageid
-----------|--------------------------------------+-------------------------------+-----------------------------------------------+--------------------------+--------------------------------------+---------------------------------------------
     test1 | a24e056a-94fa-4aee-b3a7-a8df6060091a | 2112 2016-07-19 09:57:16-0500 |                                 1468940236641 | 2016-07-19 09:57:16-0500 |                               1468940236641 | 9721d96e-d6f5-43a7-9ba4-18ef4d54ab8a
(1 rows)

Суть в том, что если вы собираетесь хранить миллисекунды с ключами временных меток, вам также необходимо включить их, когда вы SELECT/DELETE используете эти ключи. Аналогичным образом, если вы не сохраняете миллисекунды в ключах временных меток, вы не можете включать их, когда SELECT/DELETE используете эти ключи.

person Aaron    schedule 19.07.2016
comment
Спасибо за ответ . ты совершенно прав. Я использую только java.util.Date, но при вставке / удалении / выборе я не игнорирую миллисекундную часть. Я сталкиваюсь с этой проблемой только во время нагрузочного тестирования, когда за секунду приходят тысячи запросов. Так что у меня также есть те же сомнения, что и у @Mikhael Baksheev, который работает над установкой отметки времени на стороне клиента при вставке и удалении, чтобы поддерживать порядок мутации. Я молюсь, чтобы это решило мою проблему :) .. - person Laxmikant; 19.07.2016

ИСПОЛЬЗОВАНИЕ TIMESTAMP на стороне клиента решило мою проблему. Спасибо Михаилу Бакшееву за указание.

Рекомендуется использовать его на стороне клиента в запросе, чтобы поддерживать порядок мутации.

Если мы вставляем и удаляем данные, убедитесь, что значение TIMESTAMP, которое мы передаем в запросе на удаление, должно быть больше, чем то, что мы передали при вставке.

Другими причинами сбоя при удалении данных / сбоя в Cassandara могут быть:

  1. игнорирование значения миллисекунды в удалении для поля отметки времени.
  2. Данные могут появиться снова, если узел не работает дольше льготного периода.
person Laxmikant    schedule 31.08.2016