Что ж, архитектура Facebook обладает высокой масштабируемостью, и у них есть много «передних дверей» для запросов данных, и есть реальные возможности для эффективного анализа данных.
Первый вопрос: сколько одновременно работающих пользователей должно обрабатывать это приложение? <100, просто убедитесь, что ваш слой данных хорошо проиндексирован и что вы делаете «умные» запросы (получите именно те данные, которые необходимы для отображения страницы, не больше и не меньше, используя индексированные критерии). Если для запроса нужно вернуть много данных, разбейте их на части в запросе (<code>SELECT TOP 25 ... FROM Activity WHERE Activity.Date < <date of the last record of the last page you retrieved>). Несколько сотен, подумайте о сервере репликации, чтобы разделить нереальные или менее часто используемые задачи или просто распределить нагрузку. Большие сотни, начинайте думать о кластере серверов с распределенными таблицами и массовой доставкой транзакций. Более того, вы вне моей компетенции в области архитектуры предприятия.
Ваши первые шаги в любом случае:
- Профиль вашей БД. Просмотрите запросы, создаваемые каждым действием, которое может выполнить пользователь, и критически оцените, является ли этот запрос наиболее эффективным способом выполнения работы. Рефакторинг основанных на курсоре операций; вы НЕ ХОТИТЕ, чтобы они выполнялись в любой операции, которая должна быть выполнена быстро, потому что они закорачивают большую часть силы, которую движок SQL может дать вам в изнурительных числах.
- Определите критерии, наиболее часто используемые для фильтрации / получения результатов, особенно с равенством, и создайте эти кластерные первичные ключи. Кластерный ключ заставит сервер размещать данные с одинаковыми критериями на одних и тех же страницах данных для более быстрого поиска данных, которые могут быть извлечены в блоках. Будьте осторожны, хотя; слишком много индексов снизит производительность.
- Если запрос выглядит хорошо и выполняется по хорошо проиндексированной схеме, но он все еще медленный, рассмотрите возможность рефакторинга запроса в табличную функцию или хранимую процедуру. Они предварительно скомпилированы, и план запроса предварительно спроектирован, что экономит ваши накладные расходы при обычном обращении к БД. Они также требуют меньше информации для отправки по сети.
- Кэширование результатов некоторых более дорогих запросов, особенно данных, совместно используемых несколькими страницами, и / или данных, которые вряд ли быстро изменятся, в хранилище сеансов или другом хранилище в памяти на стороне веб-сервера. Вам понадобится много памяти на вашем веб-сервере.
- Все еще недостаточно? Добавьте больше аппаратных средств в компьютер сервера БД.
- Рассмотрим распределенную модель; большинство основных СУБД могут работать в кластерной среде. Как вы структурируете эту модель, зависит от вашей схемы и выполненных операций; Чаще всего разделение данных по географическим регионам работает хорошо даже для такого гиганта, как Facebook.
- Пока вы все это делаете, вы можете сделать пользовательский интерфейс более отзывчивым, включив асинхронные технологии, такие как AJAX; кадр вашей страницы может загружаться и отображаться в браузере, пока сервер БД все еще работает, тогда данные могут следовать асинхронно и отображаться на странице с задержкой.