Как лучше хранить большие объекты JSON в couchDb?

Я работаю над веб-приложением, в котором хранятся данные о проектах. Данные сохраняются в базе данных couchDb A. Приложение извлекает и отправляет данные в локальную базу данных pouchDb B, которая синхронизируется с A.

Таким образом, приложение может работать и в автономном режиме. Когда у пользователя есть соединение, изменения, сделанные на localDb B в автономном режиме, отправляются в A с использованием классической репликации.

Я храню по одному документу на проект в couchDb, это большой объект JSON с большим количеством данных (задачи проекта, сотрудники, достижения, риски, проблемы и т. д.).

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

Пользователь A не в сети, и он добавляет задачу в проект 1.

Пользователь B в сети, и он добавляет нового соавтора в проект 1.

Изменения пользователя B передаются в couchDb с помощью автоматической синхронизации.

Увеличен проект 1 _rev.

Пользователь Б извлекает свои изменения из couchDb, потому что приложение загружает все документы при любых обнаруженных изменениях couchDb. Странно ... Я знаю, как этого избежать. Но приложение по-прежнему работает нормально, так что это не большая проблема.

Пользователь A восстанавливает соединение.

Изменения пользователя A игнорируются из-за более старого _rev. Но пользователь внес изменения в другое свойство проекта, может ли couchDb сам обнаружить это и объединиться с более новым _rev?

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

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

Как с этим справиться? Проект может содержать в среднем от 10 до 10 000 свойств, которые несколько пользователей могут редактировать как онлайн, так и офлайн.


person sylvain1264    schedule 06.05.2015    source источник
comment
У кого-то недавно была похожая проблема (они пытались засунуть все свои данные в один документ), и ответ, который я дал, может быть вам полезен: stackoverflow.com/a/30029965/680742   -  person nlawson    schedule 06.05.2015
comment
спасибо, я проверю это   -  person sylvain1264    schedule 06.05.2015


Ответы (1)


Но пользователь внес изменения в другое свойство проекта, может ли couchDb сам обнаружить это и объединиться с более новым _rev?

Обработка конфликтов PouchDB / CouchDB описана в руководстве по PouchDB: http://pouchdb.com/guides/conflicts.html

приложение загружает все документы при обнаружении любых изменений couchDb. Странно ... Я знаю, как это предотвратить.

Это стандартное поведение PouchDB / CouchDB - вы попросили его синхронизировать всю базу данных, поэтому он синхронизировал всю базу данных. :) Вы можете предотвратить это, используя репликацию с фильтром: http://pouchdb.com/api.html#filtered-replication.

Как с этим справиться? Проект может содержать в среднем от 10 до 10 000 свойств, которые несколько пользователей могут редактировать как онлайн, так и офлайн.

Это действительно действительно зависит от ваших данных, от того, как часто они могут меняться, каков уникальный идентификатор одного «свойства» ... Хранение 10 000 отдельных документов в PouchDB / CouchDB - не сумасшедшая идея, и может помочь вам, когда дело доходит до конфликтов, поскольку только эти отдельные документы могут конфликтовать.

В общем, я бы рекомендовал вам прочитать руководство по разрешению конфликтов, как описано выше, и изучить возможные варианты. Также есть плагин, который может помочь вам в разрешении конфликтов: https://github.com/jo/pouch-resolve-conflicts

person nlawson    schedule 06.05.2015
comment
спасибо за это прекрасное объяснение, теперь оно мне более понятно! Думаю, я разделю проекты на несколько документов. - person sylvain1264; 06.05.2015