Что такое лучшая практика при создании идентификаторов документа в couchdb? [закрытый]
Все мы знаем, что для реляционных баз данных это - лучшая практика для использования числовых идентификаторов для первичного ключа.
В couchdb идентификатор по умолчанию, который сгенерирован, является UUID. Лучше придерживаться значения по умолчанию или использовать легко незабываемый идентификатор, который будет использоваться в приложении пользователя?
Например, при разработке базы данных stackoverflow.com в couchdb Вы использовали бы краткий заголовок вопроса (например, what-is-best-practice-when-creating-document-ids-in-couchdb) или UUID для каждого документа?
3 ответа
Я не эксперт по кушеткам, но после небольшого исследования это то, что я нашел.
Простой ответ: используйте UUID, если у вас нет веских причин не делать этого.
Более длинный ответ зависит от:
Стоимость изменения ID Vs Насколько вероятно, что ID изменится
Низкая стоимость изменения и вероятно, что ID изменится
Примером может служить блог с денорализованным дизайном, такой как jchris' blog (код дивана, доступный на git-хабе).
Каждый раз, когда другой сайт ссылается на запись блога, это еще одна ссылка на id, поэтому стоимость изменения ID увеличивается.
Высокая стоимость изменения ID и ID, который никогда не изменится
Примером этого может служить любой дизайн БД, который сильно нормализован и использует ID с авто-инкрементом. Stackoverflow.com является хорошим примером с его автоинкрементирующими идентификаторами вопросов, которые вы видите в каждом URL. Стоимость смены ID очень высока, так как каждый иностранный ключ должен быть обновлен.
Сколько ссылок, или "иностранных ключей" (в реляционном языке БД) будет на ID?
Любые "иностранные ключи" значительно увеличат стоимость смены ID. Обновление других документов - медленная операция, и ее определенно следует избегать.
Какова вероятность изменения идентификатора?
Если вы не хотите использовать UUID, вы, вероятно, уже имеете представление о том, какой ID вы хотите использовать.
Если вероятность изменения идентификатора велика, то стоимость его изменения должна быть низкой. Если это не так, выберите другой ID.
Какова ваша мотивация желания использовать легко запоминающийся ID?
Не говорите о производительности.
Бенчмарки показывают, что "поиск ключей для просмотра CouchDB почти, но не так быстр, как прямой поиск документов". Это означает, что необходимость поиска для поиска записи не имеет большого значения. Не выбирайте дружественные идентификаторы только потому, что вы можете делать прямой поиск документа.
Будете ли вы делать много объемных вставок?
Если да, то лучше использовать инкрементальные UUIDs для лучшей производительности.
Смотрите это пост о групповых вставках. Дэмиен Кац комментирует и говорит:
"Если вы хотите, чтобы у вас был самый быстрый возможное время вставки, вы должны дать повышающиеся значения _ида, так что получите UUID и увеличить его на 1, таким образом. он всегда вставляет в один и тот же место в индексе, и быть кэшированным дружелюбный, когда имеешь дело с файлы размером больше оперативной памяти. Для упрощения способ сделать то же самое, просто последовательно пронумеровывать документы, но сделать его фиксированной длины с набивкой так что они сортируют правильно, "0000001". например, вместо "1"."
_id используется много во внутреннем устройстве CouchDB, и любые дополнительные расходы на хеширование замедлят работу целого ряда внутренних устройств, так что лучше всего придерживаться UUID, входящего в комплект поставки.
Первичный ключ в БД никогда не должен иметь никакого "значения", кроме как, возможно, для кодирования последовательности. Вы можете захотеть изменить SLUG, но не первичный ключ.
Может быть, есть хороший аргумент в пользу использования чего-то, начинающегося с метки времени, чтобы иметь свой собственный порядок следования в ваших ключах. Я часто использую "%f@%s" % (time(), hostname()), чтобы получить упорядоченные, уникальные ключи. (Это работает только если ваша реализация time() никогда не возвращает одно и то же значение дважды.)
Для других вещей (например, изображений), где я хочу избежать дубликатов, я часто использую sha(data) в качестве ключа.
.