2014-01-19 4 views
2

Размер автогенерируемого идентификатора в MongodDB равен 12 Bytes, а размер большого целого - 8 bytes. У меня есть кластер mongodb на 4 машинах с Ubuntu Server, но сейчас я просто тестирую их. Вставки могут выполняться только через один сервер, который является сервером nodejs, но обновления и удаления могут выполняться с использованием различных машин, на которых запущено собственное приложение c по всему миру и сервер nodejs.MongoDB auto increment ID

Поскольку у меня есть полный контроль над вставками, не лучше ли использовать идентификатор автоматического увеличения?

  • в 1 МБ памяти можно сохранить 87381 12 байты идентификаторов и 131027 из 8 байт идентификаторов.
  • Стоит ли его использовать для увеличения количества инкремента и есть ли преимущество , кроме экономии памяти?
  • по производительности не сравнивал бы 8-байтовый идентификатор быстрее, чем байтовый идентификатор 12 , и не уменьшал бы размер, если бы я индексировал?

Как я делаю это:

У меня есть этот документ

{id:0 latestId:174845423} 

я очень редко увеличиваем его на 1, большинство моих вставок сыпучие вставки, так что сервер nodejs изменяет документы для вставки в цикле, в котором каждый из них имеет увеличенный идентификатор, в конце операции вставки я добавляю i обновляю последний идентификатор с последним значением id.

+2

Как часто вы можете создать новый идентификатор? Поймите, что в MongoDB нет типа «auto incremented field», поэтому вам нужно будет использовать такие шаблоны, как: http://docs.mongodb.org/manual/tutorial/create-an-auto-incrementing-field/ – WiredPrairie

+0

@WiredPrairie 98% моих ежедневных операций читает и обновляет, так как я сказал, что вставки происходят только на одном сервере nodejs, поэтому я могу создать документ с полем идентификатора и добавить к нему, когда операции вставки будут выполнены, они обычно вложенные вставки, поэтому я могу добавить идентификатор к вставленным документам и в конце вставки, увеличивать документ id по количеству вставленных документов, поэтому операции вставки организованы, и я полностью контролирую их – Kanka

+1

Если вы можете гарантировать, что идентификаторы будут уникальными и что процесс узла никогда не повторит идентификатор, вы можете его использовать. Однако, если процесс узла внезапно умирает ... как вы перезапустите генерацию идентификаторов, если вы не сохранили последнее значение где-то за пределами процесса узла? – WiredPrairie

ответ

5

«Автоинкремент» всегда является проблемой при работе с распределенной системой, поскольку он создает бутылочную горловину: каждый новый приращение должен читать предыдущие данные .. как и другие параллельные запросы.

Вообще говоря, «автоинкремент» ограничивает параллелизм, особенно в распределенных системах.

+0

Я буду делать приращения на сервере nodejs, прежде чем вставлять документы, на которых узел nodejs отслеживает последний идентификатор, поэтому я не буду полагаться на базу данных, чтобы получить последнее значение id , поэтому таким образом я не буду читать предыдущие данные, в этом случае не будет ли эта конфигурация лучше, чем автоматически сгенерированный идентификатор? – Kanka

+0

Похоже, вы только перемещаете узкое место из БД на сервер nodejs. Возможно, вы должны задать себе вопрос, будет ли это узкое место ограничивать вас или нет. Если это не так, то не думайте слишком много и продолжайте свою программу в любом случае. – Vincent