Новости

Многокритериальный выбор оптимальной системы управления базы данных с помощью метода анализа иерархий

Работа добавлена:






Многокритериальный выбор оптимальной системы управления базы данных с помощью метода анализа иерархий на http://mirrorref.ru

Многокритериальный выбор оптимальной системы управления базы данных с помощью метода анализа иерархий

А. Н. Земцов, Н. В. Болгов, С. Н. Божко

Одной из главных проблем разработки приложения баз данных является выбор системы управления базами данных (далее СУБД). Выбранная СУБД должна удовлетворять не только текущим, но и будущим потребностям предприятия.

В статье представлены основные критерии по выбору СУБД, также применяется метод анализа иерархий для принятия решения.

Основные критерии по выбору СУБД:

1. Модель данных. К данной группе можно отнести: используемую модель данных, предусмотренные типы данных.

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

3. Производительность. Это один из главных критериев выбора СУБД. К данной группе можно отнести: рейтингTransactionProcessingPerformanceCouncil (далееTPC), возможность распараллелить архитектуру, оптимизация запросов.

4. Требования к рабочей среде. К данной группе можно отнести: минимальные требования к оборудованию, поддерживаемые платформы.

5. Особенности разработки приложений. Стоит рассмотреть возможность  использования средыInternet, многоязыковую поддержку и средства проектирования.

6. Надежность. Еще один из главных критериев выбора СУБД. Надежность имеет множество определений, к которым можно отнести сохранность информации при сбоях системы, обеспечение защиты данных от несанкционированного доступа [1].

Сравнительный анализ на основе вышеперечисленных критериев поможет рационально выбрать систему управления базами данных для проекта. Для сравнительного анализа СУБД будет применяться метод анализа иерархий предложенного Т. Саати. В основе этого метода лежит парное сравнение всех СУБД по каждому из вышеперечисленных критериев, на выходе мы получим несколько матриц парных сравнений альтернатив [2]. Подробно с алгоритмом метода анализа иерархий, который используется в задачах многокритериальной оптимизации можно ознакомиться в [3].

В качестве альтернатив будут рассмотрены следующие СУБД:DB2,

Firebird, MySQL, Microsoft SQL Server (далее MS SQL), Oracle, PostgreSQL.Три из них бесплатные –Firebird,MySQL,PostgreSQL; остальные платные.

Все выбранные системы управления базами данных подходят для проведения анализа и сравнения т.к. реализуют реляционную модель данных. По результатам анализа строится матрица парных сравнений альтернатив (МПСА). Для полученной таблицы высчитываются следующие показатели:

1. Вектор приоритетов матрицы (W), определяется суммированием элементов каждой строки и делением каждой суммы на сумму всех элементов матрицы;

2. Главное собственное значение (ƛmax), определяется суммой произведения суммы каждого столбца на вектор приоритетов;

3. Индекс согласованности (ИС), показывает отклонение от согласованности и определяется по формуле (1).

, (1)

гдеn – размерность матрицы (n=6 в нашем случае);

4. Отношение согласованности (ОС), вычисляется делением Индекса согласованности на случайный индекс (СИ), где СИ – табличная величина для матрицы данного порядка и в нашем случае равна 1,24. Значение ОС приемлемо, в случае если меньше или равно 0,10 [2].

Таблица № 1

Матрица парных сравнений альтернатив по критерию «Модель данных»

DB2

Firebird

MySQL

MSSQL

Oracle

PostgreSQL

DB2

1

1

1

1

1

1

Firebird

1

1

2

1/3

4

3

MySQL

1

1/2

1

1/2

4

2

MS SQL

1

3

2

1

5

2

Oracle

1

1/4

1/4

1/4

1

1/3

PostgreSQL

1

1/3

1/2

1/2

3

1

–  Вектор приоритетов (W):  0.12  0.22  0.18  0.28  0.06  0.12;

–  Главное собственное значение (ƛmax): 6,61;

–  Индекс согласованности (ИС): 0,12;

–  Случайный индекс (СИ): 1.24;

–  Отношение согласованности (ОС): 0,09;

–  Отношение согласованности (ОС) в переделах нормы.

Сравним СУБД по критерию «Особенности архитектуры и функциональные возможности».

В таблице 2 рассмотрен максимально возможный объем хранимых данных для каждой из рассматриваемых СУБД [4].

Таблица № 2

Максимально возможный объем хранимых данных для каждой СУБД

Размер БД

Размер таблицы

Размер строки

DB2

512 ТБ

512 ТБ

32677B

Firebird

131 ТБ

2,5 ТБ

64KB

MySQL

256 ТБ

64KB

MS SQL

524258 ТБ

524258 ТБ

Oracle

4 ГБ * размер блока

8 KB

PostgreSQL

32 ТБ

1.6ТБ

По критерию триггеры и хранимые процедуры все альтернативы идентичны. Все поддерживают триггеры, процедуры и функции.

Триггер – программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура – программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД [1, 5].

Построим матрицу парных сравнений альтернатив по критерию «Особенности архитектуры и функциональные возможности» (таблица 3).

Таблица № 3

Матрица парных сравнений альтернатив по критерию «Особенности архитектуры и функциональные возможности»

DB2

Firebird

MySQL

MS SQL

Oracle

PostgreSQL

DB2

1

1

2

1/8

1/3

1/6

Firebird

1

1

2

1/3

1

1/2

MySQL

1/2

1/2

1

1/4

1

1/2

MS SQL

8

3

4

1

5

3

Oracle

3

1

1

1/5

1

1/2

PostgreSQL

6

2

2

1/3

2

1

–  Вектор приоритетов (W):  0,07  0,10  0,06  0,41  0,11  0,22;

–  Главное собственное значение (ƛmax): 6,58;

–  Индекс согласованности (ИС): 0,11;

–  Случайный индекс (СИ): 1.24;

–  Отношение согласованности (ОС): 0,09;

–  Отношение согласованности (ОС) в переделах нормы.

Сравним СУБД по критерию «Производительность».

На сегодняшний день применяется и существует множество различных способов и тестовых рейтингов для проверки производительности систем управления  базами данных. Наиболее авторитетным являетсяTPC-анализ, проводимый компаниейTransaction Processing Performance Council (TPC). Связано это с наличием универсальных эталонных тестов по обработке транзакций. Кроме оценки производительности в рамках TPC тестов, приводится отношение количества запросов, обрабатываемых за промежуток времени к стоимости всей системы. Однако некоторые выбранные альтернативы не проходили TPC тест, к ним относятся Firebird, MySQL и PostgreSQL [6, 7].

Нас интересует осуществление неравновероятного доступа к таблицам, а таким свойством обладает только TPC-C тест производительности, поэтому именно его результаты приведены в таблице 4. Производительность измеряется в tpmC – число транзакций в минуту. Стоимость – стоимость одной транзакции в соотношении цена/производительность.

Таблица № 4

Результаты TPC-C теста производительности

Производительность, tpmC

Стоимость,

USD

IBM DB2 9.5

1 200 011

0.69

Microsoft SQL Server 2005 Enterprise Edition  x64

661 475

1.16

Oracle Database 11 g Standard

631 766

1.08

Построим матрицу парных сравнений по критерию «Производительность» (таблица 5).

Таблица № 5

Матрица парных сравнений альтернатив по критерию «Производительность»

DB2

Firebird

MySQL

MS SQL

Oracle

PostgreSQL

DB2

1

4

5

3

4

5

Firebird

1/4

1

2

1/3

1/3

2

MySQL

1/5

1/2

1

1/3

1/2

1

MS SQL

1/3

3

3

1

2

3

Oracle

1/4

3

2