Действительно ли неправильно создавать версии документов, используя стандартное поведение CouchDB? - PullRequest
Новая
       16

Действительно ли неправильно создавать версии документов, используя стандартное поведение CouchDB?

5 голосов
/ 27 апреля 2010

Это один из тех, "Я знаю, что не должен этого делать, но это так удобно". вопросы. Извините за это.

Я планирую использовать CouchDB для хранения нескольких документов и сохранения всей их истории изменений. CouchDB выполняет управление версиями автоматически, но это настоятельно не рекомендуется для использования программистами :

«Вы не можете полагаться на редакции документов для каких-либо иных целей, кроме контроля параллелизма».

Из того, что я нашел в вики CouchDB, версии могут быть удалены либо во время сжатия , либо во время репликации . Насколько я могу судить, сжатие всегда должно запускаться вручную, а репликация происходит только при наличии более одного сервера базы данных.

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

С какими еще проблемами я могу столкнуться? Например. Разве сжатие не снижает производительность и не потребляет значительно больше дискового пространства (чем если бы я управлял версионированием вручную)?

Ответы [ 2 ]

8 голосов
/ 27 апреля 2010

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

Поэтому я бы не стал полагаться на это, потому что в нашей отрасли подобные вещи будут преследовать вас через 6 месяцев, если вы не можете абсолютно гарантировать, что никогда не обновите CouchDB.

4 голосов
/ 27 апреля 2010

Если это неправильно, то я не хочу быть правым!

На самом деле нет. Это не правильно. Майкл хорошо объяснил: в лучшем случае это делает ваше приложение не очень перспективным, а в худшем случае вы получите серьезные ошибки, которые вынудят вас перестроить в неудобное время.

Рассмотрим Google App Engine. Каков их предполагаемый образец транзакции?

  1. Начать транзакцию
  2. Получить ваши сущности по ключу
  3. Изменить сущности и сохранить их
  4. Завершение транзакции

Они формируют функцию, которая повторно запускается в случае сбоя транзакции. Зачем? И почему выборка должна быть внутри транзакции, а не зависать во внешней области видимости?

Потому что App Engine использует MVCC для внутреннего использования. Если вы получили коллизию (ваша ревизия неверна, потому что кто-то другой обновил), тогда они просто перезапустят вашу функцию. Следующая итерация извлечет более новую ревизию, обновит из более новых данных и вернет с правильной ревизией. Дело в том, что Google не предоставляет это пользователям, потому что это не подходящая среда для создания версий на уровне приложений.

...