Столбец идентификации в DocumentDB

Насколько мне известно, DocumentDB не имеет такой концепции. Каждый документ в DocumentDB имеет свойство id, которое однозначно идентифицирует документ, но это поле id имеет строковый тип. При создании документа вы можете не указывать значение для этого поля, и DocumentDB присваивает идентификатор автоматически, но это значение является GUID. Таким образом, если вы хотите добиться функциональности типа автоматического увеличения, вам нужно будет справиться с этим самостоятельно. Однако имейте в виду, что это свойство типа строки, поэтому, даже если вы обрабатываете это самостоятельно, вам нужно будет дополнить строку нулями, чтобы значения возвращались в правильном порядке, т. е. 1, 2, 3 и т. д. вместо 1, 10, 11,... 19, 2, 20....

До сих пор (по состоянию на август 2016 г.) нет встроенных функций Identity; на форуме обратной связи для DocumentDB есть запрос, за который можно проголосовать здесь. Но имейте в виду, что автоматический счетчик несколько противоречит большинству принципов проектирования NoSQL.

Однако есть несколько подходов, которые можно использовать в качестве обходных путей, и оба имеют оговорку; первый способ - использовать Counter Document, обновленный в хранимой процедуре:

СОХРАНЕННАЯ ПРОЦЕДУРА И ВСТРЕЧНЫЙ ДОКУМЕНТ

1. Создайте документ, который будет содержать свойство числового значения. Либо кэшируйте его самостоятельную ссылку, либо предпочтительнее создайте его с известным идентификатором, таким как «__DocumentType_Counter», а затем вы можете использовать UriFactory для создания ссылки на документ, которая обеспечивает эффективный «прямой» доступ к этому Counter Document.

2. Создайте хранимую процедуру, которая принимает вставляемый документ, и Uri объекта Counter Document. В этой хранимой процедуре выберите значение счетчика, увеличьте его, назначьте его соответствующему свойству вставляемого документа и, если это будет успешно сохранено, сохраните увеличенное значение как обновление документа счетчика.

Этот подход будет работать, так как хранимые процедуры автоматически выполняются как транзакция.

Предостережение. Но в настоящее время Транзакции ограничены рамками Коллекции — вы не можете использовать этот подход с Counter Document в одной Коллекции при вставке Документа в другую.

РЕДИС

Второй вариант для изучения, который добавляет немного больше сложности и немного дополнительных затрат, и не полностью транзакционный с точки зрения увеличения и вставки документа (но, по моему личному опыту, обеспечивает большую пропускную способность). , заключается в создании кэша Azure Redis и сохранении значения счетчика в хранилище значений ключа Redis, которое затем запрашивается и увеличивается с помощью сценария LUA.

Это гарантирует, что запрос значения счетчика и его приращение является атомарной транзакцией, поскольку Redis является однопоточным, а сценарии LUA в основном блокируются до завершения (но выполняются очень быстро).

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

Дополнительную информацию о транзакциях Redis можно найти здесь — Транзакции в Redis< /а>

Совет Эндрю Лю из команды DocumentDB заключается в том, чтобы использовать Counter Document, как указано в связанном вопрос - также обратите внимание на комментарии под ответом Эндрю.

Поскольку хранимые процедуры предварительно компилируются в DocumentDB, они являются эффективным способом выполнения операций "> 1". Они также в настоящее время являются оптимальным способом выполнения транзакции. «Где-то» должно быть единственным источником истины для счетчика; как упоминалось ранее, одним из вариантов является Redis, но, как я указываю, он не является частью транзакции, которая будет отменена в случае сбоя вставки документа, что может быть или не быть приемлемым; в Event Sourcing, например, это не так.