извините, что снова попросил что-то у Кассандры, и я был бы очень признателен за ваше возвращение:
Я прочитал это: http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic и совершенно потерян и удивлен:
Действительно ли это так, что в Кассандре ПИСЬМА на ОДНОМ УГЛОВОМ ОДНОМ КНОПКЕ (с МНОГИМИ КОЛОННАМИ, которые будут обновлены в ОДНОМ КОЛОННАМ, с использованием batch_mutate) НЕ ИЗОЛИРОВАНЫ против ЧИТАНИЯ на ОДНОМ УЗЛЕ ОДНОМУ КЛЮЧУ-КЛЮЧУКОЛОННЫ, гарантирующие, что чтение не готово «частично измененные данные»?Пример:
Current Status: [KEY=1 , ColumnName=A with Value=A , ColumnName=B with Value=B] on Node 1
Client A => Writes: [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=D] on Node 1
ATOMICITY:
Согласно документам cassandra, записи являются атомарными для клиента, выполняющего запись: приведенная выше запись либо будет полностью успешной, либо завершится неудачей полностью !?Что-то вроде [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=B] (= половина обновлений столбцов завершилась успешно, но другая половина еще не была применена / не выполнена) не может быть РЕЗУЛЬТАТОМ записи в случае ошибки?Это правильно?
ИЗОЛЯЦИЯ:
Правда ли, что даже на ОДНОМ ОДНОМ УЗЛЕ (здесь Узле 1) записи не изолированы для того, кто читает ту же строку на том же Узле?Как описано выше, если Клиент A обновил половину своих столбцов, которые должны быть изменены (здесь ColumnName = A со значением = C), действительно ли верно, что другое соединение Client B с узлом 1 будет действительно видеть запись как
Client B => Reads: [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=B] on Node 1
И через несколько миллисекунд, читая снова, он увидит?
Client B => Reads: [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=D] on Node 1
.
Почему обновления не изолированы на основе узла?
Для меня это кажется довольно простым и дешевым?Почему в узле 1 блокировки памяти нет, что KEY = 1 в настоящее время находится в процессе обновления, поэтому чтение может ждать завершения этой записи?(Это было бы очень маленькими накладными расходами, поскольку блокировка локально удерживается в памяти на Node1 и может быть настроена так, чтобы клиент чтения мог принять «блокировку» или просто прочитать грязное значение? Так что это что-то вроде «»Настраиваемый уровень изоляции "? Если мне нужна высокая производительность, я игнорирую блокировки / отключаю их, и если мне нужна изоляция для каждого узла и я принимаю отрицательное влияние на производительность, то я жду, когда будет снята блокировка памяти (на узле 1)?(Заметьте, я не говорю о скрытых / распределенных блокировках, но блокировках, которые гарантируют на одной обработке, что запись изолирована для каждого ключа строки!)
Или изоляция отличается от "изменение существующих столбцов "по сравнению с операциями, которые" добавляют / добавляют столбцы ". Таким образом, цепочка columsn (как в примере выше является изолированной), но добавление новых columsn не изолирована. С моей точки зрения, изменение существующих столбцов должно быть изолированным / атомарным.... Добавление columsn не так уж много необходимо для изоляции ...
Вопроспочему я спрашиваю: если что-то, как показано выше, может произойти, что читает действительно прочитанные частично измененные записи, то какие варианты использования тогда законны для nosql / cassandra?Это означает, что любой случайный столбец данных может существовать для каждой строки, так как columsn может находиться в произвольном состоянии чтения / записи?Я почти не знаю каких-либо данных и прецедентов, которые могут быть изменены "произвольно" для каждой строки.
Большое спасибо !!!Jens