Архитектура приложения — CouchDB и MongoDB

Я разрабатываю приложение с двумя типами данных:

1) Профиль пользователя — имя пользователя, электронная почта, идентификатор пользователя, токены доступа, идентификаторы сеансов, AvatarUrl и т. д. Для каждого пользователя эти данные будут составлять около 20 КБ, а для активного пользователя данные будут считываться 100 раз/день и записываться до 5 раз/день. . Я думаю об использовании ObjectRocket (MongoDB) или Cloudant (CouchDB с кластеризацией). такое количество редакций документов очень быстро исчерпает дисковое пространство и в целом не будет работать так же хорошо, как MongoDB. Я склоняюсь к MongoDB. Любые предложения для этого типа данных?

2) Транзакции между пользователями — Пользователь А отправляет пользователю Б 8 баллов — проверьте баланс баллов Пользователя А, если > 8, дебетуйте Пользователя А и зачислите Пользователю Б. Каждая транзакция будет иметь размер около 2 КБ и, скорее всего, никогда не будет обновлена ​​или удалена (бухгалтеры не используют ластики). Для этого я думаю об использовании CouchDB (Cloudant) с представлениями Map/Reduce, где представления будут отслеживать балансы пользователей. Эти данные, конечно, чрезвычайно важны для целостности приложения, и я думаю, что Couch позволит мне лучше спать по ночам (особенно с репликацией master/master, дизайном только при сбоях и мульти-географической избыточностью Cloudant). Любые другие предложения для этого типа данных?

В общем, хотелось бы для простоты использовать один тип БД, НО кажется, что иногда для постройки дома нужен молоток и отвертка. Имеет ли смысл использовать Mongo (ObjectRocket) для типа данных №1 и Couch (Cloudant) для типа данных №2?


nosql mongodb couchdb cloudant
person Justin Cloud    schedule 19.07.2013    source источник
comment
2) транзакции не поддерживаются ни в одной из выбранных вами БД. Например, база данных Windows Azure SQL поддерживает нераспределенные транзакции.   -  person WiredPrairie    schedule 19.07.2013

Ответы (2)


arrow_upward
2
arrow_downward

1) В Cloudant вам не нужно беспокоиться о месте на диске из-за предыдущих правок — мы автоматически запускаем сжатие для очистки старых неконфликтных версий в фоновом режиме.

2) Это можно смоделировать в CouchDB/Cloudant, создав новый документ для каждого кредита или дебета и используя представление с уменьшением карты для создания баланса учетной записи. Полностью рабочий пример описан в Полном руководстве по CouchDB. Логика вашего приложения будет выглядеть следующим образом:

  1. дебетовый пользователь А
  2. подтвердить, что пользователь А имеет достаточно кредитов (например, все еще имеет положительный баланс после дебета)
  3. кредитный пользователь B

Если 2 или 3 не работают, кредитуйте пользователя А и уведомите об этом соответствующим образом.

person Will Holley    schedule 22.07.2013

arrow_upward
1
arrow_downward

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

2) Это то, где вам понадобятся транзакции, а возможная согласованность CouchDB или Cloudant не подходит. Я не уверен, предоставляет ли MongoDB то, что вам нужно. Безопаснее всего здесь использовать реляционную базу данных.

person Kim Stebel    schedule 19.07.2013
comment
Поскольку MongoDB имеет настройку master-slave, то, если запись будет выполнена успешно, она будет немедленно доступна для чтения, поэтому транзакции, подобные описанным в [2], будут работать в Mongo, но могут быть шаткими в CouchDB/Cloudant из-за согласованности в конечном итоге. AKA Mongo строго последователен: stackoverflow.com/questions/11292215/ Тем не менее, настройки master-slave плохо масштабируются, и блокировка записи Mongo будет останавливать чтение и запись до тех пор, пока запись не завершится успешно. Другие заботы для размышления. - person garbados; 20.07.2013