2.5. Основные требования.

К архитектурам современных серверов баз данных выдвигаются четыре основных требования: расширяемость, производительность, OLCP, доступность.

2.5.1. Расширяемость.

Расширяемость – это свойство системы, которое допускает предсказуемую поддержку дополнительных пользователей, более высокую производительность, пропускную способность и т.д. путем добавления вычислительных ресурсов и без изменения приложений и административного сопровождения. Существует два способа расширения сервера баз данных: горизонтальный и вертикальный. Горизонтальное может быть получено, когда несколько серверов действуют независимо и делят рабочее пространство. Этот метод более применим для слабосвязанных систем и распределенных баз данных, однако он требует дополнительной административной поддержки. Вертикальное расширение, затрагивающее отдельный сервер, может быть достигнуто путем добавления к платформе дополнительных ресурсов, как, например, более быстрых процессорных элементов или дополнительных процессоров, с целью уменьшения времени отклика или увеличения пропускной способности. Поддержка сервера баз данных для вертикального расширения не должна требовать включения дополнительных программных модулей, поскольку это увеличивает административные издержки и понижает предсказуемость. Независимо от того, какое расширение используется, вертикальное или горизонтальное, его эффективность зависит от того, как хорошо использует программное обеспечение сервера доступные ресурсы.

Многопроцессорность.

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

Масштабируемость означает, что архитектура сервера баз данных не специализирована некоторым заданным числом процессоров; с одинаковым успехом она должна позволять поддерживать один процессор или полдесятка процессоров, не требуя при этом повторной установки, выключения при изменении конфигурационных параметров или дополнительных программных опций. Такая архитектура будет одинаково полезна и эффективна для случая одного процессора, нескольких процессоров (SMP) или даже многих процессоров (MPP). Пользователю нет необходимости специально заботиться о программной обеспечении, ориентированном на конкретную платформу.

Прозрачность требует, чтобы архитектура баз данных позволяла скрывать изменения в платформе архитектуры от приложений. В частности, однопроцессорная или SMP-системы для взаимодействия могут использовать общую память, тогда как слабосвязанные системы – пересылку сообщений. Приложения не должны меняться с изменением платформы или механизма взаимодействия; преобразования данных и пользовательский интерфейс баз данных должны оставаться без изменений.

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

Расширяемость архитектуры.

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