Селективная репликация с помощью CouchDB

В настоящее время я оцениваю возможные решения проблемы:

Набор записей данных должен быть синхронизирован между несколькими клиентами, где каждый клиент может просматривать (или даже знать о существовании) подмножество данных. Каждый клиент "владеет" некоторыми элементами, и решение, которое еще может читать или изменять эти элементы, может быть сделано только владельцем. Чтобы еще больше усложнить эту ситуацию, каждый элемент (и каждая ревизия элемента) должен иметь уникальный идентификатор, равный для всех клиентов.

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

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

Я также был бы благодарен за указания относительно подробной информации о том, как работает репликация. Вики CouchDB и даже книга "Определенное руководство" не слишком конкретны.

Ответы

Ответ 1

это требует фильтров репликации. вы фильтруете исходящую репликацию на основе любых критериев, которые вы навязываете, и предоставляете владельцу неограниченного доступа к своей собственной копии.

У меня не было возможности напрямую играть с фильтрами репликации, но идея заключалась бы в том, что каждый док будет иметь некоторую информацию о том, кто имеет к нему доступ, и механизм фильтрации затем разрешает исходящую репликацию только тех документов, которые у вас есть доступ. репликация с целевого объекта обратно на ведущего будет неограниченной, позволяя мастеру оставаться копией накопителя и потенциально многоадресные изменения для перекрытия наборов данных.

Ответ 2

Зачем вам нужны фильтры репликации. По словам Криса Андерсона, это функция 0,11.

"Текущий статус - это то, что есть API для фильтрации _changes корм. Репликатор в 0,10 потребляет изменения подаются, поэтому следующий шаг получение репликатора для использования API фильтра.

На этом есть работа, поэтому он должен быть полностью готов к работе 0,11".

Смотрите исходный пост

Ответ 3

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

Одно предостережение, которое я бы добавил, заключается в том, что фильтры масштабирования масштаба могут быть чрезвычайно медленными. Более подробную информацию об этом и других нюансах о couchdb можно найти в этом превосходном сообщении в блоге: "что каждый разработчик должен знать о couchdb" . Для крупномасштабных систем, выполняющих репликацию на прикладном уровне, оказалось быстрее и надежнее.