Стратегии масштабирования для приложений ASP.NET - Масштабирование баз данных
ОГЛАВЛЕНИЕ
Масштабирование баз данных
Нормальный подход к масштабированию веб-узлов – это добавление систем вместо их наращивания. В основном это обусловлено ограничениями потоков и памяти ASP.NET в сочетании с краткосрочной природой веб-запросов.
Однако, когда дело доходит до масштабирования баз данных, обычной практикой является наращивание – одна гигантская система, возможно две в кластере (хотя только одна реально несет на себе базу данных в каждый конкретный момент времени). Но рано или поздно каждое крупное веб-приложение доходит до стадии, когда одной базы данных недостаточно. Необходимо расширяться. Если возможно, достаточно применить те же стратегии масштабирования, что и к самому веб-приложению. Первым действием всегда является специализация – разбиение базы данных на логические разделы. Эти разделы могут быть основаны на разделении данных, возможно по регионам. В результате получится несколько баз данных, каждая из которых содержит часть изначальной базы данных. Например, один сервер будет содержать данные по восточному берегу США, а второй по западному берегу.
Однако действительно большие веб-приложения разделяют свои базы данных на базы чтения и записи (см. рис. 6). Базы данных чтения предназначены только для чтения, они получают свои данные от баз данных записи посредством репликации. Все запросы данных направляются базам данных чтения, оптимизированным на как можно более быстрое чтение данных. Базы данных чтения по своей природе легко распределяемы.
Рис. 6 Distributed Database Architecture
Все запросы на запись данных отправляются базам данных записи, которые разбиты на разделы и настроены на эффективную запись. Репликация перемещает новые данные с баз записи на базы чтения.
Создание таких специализированных баз данных ведет к задержке: у записи будет уходить некоторое время на распределение по базам данных чтения. Но если с задержкой удастся разобраться, то потенциал масштабирования огромен.