Последовательность чтения-записи-записи в Кассандре
Последовательность "чтение самому себе - запись" - это значительное улучшение по сравнению с так называемой конечной согласованностью: если я изменяю свою фотографию профиля, мне все равно, увидят ли другие изменения через минуту, но выглядит странно, если после перезагрузки страницы я все еще вижу Старый.
Может ли это быть достигнуто в Cassandra без необходимости выполнять полную проверку на чтение более чем на одном узле?
С помощью ConsistencyLevel.QUORUM Это нормально при чтении неуказанных данных, и n>1 узлов фактически читаются. Однако, когда клиент читает с того же узла, с которого он пишет (и фактически использует то же соединение), это может быть расточительным - некоторые базы данных в этом случае всегда будут гарантировать, что ранее записанные (мои) данные будут возвращены, а не некоторые более старые. С помощью ConsistencyLevel.ONE не гарантирует этого и полагая, что это приводит к условиям гонки. Некоторый тест показал это: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/per-connection-quot-read-after-my-write-quot-consistency-td6018377.html
Моя гипотетическая установка для этого сценария - 2 узла, коэффициент репликации 2, уровень чтения 1, уровень записи 1. Это приводит к возможной согласованности, но я хочу согласованности чтения-ваших-собственных-записей при чтениях.
Использование 3 узлов: RF=3, RL= кворум и WL= кворум, на мой взгляд, приводит к расточительному запросу на чтение, если мне достаточно согласованности только с "моими" данными.
// seo: также известен как: согласованность сеанса, согласованность чтения после записи
2 ответа
Хороший вопрос.
У нас было некоторое время http://issues.apache.org/jira/browse/CASSANDRA-876 чтобы добавить это, но никто не потрудился закончить это, потому что
- CL.ONE отлично подходит для МНОГО рабочих нагрузок без какой-либо дополнительной гимнастики
- Чтение в любом случае настолько быстрое, что выполнение дополнительного не представляет особой проблемы (и на самом деле Read Repair, который по умолчанию включен, означает, что все узлы в любом случае проверяются, поэтому разница между CL.ONE и выше заключается в большей доступности). чем производительность)
Тем не менее, если вы хотите помочь, попросите билет, и я буду рад указать вам правильное направление.
Я некоторое время следил за разработкой Cassandra, и я не видел ни одной подобной функции, о которой говорилось.
Тем не менее, если у вас есть только 2 узла с коэффициентом репликации 2, я бы спросил, является ли Cassandra лучшим решением. В итоге вы получите полный набор данных на каждом узле, поэтому более традиционная реплицированная установка SQL может быть проще и более широко протестирована. Cassandra очень многообещающая, но это всего лишь версия 0.8.2, и о проблемах регулярно сообщается в списке рассылки.
Другим способом решения проблемы "посмотреть мои собственные обновления" было бы кэширование результатов где-то ближе к клиенту, будь то на веб-сервере, на уровне приложений или с использованием чего-то вроде memcached.