получить фрагмент, возвращающий непоследовательные результаты

Я использую широкий индекс столбца для упорядочивания записей в режиме временной шкалы, a la:

"TimelineIndex" //CF name
  [CFName] //row key
    [TimeUUID]:[CFRowKey] //column name/value
    [TimeUUID]:[CFRowKey] //column name/value
    [TimeUUID]:[CFRowKey] //column name/value
    [TimeUUID]:[CFRowKey] //column name/value

Предположим, что у меня есть 10 записей в TimelineIndex CF с одним столбцом в день, начиная с '01/01/2013 12:00:00 'до '10/01/2013 12:00:00' (как TimeUUID), и я запускаю следующую команду get_slice ():

var predicate = new SlicePredicate(){ Slice_range = new SliceRange() {
{
  Start = TimeGenerator.GetTimeUUID(new DateTime("06/01/2013 12:00:00"),
  Finish = TimeGenerator.GetTimeUUID(new DateTime("11/01/2013 12:00:00"),
  Count = 5,
  Reversed = false
}};
var results = client.get_slice([CFName], parent, predicate, consitencylevel.one);

Столбцы, возвращаемые этим запросом, не всегда согласованы. В большинстве случаев возвращается столбец с именем '06/01/2013 12:00:00 ', но каждый так часто (около 1 из 10 исполнений) этот столбец исключается из результатов, и я получаю всего 4 столбца ,

Я не могу, чтобы жизнь меня определяла, почему я получаю непоследовательные результаты здесь. Может ли кто-нибудь предложить причину этого?

И прежде чем кто-нибудь скажет, я знаю, что его нецелесообразно напрямую использовать Thrift - это чисто доказательство концепции!

1
nl ja de
Сколько узлов находится в вашем кластере и каков ваш коэффициент репликации?
добавлено автор rs_atl, источник
3 узла в кластере. Коэффициент репликации 2. Я бы не подумал, что это будет иметь значение, поскольку я запрашиваю данные из одной строки, которая должна содержаться целиком на одном узле.
добавлено автор beterthanlife, источник
3 узла в кластере. Коэффициент репликации 2. Я бы не подумал, что это будет иметь значение, поскольку я запрашиваю данные из одной строки, которая должна содержаться целиком на одном узле.
добавлено автор beterthanlife, источник

4 ответы

Если вы рискуете проявить очевидность, помните, что TimeUUID (версии 1 UUID) выполняют две цели:

  • У них есть компонент, основанный на времени
  • Это UUIDs

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

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

Итак, то, что происходит, - это тонкое взаимодействие двух вышеуказанных пунктов: когда вы создаете новые random-ish TimeUUID в 06/01/2013 12:00:00 , иногда это сортирует перед тем, который вы вставили, и иногда это не так. Если это не так, то первый столбец не будет включен.

Чтобы исправить это, вам нужно сознательно построить невременные компоненты для запроса UUID для сортировки как можно ниже. Например, библиотека pycassa делает это.

4
добавлено
Интересно. Это объясняет это. Тем не менее, данные остаются постоянными, когда я запускаю эти запросы (т. Е. Im не повторно вставляя данные каждый раз), но результаты возвращаются, как описано. Конечно, cassandra не повторяет сортировку столбцов без ввода новых данных?
добавлено автор beterthanlife, источник
Поэтому, наконец, я могу подтвердить, что вы были на Джонатане. Переменная часть TimeUUID вызывала переменные результаты. Спасибо всем за вашу помощь.
добавлено автор beterthanlife, источник

Если вы рискуете проявить очевидность, помните, что TimeUUID (версии 1 UUID) выполняют две цели:

  • У них есть компонент, основанный на времени
  • Это UUIDs

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

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

Итак, то, что происходит, - это тонкое взаимодействие двух вышеуказанных пунктов: когда вы создаете новые random-ish TimeUUID в 06/01/2013 12:00:00 , иногда это сортирует перед тем, который вы вставили, и иногда это не так. Если это не так, то первый столбец не будет включен.

Чтобы исправить это, вам нужно сознательно построить невременные компоненты для запроса UUID для сортировки как можно ниже. Например, библиотека pycassa делает это.

4
добавлено
Интересно. Это объясняет это. Тем не менее, данные остаются постоянными, когда я запускаю эти запросы (т. Е. Im не повторно вставляя данные каждый раз), но результаты возвращаются, как описано. Конечно, cassandra не повторяет сортировку столбцов без ввода новых данных?
добавлено автор beterthanlife, источник
Поэтому, наконец, я могу подтвердить, что вы были на Джонатане. Переменная часть TimeUUID вызывала переменные результаты. Спасибо всем за вашу помощь.
добавлено автор beterthanlife, источник

Похоже, что ваша проблема может быть связана с вашим уровнем согласованности. У вас есть 2 реплики, но вы читаете уровень согласованности ONE. Если вы также пишете ONE, вы столкнетесь с проблемами, которые вы описываете. Если вы измените свой уровень чтения на QUORUM (или LOCAL_QUORUM), я думаю, ваши данные никогда не исчезнут. Спорадически исчезающие данные почти всегда являются проблемой согласованности.

Почему это происходит?

Используя вашу настройку 3 узлов с RF = 2, скажем, вы пишете столбец A с CL = ONE. Теперь у вас есть один узел (скажем, N1) со столбцом A, а другой узел, который теоретически получит реплику (скажем, N2), еще не имеет ее. Таким образом, вы получите следующее:

N1: has A
N2: does not have A
N3: will look to N1 or N2 for A

Итак, давайте посмотрим, что произойдет, если, используя CL = ONE, вы спросите каждый узел о A:

N1: you get A
N2: you get nothing because it doesn't check with any other nodes
N3: you may get A or nothing, depending on whether the request gets handled by N1 or N2

Если вы читаете CL = QUORUM:

N1: you get A, and N2 gets updated due to repair on read
N2: you get A, because it checks against N1 and repairs
N3: you get A, because both N1 and N2 will reliably return it

Вы можете легко проверить, не является ли это вашей проблемой, используя чтения QUORUM. Если это так, проблема не появится снова.

0
добавлено
Если вы запрашиваете с помощью cqlsh или cassandra-cli , вы когда-нибудь получаете недостающие данные? Или это просто при запуске вашего приложения?
добавлено автор rs_atl, источник
Я разорвал базу данных и повторно заполнил ее, используя согласованность записи ALL. Когда я запускаю запрос с постоянством чтения ALL, я все равно получаю несогласованные результаты. На самом деле в убытке здесь ...
добавлено автор beterthanlife, источник

Похоже, что ваша проблема может быть связана с вашим уровнем согласованности. У вас есть 2 реплики, но вы читаете уровень согласованности ONE. Если вы также пишете ONE, вы столкнетесь с проблемами, которые вы описываете. Если вы измените свой уровень чтения на QUORUM (или LOCAL_QUORUM), я думаю, ваши данные никогда не исчезнут. Спорадически исчезающие данные почти всегда являются проблемой согласованности.

Почему это происходит?

Используя вашу настройку 3 узлов с RF = 2, скажем, вы пишете столбец A с CL = ONE. Теперь у вас есть один узел (скажем, N1) со столбцом A, а другой узел, который теоретически получит реплику (скажем, N2), еще не имеет ее. Таким образом, вы получите следующее:

N1: has A
N2: does not have A
N3: will look to N1 or N2 for A

Итак, давайте посмотрим, что произойдет, если, используя CL = ONE, вы спросите каждый узел о A:

N1: you get A
N2: you get nothing because it doesn't check with any other nodes
N3: you may get A or nothing, depending on whether the request gets handled by N1 or N2

Если вы читаете CL = QUORUM:

N1: you get A, and N2 gets updated due to repair on read
N2: you get A, because it checks against N1 and repairs
N3: you get A, because both N1 and N2 will reliably return it

Вы можете легко проверить, не является ли это вашей проблемой, используя чтения QUORUM. Если это так, проблема не появится снова.

0
добавлено
Если вы запрашиваете с помощью cqlsh или cassandra-cli , вы когда-нибудь получаете недостающие данные? Или это просто при запуске вашего приложения?
добавлено автор rs_atl, источник
Я разорвал базу данных и повторно заполнил ее, используя согласованность записи ALL. Когда я запускаю запрос с постоянством чтения ALL, я все равно получаю несогласованные результаты. На самом деле в убытке здесь ...
добавлено автор beterthanlife, источник