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

возможно ли иметь столбец идентификаторов в documentDB для автоинкремента, это обычно удобно для идентификаторов? Любая ссылка или подсказка, относящаяся к нему, может быть полезной.

спасибо.

8
azure azure-cosmosdb

2 ответов

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

8

по-прежнему (по состоянию на август 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

предостережение: если сохранение документа не удается, у вас есть идентификаторы "призрак", которые могут быть или не могут быть приемлемыми для вас.

обновление: в ответ на комментарий относительно "добавления стоимости RU к каждой операции создания", и "сериализованные все пишет" -да, очевидно, при использовании Counter Document подход это случай при создании документов, требующих инкрементного Identity свойство; никакие другие вставки не будут затронуты.

обе эти "затраты" необходимы для удовлетворения требуемой функциональности при использовании DocumentDB - это по своей сути не поддерживает концепцию Identity свойство; сохраняемость документа для обеспечения восстановления / непрерывности, сериализация для согласованности. Стоимость RU В общем использовании незначительна, и такие методы, как дозирование, могут быть использованы для компенсации этот.

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

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

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

5