База данных _replicator не масштабируется, или мой дизайн нуждается в настройке
Я думаю, что важно, чтобы я уточнил, откуда я иду, чтобы вы могли понять мой вариант использования, пожалуйста, потерпите меня.
Предыстория: я пытаюсь перенести мое приложение с CouchDB 1 на 2, и эта миграция потребует немалого труда. Я просто хочу дважды проверить, что я не изобретаю велосипед, и убедиться, что нет лучшего дизайна, чем то, о чем я расскажу ниже, тем более, что у CouchDB 2, похоже, есть некоторые потрясающие новые функции.
Рассмотрим следующий упрощенный вариант использования приложения, которое позволяет студентам отправлять ответы на вопросы в цифровом виде. Каждый ученик должен иметь возможность представить свои ответы на вопросы, а учитель должен просмотреть все ответы. Этот дизайн должен работать с PouchDB, так как PouchDB напрямую обращается к БД, и это экономит нам много времени, так как в противном случае необходимо было бы написать сложный набор API.
Мой выбранный дизайн состоит из одной базы данных на каждого учащегося и одной базы данных на каждого учителя, то есть базы данных на пользователя. Только владелец базы данных может редактировать свою базу данных, и это осуществляется через роли CouchDB. Когда студент отправляет ответ, он синхронизируется с его / его базой данных через PouchDB. Ответы затем копируются в базу данных учителя. Это, в свою очередь, позволяет учащимся быстро загрузить свои ответы в приложение, а учителям - загрузить все ответы для всех своих учеников. Конечно, в базах данных учителей есть представления, которые разбивают ответы по классам, викторинам и т. Д., Так что учитель не должен загружать ответы сразу для всех своих учеников. Если бы у нас не было базы данных для учителей, тогда учитель должен был бы иметь доступ ко всем базам данных учеников и синхронизироваться со всеми базами данных своих учеников.
На первый взгляд, база данных _replicator является очевидным способом репликации данных из баз данных учеников в одну базу данных учителей. Суть в том, что когда вы используете непрерывную репликацию, она использует дескриптор файла и соединение с базой данных, что означает, что вы можете очень быстро истощить базу данных ее ресурсов. Например, если в нашей базе данных, скажем, 10000 студентов, то для репликации нам потребуется 10000 одновременных файловых дескрипторов и соединений с базой данных. Это довольно безумно, учитывая, что маловероятно, что даже 100 из этих 10000 студентов будут использовать приложение одновременно.
Вместо этого я разработал сервис, который прослушивает канал _db_updates, а затем реплицирует базу данных только при изменении этой конкретной базы данных. Используя этот метод, мы беспокоимся только о потреблении ресурсов, когда есть изменения, и в результате мы получаем множество свободных файловых дескрипторов и соединений с базой данных.
Я кратко экспериментировал с CouchDB 2, и оказалось, что база данных _replicator так же жадна с ресурсами, как и в CouchDB 1.
Является ли этот дизайн базы данных на пользователя как для студентов, так и для преподавателей лучшим решением или есть лучшее решение? Если это лучшее решение, есть ли лучший способ репликации этих данных, который не потребляет столько ресурсов?
1 ответ
Я открыл свое решение под названием Spiegel, которое предоставляет недостающую часть: масштабируемую репликацию CouchDB и прослушивание изменений. Spiegel в настоящее время используется в производстве с дизайном db-per-user и эффективно обрабатывает репликацию более 10000 баз данных для Quizster.