2016-10-23 2 views
0

Поскольку objectID хранится на 12 байтах и ​​даже не подходит для ключа осколка, я спрашиваю себя, не лучше ли использовать вместо этого случайный int64 (8 байтов) для _id?MongoDB: лучше ли использовать int64 или ObjectID для _id?

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

Что вы думаете об этом?

+0

По-моему, это дизайнерское решение, и я не уверен, почему вы выбрали ObjectID для осколков. Концепция оштукатуривания распространяется на нагрузку. Поэтому подумайте о том, какое поле имеет смысл распространять нагрузку в вашем дизайне. – Elyasin

ответ

1

Я бы настоятельно рекомендовал вам никогда не произвольно сгенерированное число как уникальный идентификатор. Во-первых, вам всегда нужно будет проверить, существует ли это, когда вы вставляете новую запись, потому что вы никогда не сможете действительно создать уникальное случайное число. Еще одна довольно очевидная причина в том, что int64 имеет предел.

Используйте ObjectId для _id, это то, что он нужен, или если у вас есть очень хорошая причина, чтобы не использовать GUIDs

Смотрите здесь:

Considerations when selected a shard key

+0

, но objectID не может использоваться как shardkey, поэтому это означает, что мне нужно будет иметь еще один индекс в памяти (возможно, hashed of objectID) – loki

+0

Вы производите штамп другого поля с произвольно сгенерированным номером и используете его в качестве ключа осколка, если вы действительно хотят, или включают нецифровые символы, и изобретают более уникальный способ генерации уникальных ключей. Ключ осколка не обязательно должен быть одним полем, вы можете использовать сложный осколочный ключ. Я бы не использовал случайное число для вашего _id. Я обновил свой ответ, чтобы включить ссылку для вас на клавиши осколка – pieperu

+0

@loki Это можно использовать как ключ осколка, это очень плохо. –

1

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

+0

Какой вид накладных расходов. Поле '_id' может быть _anything_, поэтому зачем беспокоиться о том, чтобы спрятаться вокруг. UUID будет таким же хорошим. –

+0

, но uuid на 16 байт? это не вопрос? – loki

Смежные вопросы