локальный UUID и уникальный сетевой идентификатор счетчика

Какой из них вы выберете в качестве реализации суррогатного ключа?

  • Local UUID
    • That is generated locally in the application, no network trip to retrieve it
    • Но длина велика и может повлиять на размер используемого вами хранилища.
    • Длинный URL с длинным UUID
    • Малейший страх, что произойдет столкновение UUID
  • Or .. Network-unique-counter id (not sure on what is the proper term for this)
    • I imagine a remote Redis with the atomic INC or Mongo with $inc
    • Стоимость поездки по сети
    • Гораздо короче, занимает меньше места и приводит к гораздо более короткому URL-адресу.
    • Не бойтесь столкновений, даже в кластерных приложениях

nosql web-applications mongodb redis uuid
person Albert Gan    schedule 09.03.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Для приложения с низким параллелизмом вы, вероятно, можете использовать идентификатор сетевого счетчика. Но, кроме URL, нет интереса к низкому параллелизму (= мало данных).

В случае тяжелого параллелизма, большого количества данных и большого количества кластеров, ваш механизм перераспределения + связанная с ним сеть, вероятно, будут медленными для этого решения.

В заключение: - сетевой счетчик кажется привлекательным, но бесполезным, на мой взгляд, с MongoDB.

При коллизии MongoDB из-за алгоритма создания коллизия близка к нулю. Я объясняю, что часть uuid построена с адресом компьютера, который должен быть уникальным, и вы можете получить этот адрес перед запуском своего кластера в производство.

person Aurélien B    schedule 09.03.2012

arrow_upward
2
arrow_downward

Если вы используете MongoDB, вам следует изучить использование BSON ObjectID:

http://www.mongodb.org/display/DOCS/Object+IDs

Они создаются по умолчанию как поле _id, если вы не укажете иное и не создадите поле _id самостоятельно (которое также может быть ObjectID, только что созданным вами). Не бойтесь коллизий, и вы можете получить изначально поддерживаемый тип идентификатора в БД, который вы также можете использовать в своем приложении. Похоже, беспроигрышный вариант, если вы, конечно, используете MongoDB;)

person Adam Comerford    schedule 09.03.2012
comment
Спасибо за понимание. В настоящее время я генерирую UUID из приложения, думая немного разгрузить монго. - person Albert Gan; 10.03.2012
comment
Если вы создаете полный UUID, похожий на uuid mongo, я настоятельно рекомендую позволить Mongo сгенерировать его для вас. Поэтому, когда вы будете использовать шардинг, генерация Mongo всегда будет быстрее, чем у вас. - person Aurélien B; 10.03.2012

arrow_upward
2
arrow_downward

Вы можете комбинировать оба подхода. Посмотрите на алгоритм SnowFlake в Твиттере. Алгоритм будет производить глобальные уникальные целые числа (64 бита), но без какой-либо координации, чисто локальный алгоритм.

person Tobias P.    schedule 11.03.2012