Каково поведение local_seq в CouchDB 2.x? - PullRequest
Новая
       19

Каково поведение local_seq в CouchDB 2.x?

0 голосов
/ 24 января 2019

В CouchDB 1.x документы имели «скрытое» поле ._local_seq, которое отслеживало последовательность обновления базы данных в состоянии, когда была написана редакция документа. Это может использоваться представлениями путем включения опции {local_seq:true} в проектном документе или извлечения клиентами с помощью опции запроса ?local_seq=true в запросе GET документа.

Это поле все еще доступно в CouchDB 2.x, но неясно, как оно себя ведет. Из-за кластеризации последовательность обновления базы данных теперь является "непрозрачным токеном", тогда как local_seq по-прежнему представляет собой простое целое число, которое на практике не всегда совпадает.

Есть ли какая-либо связь, особенно если я ограничусь кластером из одного узла?

1 Ответ

0 голосов
/ 24 января 2019

Вот что я понял до сих пор:

Для начала, цель local_seq действительно намного менее ясна в CouchDB 2.x. Как уже упоминалось в вопросе, на уровне базы данных / _changes порядковые номера были заменены «непрозрачным токеном», который официально не имеет никакого отношения к local_seq.

Что еще хуже, кажется, что значение local_seq, хранящееся в [или, по крайней мере, выводимом из] каждого документа, не локально для базы данных , а для осколка ! (Каждая база данных внутренне разделена на несколько частей; подробности о Осколках и репликах см. В документации.)

Так, в то время как в CouchDB 1.x можно, например, создать пользовательский фид изменений, отправив local_seq как часть ключа индекса map-Reduce - и он будет соответствовать значениям ?since=N _changes базы данных. feed - в кластерно-ориентированном CouchDB 2.x такое представление будет иметь тенденцию испускать несколько документов [до одного от каждого шарда], которые имеют одинаковое поле ._local_seq друг с другом!

А с другой стороны, в CouchDB 2.x даже "seq", связанный с конкретным документом в фиде _changes уровня базы данных, может меняться от запроса к запросу - и префикс, и / или большой длинный беспорядок после Это. Я не уверен, есть ли способ или какое-либо полезное преимущество, чтобы механизм представления мог предоставить значение «нелокальной последовательности» для функции map, как это делается с локальной последовательностью.

Тем не менее, в CouchDB 2.3.0 я нашел "случайный" способ сохранить некоторую полезность:

  1. Путем создания базы данных с PUT /newdb?n=1&q=1 - то есть настройкой 1 реплики и только 1 шарда - значения local_seq в конечном итоге становятся уникальными в базе данных.
  2. В этих обстоятельствах первая часть каждого seq токена в канале _changes уровня базы данных также кажется совпадает с local_seq каждого измененного документа. То есть если вы разделите строковый токен на '-' и преобразуете первую часть в число, вы получите local_seq.

Я бы использовал это с осторожностью:

  • в случае, если вам нужно необходимо увеличить масштаб и выбрать для этого использование многоузловых функций кластеризации, любой код, основанный на вышеприведенном, сломается
  • это ни в коем случае официально не санкционировано, и теоретически может взломать столько, сколько точечный выпуск. Разработчикам CouchDB было совершенно ясно, что токены уровня _changes непрозрачны и что вы должны обращаться с ними как таковыми.

Итак предостережение хакора и все вышеперечисленное, "совпадения", приведенные выше, соответствуют описанию того, как эти токены работают в данный момент:

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

✅ Если есть только одна последовательность обновлений, сумма должна быть просто исходной последовательностью.

Для данного осколка [канал _changes] полностью упорядочен (осколок идентичен базе данных до 2.0 с целочисленной последовательностью), couchdb не тасует этот вывод […]

✅ Только с одним осколком [н.б. осколок , а не просто один узел / реплика ], вы в значительной степени остались с поведением базы данных до версии 2.0.

...