MongoDB/ NoSQL: Сохранение Истории Изменений Документов

хороший вопрос, я тоже занимался этим.

создать новую версию на каждом изменении

я наткнулся на модуль управления версиями монгольского водителя для Руби. Я сам им не пользовался, но от что я мог найти, он добавляет номер версии каждого документа. Более старые версии встроены в сам документ. Основным недостатком является то, что весь документ дублируется при каждом изменении, что приведет в большом количестве дубликатов контента, хранящихся при работе с большими документами. Этот подход хорош, хотя, когда вы имеете дело с документами небольшого размера и/или не обновляете документы очень часто.

только хранить изменения в новой версии

другой подход -хранить только измененные поля в новой версии. Затем вы можете "сгладить" свою историю, чтобы восстановить любую версию документа. Это довольно сложно, хотя, как вам нужно отслеживание изменений в модели и сохранение обновлений и удалений таким образом, чтобы приложение могло восстановить обновленный документ. Это может быть сложно, поскольку вы имеете дело со структурированными документами, а не с плоскими таблицами SQL.

Сохранить изменения в документе

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

{
  _id: "4c6b9456f61f000000007ba6"
  title: [
    { version: 1, value: "Hello world" },
    { version: 6, value: "Foo" }
  ],
  body: [
    { version: 1, value: "Is this thing on?" },
    { version: 2, value: "What should I write?" },
    { version: 6, value: "This is the new body" }
  ],
  tags: [
    { version: 1, value: [ "test", "trivial" ] },
    { version: 6, value: [ "foo", "test" ] }
  ],
  comments: [
    {
      author: "joe", // Unversioned field
      body: [
        { version: 3, value: "Something cool" }
      ]
    },
    {
      author: "xxx",
      body: [
        { version: 4, value: "Spam" },
        { version: 5, deleted: true }
      ]
    },
    {
      author: "jim",
      body: [
        { version: 7, value: "Not bad" },
        { version: 8, value: "Not bad at all" }
      ]
    }
  ]
}

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

{
  author: "xxx",
  body: [
    { version: 4, value: "Spam" }
  ],
  state: [
    { version: 4, deleted: false },
    { version: 5, deleted: true }
  ]
}

С каждым из этих подходов вы можете хранить актуальную и сплющенную версию в одной коллекции и данные истории в отдельной коллекции. Это должно улучшить время запроса, если вас интересует только последняя версия документа. Но когда вам нужны как последняя версия, так и исторические данные, вам нужно будет выполнить два запроса, а не один. Таким образом, выбор использования одной коллекции против двух отдельных коллекций должен зависеть от как часто ваше приложение нуждается в исторических версий.

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

С нетерпением ждем отзывов об этом, а также решений других людей для этой проблемы :)