Создание уникальных URL-адресов

Question

Итак, у меня проблема. У меня есть сервер, который пытается создать «красивые» URL-адреса, основанные на данных, которые они предоставляют. Ради обсуждения, можно сказать, заголовки сообщений в блогах. URL-адрес для этого, очевидно, должен быть уникальным, чтобы правильно представлять ресурс. Ну, поправьте меня, если я ошибаюсь .. но это не простая проблема в MongoDB?

Сначала я искал какой-то тип автоинкрементного поля. Это вернуло то, что я ожидал, но была явная проблема. 10gen советует против этого.

Предупреждение Вообще в MongoDB, вы бы не использовать шаблон автоинкрементируемого для поля _ID, или любого поля, потому что она не масштабируется для баз данных с большими номерами документов. Обычно значение ObjectId по умолчанию более подходит для _id.

Обратите внимание на полужирный текст. 10gen не рекомендует увеличивать любое поле.

Итак, вернемся к проблеме. Если я передам серверу заголовок сообщения, и я хочу, чтобы он создал сообщение, я ожидаю, что он автоматически изменит мой заголовок на уникальный заголовок. Например, если я создаю три сообщения с заголовком foo, я хочу, чтобы сервер создавал URL-адреса для /foo, /foo1, /foo2. Хотя, это может быть любая форма уникального дополнения, дело здесь в том, что сервер обрабатывает грязную работу по созданию уникальных URL-адресов, а не просто отказывается и заставляет пользователя неоднократно пытаться создать уникальный URL-адрес.

С учетом сказанного, как это делается в режиме «MongoDB»? 10gen советует против приращений, и в основном единственная уникальная строка, которую я могу найти, - это ObjectID, но /foo50bbe1573b60ff0000000002 вряд ли «красиво». Вы должны признать, что если вы вынуждены использовать /foo50bbe1573b60ff0000000002, вы можете просто использовать /50bbe1573b60ff0000000002. «хорошенький» был давно ушел после первых 5 персонажей.

Итак, любые мысли и мнения о том, как справиться с этой проблемой в дружественной манере MongoDB?

Потенциальный ответ: Одним из ужасных решений является повторное создание документа до уникальных проходов, но не более X раз. Например,

1. вы можете попробовать написать его с названием
2. , если это не удается записать его с названием плюс значение приращения ObjectID (скажем, 00002)
3. Если это не удается, писать со всем богом чертовски объектив. В любом случае, мы уже проиграли.

Потенциал Ответ: Другой потенциальный ответ, просто делать то, что 10gen советует, что делает поле Приращение.

Из двух вышеупомянутых решений я уверен, что каждый из них более эффективен с различными методами .. например: решение 1, вероятно, лучше всего, если ваше уникальное поле, скорее всего, будет уникальным, скажем, 40 символов введенных пользователем данных. Это потенциально медленно, как меласса, если вы имеете дело с 4 символами.

Редактировать: лучше ответ Сочетание двух было бы лучше всего, я думаю. Имейте коллекцию «оригинальных» URL-адресов (например: /foo), с учетом того, сколько раз они были написаны. Добавьте граф к целевому URL-адресу, и у вас есть уникальный URL-адрес. Я считаю, что это будет баланс между проблемами производительности, которые 10gen советует против, а также все еще дает вам прирост.

Answer 1

10gen предупреждает о том, чтобы установить какой-то пессимистический параллелизм на месте или использовать javascript на стороне сервера, чтобы найти текущий максимальный ключ для коллекции ENTIRE, а затем увеличивать его и возвращать новый _id. MongoDB предназначен для огромных коллекций, которые часто зависят от огня и забывают вставки/обновления. По характеру приложения, которое вы описываете, ничто из этого не является препятствием (гораздо важнее, чем советы 10gen, это ваше знание проблемной области и то, как это может взаимодействовать с предметом, о котором они предупреждали).

Лучше схема, которая не идет вразрез с советом 10gen было бы построить URL из какого-то другого атрибута поста, т.е. имя пользователя, дату и время он был создан, и т.д.

в вашем пример записи в блоге, вы можете иметь пути URL-адреса, которые выглядят как

/сообщений/Имя пользователя/2013/3/5/название-оф-моему столбу

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

{ _id: ObjectId (...), имя_пользователя: "Username", dateCreated: ISODate ("2013-03-05"), название: «название моего поста», тела: «...» }

с уникальным индексом на {dateCreated: -1, userName: 1, title: 1} (это было бы установить вас хорошо на сортировку и заказал сообщения пользователя, а также).