Может ли CouchDB обрабатывать тысячи отдельных баз данных?

Question

Может ли CouchDB обрабатывать тысячи отдельных баз данных на одном компьютере?

Представьте, что у вас есть коллекция BankTransaction с. Есть много тысяч записей. (РЕДАКТИРОВАТЬ: на самом деле не хранить транзакции - просто представьте себе очень большое количество очень маленьких, часто обновляемых записей. Это в основном таблица соединения из SQL-land.)

Каждый день вы хотите получить сводный отчет о транзакциях, которые произошли только в вашем местном отделении банка. Если все записи находятся в одной базе данных, при восстановлении представления будет обрабатываться все транзакций из всех ветвей. Это гораздо большая часть работы, и она не нужна для пользователя, который заботится только о своем конкретном наборе документов.

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

Есть ли другой способ, которым я должен моделировать эту проблему? (Должно ли разделение происходить между отдельными компьютерами, а не отдельными базами данных на одном и том же компьютере?) Если нет, может ли CouchDB обрабатывать тысячи баз данных, которые потребуются для того, чтобы разделы были небольшими?

(Спасибо!)

Answer 1

[Внимание, я предполагаю, что вы используете это в какой-то производственной среде.Просто воспользуйтесь кратким ответом, если это для школьного или домашнего проекта.]

Краткий ответ - «да».

Более длинный ответ: есть некоторые вещи, которые вынужно следить за ...

• Вы будете играть в бяку с множеством системных настроек, таких как максимальные дескрипторы файлов.

• Вы также будете играть в хоккей с настройками erlang vm.

• CouchDB имеет опцию «максимальное количество открытых баз данных».Увеличьте это значение, иначе у вас будут накапливаться отложенные запросы.

• Это будет PITA для объединения нескольких баз данных для генерации отчетов.Вы можете сделать это, опросив фид _changes каждой базы данных, изменив данные, а затем выбросив их обратно в центральную / агрегирующую базу данных.Инструментарий, облегчающий эту задачу, пока отсутствует в API CouchDB.Почти, но не совсем.

Однако самая большая проблема, с которой вы столкнетесь, если попытаетесь это сделать, заключается в том, что CouchDB не масштабирует [хорошо] по горизонтали.Если вы добавите больше серверов CouchDB, все они будут иметь дубликаты данных.Конечно, ваш максимальный счетчик открытых БД будет линейно масштабироваться с каждым добавленным узлом, но другие вещи, такие как время построения представления, не будут (например, им всем нужно будет делать свои собственные построения представления).

Принимая во внимание, что яВы видели тысячи открытых баз данных в кластере BigCouch .Как ни странно, это связано с динамо-кластеризацией: больше узлов параллельно выполняют разные задачи, а не защищенные от копирования серверы CouchDB.

Приветствия.

Answer 2

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

При опросе на конец дня в агрегированной базе данных первая ветвь приведет к обработке 100% новых документов и оплате 100% задержки. Все остальные филиалы будут платить 0%. Так что большинство отраслей выигрывают. При опросе на конец дня в отдельных базах данных все филиалы платят часть штрафа, пропорциональную их объему, поэтому большинство из них немного отстают.

Для частых обновлений просмотра в течение дня активные ветви предпочитают агрегатные, а ветви с малым объемом предпочитают отдельные. Если одна ветка из 10 добавляет 99% документов, большая часть работы по обновлению будет выполняться при опросах других ветвей, поэтому 9 из 10 предпочитают отдельные базы данных.

Если эта задержка имеет значение, и если предположить, что на диване есть несколько тактов, которые не используются, вы можете написать 3-строчный скрипт оболочки loop / view / sleep, который обновляет некоторые документы до того, как какой-либо пользователь ожидает.

Answer 3

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