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

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

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

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

Источник

1 ответ

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

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

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

Так что, в то время как в CouchDB 1.x можно, например, создать пользовательский канал изменений, отправив local_seq как часть ключа индекса карты-уменьшения - и он будет совпадать с ?since=N значения канала _changes базы данных - в 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 не перемешивает этот вывод […]

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

Источник
Другие вопросы по тегам