Приложение Multi-Tenant Rails 3 на Heroku с использованием PostgreSQL

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

Теперь мое Rails-приложение в основном обслуживает JSON, так как большинство шаблонов визуализируются на стороне клиента (с использованием Backbone.js). Поэтому я рассматриваю возможность перехода на MongoDB, потому что 1) каждый арендатор может получить один аккаунт верхнего уровня. документ, и все может быть вложено ниже, и 2) его формат хранения так близко напоминает JSON. Мы все еще находимся в бета-версии, так что это может быть снято. Являются ли эти веские причины использовать Mongo? Бывший даже умный способ использовать Монго?

Если бы я придерживался postgres, должно ли все принадлежать модели аккаунта верхнего уровня (с индексами)? Если так, как бы я справился с объединениями? Можно ли выполнять многоиндексные объединения (всего postgres noob)?

Пока у нас около 60 тыс. Записей в одной таблице, но в одной учетной записи может быть только 200-1000, поэтому я беспокоюсь о присоединении ко всей таблице.

Очень ценю любую помощь.

Обновить:

В итоге мы перешли на VPS (Rackspace Cloud) и внедрили схемы postgres. Нет сожалений с этим ходом, поскольку он бежитmuch быстрее, чем на Heroku, и у нас больше контроля над сервером.

 Maurício Linhares20 июн. 2012 г., 12:38
Да, как обычно.
 brightball20 июл. 2013 г., 05:26
Это создает много дополнительных индексов. Теперь каждый запрос, который вы выполняете почти для каждого поля в этих таблицах, должен фильтроваться по идентификатору учетной записи, что увеличивает сложность и размер вашей структуры индекса и планов запросов. Схемы избегают необходимости во всех этих индексах и значительно упрощают все ваши запросы. Схемы - это оптимальная архитектура, Heroku просто нужно найти способ решить проблему с резервными копиями. Другой вариант, а не полагаться на их резервные копии для вашей основной базы данных, чтобы создать маломощного последователя для резервного копирования. Это также обеспечит оперативную резервную копию.
 kmurph7920 июн. 2012 г., 07:09
@ Maur & # xED; cioLinhares спасибо. Итак, просто добавьте account_id к каждой таблице и индексируйте их, это то, что вы говорите?
 Maurício Linhares20 июн. 2012 г., 03:29
При работе с мультитенантными приложениями каждый из них просто определяет все под таблицей, подобной учетной записи, ничего нового в этом нет, гораздо проще управлять репликацией и даже разделением, когда вы делаете это таким образом, вместо решения с несколькими схемами. Что касается объединений, то это так, но объединения всегда дороги, несмотря ни на что.
 Dondi Michael Stroma20 июн. 2012 г., 06:04
В вопросе недостаточно подробностей, чтобы ответить на него. Просто скажи нам, что у тебя "мультитенантное приложение" недостаточно информации, чтобы помочь вам решить, какое хранилище данных использовать. Любой может быть совершенно уместным. Сколько у вас столов? Как & quot; реляционный & quot; ваши данные?

Ответы на вопрос(1)

который был написан, чтобы сделать многопользовательский с Postgreshttp://railscraft.tumblr.com/post/21421806379/multi-tenanting-ruby-on-rails-applications-on-heroku

Ваш ответ на вопрос