Как создать размещенное веб-приложение?

Question

Как бы вы разработали размещенное веб-приложение?Я рассматриваю такие приложения, как Basecamp, Campaign Monitor, Freshbooks и т.д...где пользователи могут зарегистрироваться онлайн, и приложение размещено для них.

1. Будете ли вы использовать 1 большую базу данных для хранения всех данных вашего клиента или будете обрабатывать данные по-другому?Стали бы вы использовать более 1 базы данных?Могли бы вы создать базу данных для каждого клиента?
2. Будете ли вы дублировать свою кодовую базу для каждой регистрации / клиента или будете использовать 1 кодовую базу для обработки всех клиентов?
3. Есть ли другие элементы дизайна, о которых мне следует подумать?
4. Есть какие-нибудь веб-сайты или книги, в которых говорится об этом?

Редактировать:Я нашел статью MSDN, в которой обсуждалась многопользовательская архитектура данных:http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Answer 1

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

Высокая масштабируемость = Архитектура 37signals

Спросите 37сигналов:Как вы обрабатываете кредитные карты?

Что касается количества баз данных, от Дэвида Хайнемайера Ханссона в Что ты хочешь знать?

Некоторые технические ответы…

Лэнс, все наши запланированные выставления счетов операции автоматизированы.Что угодно что-то вроде того, что свело бы нас с ума.Особенно важно убедиться, что предусмотрена обработка в чрезвычайных ситуациях в случае сбоя кредитных карт.Последний раз, когда я просматривал, я полагаю, что 5% наших платежей были списаны благодаря кредитным картам, срок действия которых истек, превысил лимит или они были закрыты.Будьте уверены, что справитесь с этим изящно.

Мы просто используем Authorize.net и отдельное приложение для кредитных карт (крошечное приложение, разработанное в Rails и используемое другими приложениями во внутренней сети через REST ), которое обеспечивает безопасность номеров .

Уоррен, мы запускаем бесплатные и платные аккаунты в одной базе данных.Это одна база данных для каждого приложения.Одна база данных для каждой учетной записи обычно является действительно, действительно плохой идеей.Обычно данные довольно нормализованы, но мы определенно не относимся к этому религиозно.Я обычно ценю свой исходный код больше, чем свою схему.Так что, если я могу получить лучший / симпатичный исходный код, изменив схему, я обычно так и делаю.Но начните с normalized и денормализуйте как того требует производительность или структура кода .

Джейсон, мы используем электронную почту для отправки sms.У всех НАС у операторов связи есть телефон @carrier-gateway.com шлюз.

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

Существует множество других Rails приложений, управляющих десятками миллионов ежедневных запросов.Все следуйте более или менее одному и тому же подходу Shared Nothing.Все методы для масштабирования все выше и выше отсутствуют там.Вряд ли это решение "под ключ" но все, что обещает быть таким, обычно просто переполнено им.

Answer 2

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

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

Не беспокойтесь слишком сильно о проблемах масштабирования СУБД, пока не станет казаться, что у вас может появиться несколько миллионов строк в одной таблице.Тогда, возможно, пришло время исследовать распределенное хранилище ключей / значений.Но имейте в виду, что такого рода проблемы - это хорошая проблема, потому что, по-видимому, это означает, что вы зарабатываете кучу денег.

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

Answer 3

Я работаю консультантом по ряду SaaS-приложений, поэтому видел разные архитектуры.Я бы порекомендовал:

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

   1. В какой-то момент вам захочется начать отслеживать множество способов взаимодействия с пользователем.Для этого вы можете использовать хранилище имен-значений NoSQL и просто начать выбрасывать в него события для последующего анализа.Или используйте что-то вроде MixPanel или KISSmetrics.

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

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