Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE 131
VII ВЫБОР СУБД
Проблемы выбора СУБД
-Описание предметной области
-Определение модели выбора системы
-Назначение руководителя проекта по созданию БД
-Формулировка цели создания БД
-Определение задач создания БД
-Проведение экспресс-анализа деятельности компании
-Определение бюджета проекта
-Разработка технологической схемы обработки данных
-Создание спецификации для каждого этапа обработки данных, определение места СУБД и необходимых структур для хранения данных
-Определение критериев выбора СУБД
Особенности архитектуры и функциональных возможностей СУБД
Анализ рынка
Выбор поставщика СУБД
Сравнение СУБД Access, MySQL, Oracle
Расчет совокупной стоимости владения СУБД
Миграция приложений и баз данных
Ошибки выбора СУБД
Проблемы выбора СУБД
Стоимость проекта по созданию БД может составить от десятка до многих сотен тысяч и даже млн. долларов. Оптимизацию этих расходов можно произвести через правильный выбор СУБД.
Выбор СУБД представляет собой сложную многопараметрическую задачу и является одним из важных этапов при создании БД. Неправильный выбор СУБД может привести к колоссальным затратам на загрузку данных и последующее их использование. А если учесть, что недостатки принятых решений проявятся через несколько лет, становится очевидной сложность положения, в котором находятся проектировщики баз и банков данных. Стоимость создания крупных БД во много раз превышает стоимость компьютеров и программного обеспечения, поэтому необходимо уделить особое внимание методологии и технологии проектирования БД.
Каждое предприятие имеет свою структуру, свой опыт в области эксплуатации ИТ–технологий. Современную информационную систему среднего предприятия [9] можно рассматривать как набор продуктов одного или нескольких производителей, удовлетворяющие требованиям компании, совместимых и легко интегрируемых между собой.
Заказчики приобретают СУБД, чтобы либо самостоятельно создать поверх нее приложения (с помощью собственных или приглашенных специалистов), либо использовать готовые решения.
Правильный выбор стратегии создания программного обеспечения может существенно уменьшить суммарные затраты на создание БД и сократить сроки ввода БД в эксплуатацию. Благодаря наличию большого числа имеющихся СУБД и приложений к ним, разработчики могут начинать создание БД с достаточно высокого стартового уровня. Предварительно необходимо произвести анализ, оценку и выбор СУБД. Разработчики СУБД и приложений к ним ставят свои цели, отличающиеся от целей создателей БД. Например, критериями разработки СУБД является унификация, масштабирование программного обеспечения, независимость его от используемых платформ, а критериями создателей БД – как можно проще и быстрее запустить БД в работу. Огромный объем данных, участие больших коллективов разработчиков из различных организаций требуют применения промышленных стандартов проектирования БД.
Крупная БД не продается, так не является коробочной версией. Она, как правило, создается на основе коробочных продуктов СУБД [2,3] и прикладных разработок. Системные интеграторы предлагают целый комплекс коробочных продуктов, в т.ч. СУБД, на основе которых создается БД. А далее идет большая кропотливая работа по освоению и разработке приложений.
Именно БД лежит в основе любой корпоративной системы — бухгалтерской, финансовой, управленческой, архивной. БД — это основа любого программного проекта, независимо от размеров предприятия и масштаба проекта, поскольку хранение информации и обеспечение доступа к ней — первоочередная задача любой БД.
Вопрос выбора СУБД встает в тот момент, когда компания либо решилась на создание БД, либо переживает этап модернизации. При создании первой БД легче – не надо организовывать миграцию данных из старой системы, нет еще унаследованных приложений, которые необходимо переносить в новую систему. Отсутствие опыта эксплуатации не дает возможность сравнить функциональность, оценить сложность и эффективность владения. Проблемы, которые могут появиться при внедрении и эксплуатации, пока еще не видны. Компания, имеющая серьезный опыт эксплуатации различных систем, да еще на различных платформах, имеет колоссальное преимущество, но при этом сталкивается с весьма серьезными затратами по переносу данных и параллельному сопровождению новых и унаследованных приложений.
Описание предметной области - чем шире эта область, тем сложнее выбор СУБД, тем больше проблем, связанных с несовместимостью или сложностью интеграции уже имеющихся продуктов и вновь приобретаемого программного обеспечения.
Определение модели выбора системы. Существует два основных подхода: система выбирается исходя из выделенного бюджета, либо бюджет выделяется исходя из стоимости проекта, выбранной на основании проведенного конкурса на разработку БД. Приступая к работе по руководству выбором и внедрением системы, необходимо четко представлять модель выбора, с тем, чтобы минимизировать потери времени в дальнейшем.
Назначение руководителя проекта по созданию БД. Иногда проект идет слишком медленно, поскольку руководитель проекта со стороны заказчика отсутствует, или наделен недостаточными полномочиями, или функции руководителя проекта взял на себя один из топ-менеджеров. Во всех этих случаях с большой вероятностью можно утверждать, что проект не будет идти настолько оперативно и успешно, насколько хотелось бы. Требованиями к руководителю проекта являются:
Если руководитель проекта не обладает необходимыми знаниями относительно происходящего в компании, это может привести к самым серьезным последствиям.
Формулировка цели создания БД. Необходимо понять, какие бизнес-процессы являются критически важными для компании и при создании БД сфокусироваться на них. При этом автоматизировать соответствующие бизнес-процессы надо полностью.
Необходимо ответить на следующие вопросы. Как БД поможет достичь стратегической цели компании? Каковы эти цели и соответственно, какие основные требования должны быть выдвинуты к БД? Необходимо получить список тех стратегических целей и ключевых процессов, которые должна улучшить БД. Необходимо детализировать решаемые проблемы, так чтобы предъявлять к будущей БД вполне определенные требования. Какие люди будут вовлечены в процесс внедрения и использования БД?
Возможными целями создания БД могут быть – увеличение прибыли, повышение эффективности работы предприятия, сокращение затрат на обслуживание, времени обслуживания.
Определение конкретных задач, которые будут решаться с помощью БД. Задачами могут быть:
Проведение экспресс-анализа деятельности компании. Экспресс-анализ позволяет получить ответ о приблизительных сроках и стоимости выполнения проекта. Как правило, функциональность информационной системы несколько шире, чем реальные бизнес процессы компании. На данном этапе необходимо определить как присутствие тех или иных функций скажется на конечной стоимости системы, времени создания, и что самое важно, соответствует ли предлагаемая функциональность целям компании.
Определение бюджета проекта. Мировая практика показывает, что компании тратят на ИТ около 5% своего оборота. Оптимизация схемы покупки и лицензирования СУБД позволит избежать излишних затрат.
Как правило, производители СУБД используют определенные модели формирования стоимости. Например, стоимость одного и того же продукта может существенно изменяться в зависимости от того, сколько пользователей будет с ним работать. В зависимости от того, сколько процессоров имеет сервер, на котором будет установлена СУБД, зависит стоимость лицензии.
На практике решение об использовании той или иной СУБД часто принимает руководитель предприятия, а он может рассматривать не технические критерии. Здесь свою роль могут сыграть такие факторы как рекламная раскрутка компании-производителя СУБД, опыт использования выбранной СУБД на других предприятиях, стоимость. В зависимости от финансового состояния и политики предприятия может быть принцип – чем дороже, тем лучше или использование только бесплатных продуктов.
Очень важно иметь сравнительные показатели работы СУБД. Сравнение должно проходить в равных условиях, т.е. при равных количествах дисков с программным обеспечением, на одинаковой конфигурации аппаратных средств и программ, ориентированных на один и тот же сегмент рынка. Конечно, это достаточно сложный и дорогостоящий вариант выполнения пилотного проекта по созданию тестовой БД на основе нескольких СУБД и последующий выбор наиболее подходящего варианта. Но и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора. Перечень требований к СУБД, используемых при анализе той или иной информационной системы, может изменяться в зависимости от поставленных целей.
Разработка технологической схемы обработки данных. После того как определена максимально возможная область охвата СУБД необходимо разработать технологическую схему обработки данных. На различных предприятиях схемы обработки могут сильно различаться. В компании должна быть четкая картина процессов обработки данных, начиная со сбора данных и заканчивая их визуализацией. Если нет такого представления, то вероятность ошибки при выборе СУБД предельно высока. Как не редкость и тот факт, что как раз выбор и начало эксплуатации СУБД зачастую выявляют массу проблем в управлении, слабое взаимодействие различных подразделений и отсутствие четких схем обработки данных.
Создание спецификации для каждого этапа обработки данных, определение места СУБД и необходимых структур для хранения данных. На этом шаге проводится определение места СУБД на каждом этапе обработки данных и необходимых структур для хранения данных. В спецификации уместно указать форматы и стандарты возможной передачи данных, определить правила взаимодействия подсистем. Таким образом, каждый этап должен иметь свой детально описанный интерфейс (функции, форматы обрабатываемых данных, форматы передачи входных - выходных данных) и предназначенный для интеграции с другими частями системы.
Определение критериев выбора СУБД. Выбору СУБД предшествуют работы по анализу их функциональных возможностей, определению критериев оценки и сравнения их на основе изучения литературы и тестовой загрузки СУБД. Критериями выбора СУБД могут быть стоимость программных средств; объем памяти на диске; требуемый объем оперативной памяти; быстродействие; простота использования структуры данных; удобный доступ к БД через Интернет.
Требования к функциональности и производительности программного обеспечения могут меняться довольно быстро, поэтому требования, предъявляемые к СУБД, должны иметь некий резерв по производительности аппаратно - программных средств. Полезно разработать два документа; один с функциональными и технологическими требованиями к системе, а другой — с требованиями к ее поставщику. Очень важно сравнивать СУБД одного класса.
Очень важными функциональными возможностями СУБД являются поддержка языка XML, доступ к данным с мобильных устройств, наличие версии с открытым кодом, интеграция с офисными пакетами, наличие программ визуализации данных, управление неструктурированными данными, унифицированный интерфейс.
У современных СУБД необходимо рассматривать:
Критические факторы для производительности БД представлены в табл.1.
Таблица 1 - Критические факторы для производительности БД
|
Клиент |
Сеть |
Сервер |
|
Время ответа |
Коммуникационный протокол |
Модель данных |
|
Количество пользователей |
Сетевой драйвер |
Пользовательские приложения |
|
Запросы |
Маршрутизатор |
Схема БД |
|
Сложность интерфейсов |
Физическая среда |
Модель вычислительной системы (ОС, оперативная память, процессор, язык программирования) |
|
Надежность работы инфраструктуры |
Наличие дублирующего провайдера |
Резервирование серверов, копирование данных |
После того как определены функции БД необходимо определиться с линейкой программных средств. Требованиями к линейке инструментов относятся стоимость, пользовательский интерфейс, возможности доработки, расширения функциональности, платформа, сопровождение и т.д.
Поскольку СУБД работает не сама по себе, а поверх определенной ОС, ее стоимость играет важную роль для заказчика. Поэтому крупные компании предпочитают СУБД для Unix, а средние и малые — для Windows и Linux. Чтобы удовлетворить все запросы, разработчики создают кроссплатформенные СУБД. В последние годы растет спрос на СУБД для Linux. По объему продаж у СУБД Oracle лидируют Unix-системы. Поэтому выбор СУБД часто определяется установленной на предприятии ОС.
Следует учитывать базовые типы данных, заложенные в систему, и наличие возможности расширения типов. Отклонения базовых типов данных у современных систем невелики, а вот механизмы расширения типов данных у них различаются.
Все современные СУБД совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют не все расширения этого стандарта. Например, СУБД MySQL не поддерживает вложенные запросы на выборку данных.
Особенности архитектуры и функциональных возможностей СУБД
К главным характеристикам СУБД относятся мобильность, совместимость программного обеспечения, масштабируемость технических и программных средств, распределенность, сетевые возможности.
Мобильность – это независимость системы от среды, в которой она работает.
Совместимость программного обеспечения обеспечивается вычислительной средой, которая позволяет гибко менять количество и состав аппаратных средств и программного обеспечения в соответствии с меняющимися требованиями решаемых задач. Она должна обеспечивать возможность запуска одних и тех же программных систем на различных аппаратных платформах. Эта среда должна гарантировать возможность применения одних и тех же человеко-машинных интерфейсов на всех компьютерах, входящих в неоднородную сеть. В последнее десятилетие сформировалась концепция открытых систем, представляющая собой совокупность стандартов на различные компоненты вычислительной среды, предназначенных для обеспечения мобильности программных средств в рамках неоднородной, распределенной вычислительной системы.
Масштабируемость технических средств представляет собой возможность наращивания числа и мощности процессоров, объемов оперативной и внешней памяти и других ресурсов вычислительной системы. Масштабируемость обеспечиваться архитектурой и конструкцией компьютера, а также соответствующими средствами программного обеспечения. В идеале добавление процессоров к системе должно приводить к линейному росту ее производительности. Однако это не всегда так. Потери производительности могут возникать, например, при недостаточной пропускной способности шин из-за возрастания трафика между процессорами и основной памятью, а также между памятью и устройствами ввода/вывода. Простой переход, например, на более мощный процессор может привести к перегрузке других компонентов СУБД.
Масштабируемость программных средств - это способность одновременно обслуживать большее количество пользовательских запросов с той же скоростью при пропорциональном этому количеству увеличении объема предоставляемых ресурсов (процессоров, оперативной памяти и т.д.). При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать развитию БД (увеличение числа пользователей, объема хранимых данных и объеме обрабатываемой информации). СУБД с плохой масштабируемостью, успешно применявшаяся при небольшом объеме данных, оказывается непригодной при его росте и нередко СУБД приходится заменять на другую. При этом неизбежны определенные затраты на переписывание кода программы.
Распределенность - различные системы имеют разные возможности распределенности. Для обеспечения параллельной обработки данных используется распараллеливание обработки последовательности запросов на несколько процессоров или использование нескольких компьютеров-клиентов, работающих с одной БД, которые объединяются в так называемый параллельный сервер.
Сетевые возможности. СУБД позволяют использовать широкий диапазон сетевых протоколов и служб для работы и администрирования БД. Большим достоинством современных СУБД является их удаленное администрирование. Отслеживание состояния БД включает контроль использования памяти, автонастройку, управляемость, отказоустойчивость.
Контроль использования памяти компьютера. СУБД должна иметь возможность управления оперативной памятью и дисковым пространством (сжатие БД, удаление избыточных файлов, др.).
Автонастройка. Современные СУБД включают в себя возможности самоконфигурирования, самодиагностики производительности. Эти возможности позволяют выявить слабые места конфигурации СУБД и автоматически настроить ее на максимальную производительность.
Управляемость - простота администрирования и конфигурирования, наличие средств автоматического конфигурирования (набор средств администрирования включает средства создания объектов БД - таблиц, связей, атрибутов, инструменты репликации данных, утилиты управления пользователями и группами, средства мониторинга событий, средства просмотра планов выполнения запросов, утилиты миграции данных из других СУБД);
Отказоустойчивость - это свойство СУБД, которое обеспечивает ей возможность продолжения действий, заданных программой, после возникновения неисправностей. Обеспечение отказоустойчивости требует избыточного аппаратного и программного обеспечения создания БД на параллельных вычислительных системах. Структура многопроцессорных и многомашинных систем приспособлена к автоматической реконфигурации и обеспечивает возможность продолжения работы системы после возникновения неисправностей.
Реляционные БД допускают эффективную компрессию данных, поскольку в каждой колонке хранится лишь однотипная информация в отличие от многомерных БД, в которых, как правило, содержится несколько типов данных. Индексирование и выделение разделов в отдельных случаях увеличивают объем данных вдвое, а то и больше.
Многие производители СУБД выпускают средства разработки приложений для своих систем. Эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при выборе СУБД необходимо анализировать возможности средств разработки приложений. Особенностями разработки приложений являются:
средства автоматизированного проектирования БД и прикладных программ, например, в СУБД Oracle есть инструмент Oracle Designer - средство проектирования программных систем, реализующее технологии CASE;
возможности разработки Web-приложений;
поддерживаемые языки программирования - широкий спектр используемых языков программирования повышает доступность системы для разработчиков, а также может существенно повлиять на быстродействие и функциональность создаваемых приложений (большинство современных СУБД поддерживают языки программирования Си, Дельфи, Java и др.).
Важнейшей характеристикой вычислительных систем является надежность. Главной целью повышения надежности СУБД является сохранность хранимых данных. Повышение надежности основано на принципе предотвращения неисправностей путем снижения интенсивности отказов и сбоев за счет применения электронных схем и компонентов с высокой и сверхвысокой степенью интеграции, снижения уровня помех, облегченных режимов работы схем, обеспечение тепловых режимов их работы, а также за счет совершенствования методов сборки аппаратуры. Понятие надежности системы имеет много смыслов – это восстановление информации после сбоев, и безотказность работы системы в любых условиях, и обеспечение защиты данных от несанкционированного доступа. Для повышения надежности СУБД должна иметь следующие функции.
Восстановление после сбоев. При возникновении программных или аппаратных сбоев целостность и работоспособность всей системы может быть нарушена. От наличия механизмов восстановления после сбоев зависит жизнеспособность системы.
Резервное копирование. В результате аппаратного сбоя может быть частично поврежден или выведен из строя носитель информации и тогда восстановление данных невозможно, если не было предусмотрено резервное копирование БД или ее части. Резервное копирование спасает и в ситуациях, когда происходит логический сбой системы, например при ошибочном удалении таблиц. Существует множество механизмов резервирования данных (хранение одной или более копий всей БД, хранение копии ее части, копирование логической структуры и т.д.).
Откат изменений. При выполнении транзакции применяется простое правило – либо транзакция выполняется полностью, либо не выполняется вообще.
Для предотвращения несанкционированного доступа к данным используется служба идентификации пользователей. Уровень защиты может быть различным. Кроме непосредственной идентификации пользователей при входе в систему может использоваться также механизм шифрования данных при передаче по линиям связи
На серверах БД наблюдается большое разнообразие выполняемых приложений. Далеко не все приложения интенсивно используют процессорные ресурсы, и не все из них связаны с интенсивным вводом/выводом. Поэтому смесь таких приложений на одной системе может обеспечить достаточно равномерную загрузку всех ресурсов. Естественно неправильно подобранная смесь может дать совсем противоположенный эффект. Реальное использование систем показывает, что имеет место тенденция заполнения всех доступных ресурсов. Как следствие, системы, даже имеющие некоторые избыточные ресурсы, со временем не будут воспринимать дополнительную нагрузку.
Анализ рынка
После проведения всех вышеуказанных работ можно приступать к анализу рынка программного обеспечения. Благодаря сформированным требованиям к СУБД, в процессе выбора отсеиваются продукты, не удовлетворяющие критериям выбора (ОС, сервер БД, стоимость, преемственность, сложность в обучении и наличие специалистов для сопровождения и дальнейшей разработки).
Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала.
СУБД - это инфраструктурное программное обеспечение, а не готовое решение. Клиентам нужны приложения, обеспечивающие автоматизацию их деятельности, а СУБД интересуют их только с точки зрения возможности создания прикладного программного обеспечения. СУБД относятся к классу корпоративного программного обеспечения. Сама по себе БД, без прикладной системы, заказчику не нужна. Эти обстоятельства и определяют особенности продвижения продукта.
Выбор поставщика СУБД
Оценивая поставщика СУБД, необходимо учесть следующие факторы:
Полнота и завершенность продукта определяются стратегией продукта для удовлетворения рыночных требований; пониманием рыночных тенденций и умением влиять на них.
Оценивая СУБД по поставщику, необходимо учесть следующие факторы [4]:
Выбор поставщиков зависит от рекламы, размеров компании, присутствия на международном рынке, качества сайта фирмы, аналитических рейтингов, репутации, удобства сотрудничества, стоимости, законченности системы, используемых технологий, функциональности продукта. Не делайте цену решающим фактором выбора поставщика. Познакомьтесь с методологией внедрения. От того, насколько подробно в ней прописан каждый шаг проекта, управление проектными рисками, ожиданиями клиента, насколько логичны этапы выполнения проекта, зависит очень многое. Составьте тщательно продуманный договор.
Для продажи СУБД требуются дополнительные услуги по внедрению, настройке, поддержке и сопровождению, которыми в основном занимаются системные интеграторы. Поэтому, кроме анализа поставщиков СУБД необходимо дать оценку работы системного интегратора.
Основными критериями оценки системных интеграторов являются известность компании, количество успешных внедрений, опыт внедрения в сходных областях. Она занимается не только настройкой и установкой СУБД, но и разработкой БД. Важно работать с компанией, придерживаясь принципа поэтапной оплаты исследований, внедрения и лицензии на систему. Важно иметь возможность без значительных потерь отказаться от услуг данной компании.
При этом документируйте все вопросы, связанные с постановкой задач, описанием бизнес процессов, постановкой сроков и контрольными точками. Необходимо определить систему взаимодействия с системным интегратором. Все основные результаты уже проделанной работы, должны использоваться в будущем, чтобы при возникновении каких-либо спорных ситуаций можно было бы ссылаться на подписанную ранее документацию.
Важную роль в продвижении СУБД играет предоставляемый системными интеграторами сервис для заказчиков. Чем сложнее СУБД и чем он важнее она бизнеса клиента, тем большее значение приобретают обслуживание и техническая поддержка.
Для пользователя, приобретающего дистрибутив программного обеспечения СУБД в виде коробки или пакета, это программное обеспечение является товаром со своими потребительскими характеристиками. Разумно выделить такие характеристики, как цена дистрибутива, время и сложность (или простота) установки, возможности по поддержке оборудования пользовательского компьютера [8]. В затраты на создание БД должны входить, кроме стоимости самой СУБД и приложений, стоимость изучения, привязки и обучения персонала. Главным критерием оценки здесь должна быть совокупная стоимость владения СУБД (расчет рассмотрен далее более подробно).
Сами по себе БД не являются готовыми тиражными решениями. Все современные СУБД имеют дополнительные программные средства. Их наличие и стоимость также являются критерием выбора СУБД. Например, у фирмы Oracle имеется множество дополнительного программного обеспечения, но, к сожалению, его стоимость тоже высока. И только очень крупные компании могут себе позволить купить вместе с СУБД еще и дополнительные программные средства (например, Server Application Oracle – сервер приложений для создания web-порталов).
Применяя те или иные языки программирования, среды и инструменты разработки, готовые компоненты третьих фирм и модули, поставляемые производителем сервера БД, можно существенно увеличить функциональность создаваемых БД [7]. Но при этом могут появляться драйверы ODBC и OLEDB «третьих» производителей, которые хотя и позволяют работать с БД, но не гарантируют отсутствия проблем при обработке специфических запросов.
Представленным выше критериям, удовлетворяет много СУБД, характеристики наиболее известных СУБД даны в табл.2. В идеальном случае СУБД должна обеспечивать реализацию всех возлагаемых на БД задач и укладываться в ограничения, накладываемые техническими средствами. Для окончательного выбора СУБД необходимо проанализировать свойства СУБД, ОС, в которой может работать СУБД, возможные структуры данных, типы запросов, возможность создания метаданных, интеграции данных, средств экспорта-импорта, возможность использования ранее созданных приложений. Можно предложить следующие оценки СУБД, например:
Таблица 2 – Характеристики корпоративных СУБД
|
Компании |
СУБД |
Краткая характеристика |
|
Зарубежные продукты |
||
|
Borland |
InterBase |
SQL-совместимая реляционная, ОС - Windows, Linux и Solaris. |
|
Computer Associates |
Jasmine, Ingres II |
Объектно-ориентированная СУБД, совместима с технологиями XML и Java. Распределенная реляционная СУБД и объектно-ориентированная среда разработки приложений в архитектуре клиент/сервер. ОС - Unix, Linux, мейнфреймах, VMS, OS/2, Windows, NetWare. |
|
IBM |
DB2 Universal Database, Informix |
Мультимедийная, Web, ОС - Unix, Linux и Windows, аппаратные платформы - zSeries, iSeries, VSE и VM. СУБД для систем масштаба предприятия и рабочей группы, обеспечивает работу с очень крупными БД в условиях дефицита ресурсов. Используемые языки - Java, SQL 2000 |
|
InterSystems |
Cache’ |
Постреляционная СУБД, включающая сервер многомерных данных и средство обработки запросов на языке SQL. ОС - Unix, Mac OS, Linux, Windows (32- и 64-разрядные версии). |
|
Microsoft |
SQL Server |
Реляционная СУБД для управления данными в масштабе предприятия, поддерживает технологии XML и Интернет, обладает встроенным средством анализа и извлечения данных, интегрированным с MS Office, ОС - Windows. Используемый язык Transact-SQL, XML |
|
Oracle |
Oracle |
СУБД для масштабной обработки транзакций (OLTP), хранилищ данных с высокой интенсивностью потока запросов и ресурсоемких Интернет-приложений. ОС - Unix, Windows и Linux. Последняя версия поддерживает Grid-вычисления. Используемые языки Java, Delphi PL/SQL, XML |
|
Software AG |
Adabas |
Постреляционная, поддерживает различные модели данных, работает на мейнфреймах, ОС - Unix, Linux, OpenVMS и Windows |
|
Sybase |
Sybase Adaptive Server Enterprise |
СУБД масштаба предприятия для централизованной обработки критически важной информации, работает на платформах Unix и Linux. Компактная, полноценная реляционная СУБД для рабочих групп, мобильных и встроенных вычислений. Используемые языки Java, Transact-SQL |
|
Teradata |
Teradata Database |
Предназначена для создания хранилищ данных, ОС - Windows 2000 Server, Windows 2000 Advanced Server, Windows .NET Server и ряда версий UNIX |
|
Microsoft |
dBASE III Plus |
ОС Windows. Создаваемые ею файлы импортируются СУБД FoxPro, Paradox, MS Access, а также пакетами прикладных программ MS Excel, Surfer, Grapher и др. |
|
Отечественные продукты |
||
|
Рэлэкс |
Линтер |
Реляционная СУБД, имеющая сертификат Гостехкомиссии при Президенте РФ на соответствие 2 классу защиты информации от несанкционированного доступа, ОС - Unix, Linux, QNX, VAX/VMS, OpenVMS, DOS, Windows, NetWare, OS/2 |
|
ВНИИНС |
Паллада |
Объектно-ориентированная СУБД, предназначенная для АСУ вооруженных сил, функционирует в среде ОС МСВС и ОЛИВИЯ |
|
СУБД с открытым исходным кодом |
||
|
MySQL AB |
MySQL |
Компактная, быстродействующая реляционная СУБД для малых и средних предприятий, ОС - Linux, Mac OS X, Unix и Windows |
|
Сообщество PostgreSQL |
PostgreSQL |
Реляционная СУБД, имеет многие возможности, которые реализованы в крупных коммерческих продуктах, ОС - Unix, Windows и NetWare |
Сравнение СУБД ACCESS, MySQL, Oracle
Объём памяти на жёстком диске необходимый для самой СУБД: ACCESS (OfficeXP) – 530 Мбайт, Oracle – >1 Гбайт, для работы с MySQL через Интернет необходим только браузер, а для работы локально нужен ещё web-сервер, поддерживающий MySQL и PHP (например, Apache – 8Мбайт). Размер БД в формате соответствующем каждой СУБД: ACCESS – 1,73 Мбайт, MySQL – 113 Кбайт, Oracle – размер определяется не содержанием самой базы, а задаваемым табличным пространством.
Оперативная память, используемая СУБД при работе с той же БД: ACCESS – 4528 Кбайт, сервер Apache + Internet Explorer – 28612 Кбайт (из них Internet Explorer – 11660 Кбайт).
Быстродействие: при работе локально разница между временем выполнения запроса в ACCESS и временем выполнения аналогичного запроса в MySQL практически неощутима (десятые доли секунды); при работе же с MySQL через Internet скорость зависит от таких параметров как трафик сети, удалённость и быстродействие сервера и прочее.
Простота использования: Интерфейс СУБД ACCESS очень нагляден, содержит хорошую систему помощи и опции «мастеров» создания и заполнения, это всё в совокупности позволяет даже неопытному пользователю, не имеющему навыков работы с какими-либо СУБД, довольно таки быстро научиться создавать и управлять БД. В СУБД MySQL – не смотря на то, что приходится прописывать всё в ручную, особых трудностей тоже нет, особенно, если пользователь обладает хотя бы какими-то навыками программирования и работы с БД. СУБД Oracle требует ее изучения в течение большего, по сравнению с ACCESS и MySQL, времени.
Таблица 3 - Практические характеристики БД MS SQL и Oracle []
|
Характеристики |
Microsoft SQL Server |
Oracle |
|
Удобство и простота настройки |
Интуитивно понятный интерфейс |
Медленный графический интерфейс, требуется много оперативной памяти из-за работы Сборщика мусора |
|
ОС |
Windows |
Windows или UNIX |
|
Мин требования для аппаратного обеспечения (при загрузке) |
HDD – 80 Мбайт, RAM – 15 Мбайт |
HDD - 1.3 Гбайт, RAM – 150 Мбайт |
|
Скорость развёртывания |
Установка занимает не больше 10 мин |
Установка занимает не меньше 30 мин |
|
Скорость загрузки |
Максимум 10 с |
Минимум 3 мин |
|
Производительность |
Хорошо |
Хорошо |
|
Конкурентный доступ |
Хорошо |
Отличный |
|
Число пользователей |
Удовлетворительно |
Не ограничено |
|
Большие БД |
Поддерживает средне |
Отлично |
|
Готовность |
Отлично |
Отлично |
|
Административное управление |
Хорошо |
Отлично |
|
Графические инструменты |
Отлично |
Хорошо |
|
Простота обслуживания |
Отлично |
Отлично |
|
Механизм данных |
Хорошо |
Отлично |
|
Работа с несколькими процессорами |
Приемлемо |
Отлично |
|
Функция соединения и выбор индексов |
Отлично |
Отлично |
|
Одновременный доступ нескольких пользователей |
Хорошо |
Отлично |
|
Обработка мультимедиа-данных |
Плохо |
Отлично |
|
Подключение к Интернет |
Хорошо |
Отлично |
|
Обработка аудио, видео, изображений |
Плохо |
Отлично |
|
Поиск по всему тексту |
Хорошо |
Отлично |
|
Функциональная совместимость |
Хорошо |
Хорошо |
|
Сопряжение с другими БД |
Хорошо |
Хорошо |
|
Единая регистрация |
Хорошо |
Хорошо |
Примечание: Тестирование производилось на компьютере с характеристиками CPU - 750 MHz AMD DURON, RAM- 128 Мбайт, ОС - Windows 2000 Professional.
Основным минусом СУБД Oracle, DB2 и Microsoft SQL Server является их высокая стоимость. Кроме того, они являются закрытыми, что не всегда подходит компаниям с высокими требованиями к безопасности. Это ограничивает также возможности интеграции данных.
Сравнение наиболее важных характеристик и возможностей БД MySQL и PostgreSQL приведено в табл. 4. Из таблицы видно, что PostgreSQL предлагает полные особенности и возможности традиционных приложений БД, в то время как MySQL сосредотачивается на более быстром выполнении веб-приложений.
Таблица 4 - Сравнение MySQL и PostgreSQL
|
Особенности |
PostgreSQL |
MySQL |
|
ANSI SQL совместимость |
Близка к стандарту |
Следует не всем стандартам ANSI SQL |
|
Скорость работы |
Медленнее |
Быстрее |
|
Вложенная команда Select |
Да |
Нет |
|
Транзакации |
Да |
Да, должен использоваться тип таблицы InnoDB |
|
Ответ БД |
Да |
Да |
|
Поддержка внешних ключей |
Да |
Нет |
|
Представления |
Да |
Нет |
|
Хранимые процедуры |
Да |
Нет |
|
Триггеры |
Да |
Нет |
|
Unions |
Да |
Нет |
|
Полные Joins |
Да |
Нет |
|
Ограничители целостности |
Да |
Нет |
|
Поддержка Windows |
Да |
Да |
|
Вакуум (очистка) |
Да |
Нет |
|
ODBC |
Да |
Да |
|
JDBC |
Да |
Да |
|
Различные типы таблиц |
Нет |
Да |
СУБД PostgreSQL Plus Advanced Server — это СУБД корпоративного уровня с гарантированной поддержкой производителя. СУБД PostgreSQL в настоящее время лидер среди СУБД с открытым исходным кодом. Также она хорошо совместима с СУБД Oracle, MS SQL, MySQL, Sybase (поддержка процедур, триггеров, пакетов, типов данных, функций и т.д.), что дает возможность достаточно быстро мигрировать на СУБД PostgreSQL.
Несмотря на некоторые преимущества Oracle, при использовании на не очень больших объектах особой разницы между Oracle и MS SQL Server нет. В таком случае начинают играть весомую роль другие критерии выбора:
Расчет совокупной стоимости владения СУБД [6]
Совокупная стоимость владения СУБД включает стоимость:
При выборе СУБД надо помнить о затратах, связанных с ее последующим внедрением и адаптацией. Величина этих затрат определяется сложностью работы с СУБД, открытостью ее исходного текста, а также стоимостью услуг компаний-интеграторов. Она зачастую бывает довольно большой, но в данном случае оценить ее сложно, поскольку она зависит от многих факторов конкретного проекта — решаемых задач, сложности существующих приложений, объема хранимых и обрабатываемых данных и т.д.
Для сравнения совокупной стоимости владения СУБД Oracle, DB2 и MS SQL Server и PostgreSQL будем проводить расчеты затрат для случая разворачивания СУБД на двух серверах, на каждом из которых имеется два CPU архитектуры x86 стоимостью — 100000 рублей. В качестве периода владения выбран один год. Стоимость лицензии и поддержки для выбранных СУБД приведены в табл.5.
Стоимость сопровождения СУБД определяется заработной платой сотрудников, ответственных за обслуживание и администрирование БД. Для оценки этих затрат предположим, что для обслуживания двух серверов достаточно одного квалифицированного администратора баз данных. Оценка годового фонда оплаты труда (ФОТ), исходя из среднемесячной зарплаты сотрудников, представлена в табл.6.
Таблица 5 - Стоимость СУБД (в рублях)
|
Наименование СУБД |
Лицензия |
Поддержка |
Итого |
|
PostgreSQL |
0 |
636 492 |
636 492 |
|
MS SQL |
2 902 200 |
856 149 |
3 758 349 |
|
DB2 |
4 368 000 |
1 030 848 |
5 398 848 |
|
Oracle |
7 080 000 |
1 837 968 |
8 917 968 |
Таблица 6 - Стоимость сопровождения СУБД (в рублях)
|
Наименование СУБД |
Среднемесячная зарплата |
Годовой ФОТ |
|
PostgreSQL |
70 000 |
840 000 |
|
MS SQL |
80 000 |
960 000 |
|
DB2 |
90 000 |
1 080 000 |
|
Oracle |
80 000 |
960 000 |
В качестве ОС для СУБД Oracle, PostgreSQL и IBM DB2 выбрана ОС Red Hat Enterprise Linux с уровнем поддержки Standard. Для MS SQL в качестве ОС взята Microsoft Windows Server Enterprise. Исходя из указанных предположений, получим следующие результаты расчета стоимости платформы для СУБД (табл.7).
Таблица 7 - Стоимость платформы для СУБД (в рублях)
|
Наименование СУБД |
Оборудование |
ОС |
Итого |
||
|
Стоимость |
Поддержка |
Стоимость |
Поддержка |
||
|
PostgreSQL |
200 000 |
59 000 |
0 |
63 720 |
322 720 |
|
MS SQL |
200 000 |
59 000 |
128 600 |
37 937 |
425 537 |
|
DB2 |
200 000 |
59 000 |
0 |
63 720 |
322 720 |
|
Oracle |
200 000 |
59 000 |
0 |
63 720 |
322 720 |
Основываясь на результатах предыдущих расчетов, можно оценить совокупную стоимость владения рассматриваемыми СУБД в течение первого года как сумму всех составляющих. Также приведем результаты расчета TCO в течение 3 лет. Результаты представлены в табл.8.
Таблица 8 - Совокупная стоимость владения СУБД (в рублях)
|
Наименование СУБД |
в течение 1 года |
в течение первых 3 лет |
|
PostgreSQL |
1 799 212 |
4 997 636 |
|
MS SQL |
5 143 886 |
8 970 058 |
|
DB2 |
6 801 568 |
11 268 704 |
|
Oracle |
10 200 688 |
16 042 064 |
При расчете для двух серверов с двумя процессорами получаем, что PostgreSQL обходится дешевле Oracle в 3-5 раз, и эта разница будет только увеличиваться при разворачивании более масштабных БД. При внедрении открытого программного обеспечения надо учитывать стоимость владения TCO, а не стоимость лицензий. Поэтому всё упирается в вопрос масштаба. Все затраты и на проект уже сделаны, поэтому каждый новый центр будет давать чистую экономию.
Миграция приложений и баз данных
Миграция приложений и баз данных это сложный, дорогостоящий и, зачастую, рискованный процесс. В первую очередь это связано с тем, что при разработке приложений для СУБД используются различные специфические функции, не входящие в стандартный SQL. Кроме того, ожидаемые выгоды от миграции часто не оправдывают затрат на переподготовку специалистов и работы, связанные с переписыванием приложений и тестированием произведенных изменений [http://www.pcweek.ru/upload/iblock/fd0/bureausolomatina-3.pdf].
Рассмотрим процесс миграции на примере перехода с СУБД Oracle на PostgreSQL. Помимо технической возможности, для успешной миграции БД необходимо четко представлять стратегию миграции (табл.9). Это позволит спланировать основные этапы проекта, отследить промежуточные результаты и, при необходимости, внести требуемые корректировки. Такие меры помогут уменьшить риски процесса миграции и позволят избежать непредвиденных затрат.
Таблица 9 - Стратегия внедрения СУБД Postgres
|
Стратегия |
Преимущества |
|
Разработка-внедрение новых приложений на СУБД PostgreSQL |
Значительное сокращение затрат на некритичные системы Использование имеющихся знаний и опыта работы с Oracle Очень низкий риск неудачи |
|
Использование СУБД PostgreSQL в качестве сервера репликации с Oracle |
Значительное сокращение затрат Использование преимуществ PostgreSQL Использование имеющихся знаний и опыта работы с Oracle Повышение производительности OLTP приложений |
|
Миграция некритичных приложений с СУБД Oracle на PostgreSQL |
Значительное сокращение затрат Использование имеющихся знаний и опыта работы с Oracle Низкий риск неудачи |
|
Миграция критически важных приложений с СУБД Oracle на PostgreSQL |
Наибольшее сокращение затрат Использование имеющихся знаний и опыта работы с Oracle Гибкость развертывания |
СУБД PostgreSQL имеет высокую степень совместимости с СУБД Oracle, что обеспечивает простую и быструю миграцию существующих приложений. Все усовершенствования можно разделить на несколько категорий.
Производители БД сознательно создают специфические расширения SQL для придания отличительных черт своему продукту. PostgreSQL распознает расширения SQL, созданные Oracle, например, decode(), таблица DUAL и ROWNUM.
Процедурный язык СУБД PostgreSQL (PL/pgSQL) совместим с языком PL/SQL от Oracle для триггеров, хранимых процедур, пакетов, функций и других расширений СУБД, например, распознание событий ожидания (Wait Events). В итоге, необходимость переподготовки разработчиков и переписывание приложений сводится к минимуму, экономя время и затраты на миграцию, а также снижая риск неудачи проекта.
Такие инструменты, как SQL*Plus, SQL*Loader, DBA Management Server и DBLinks, также поддерживаются в PostgreSQL. Кроме того, поддерживаются наиболее часто используемые служебные представления Oracle. Поэтому администраторам БД не требуется проходить переподготовку, и они могут полноценно использовать ранее накопленный опыт работы с Oracle.
PostgreSQL поддерживает наиболее распространенные языки программирования, используемые для создания приложений для Oracle. Также PostgreSQL имеет встроенную поддержку Oracle Call Interface (OCI), тем самым гарантируя работу приложений, написанных на C или C++.
Для упрощения и ускорения процесса миграции больших баз данных PostgreSQL предоставляет автоматизированные инструменты для перемещения объектов СУБД Oracle (схемы, таблицы, данные, пакеты, триггеры, хранимые процедуры, функции и т.д.).
Перед началом миграции данных целесообразно оценить параметры будущей БД:
• факторы совместимости БД (влияют на трудоемкость миграции);
• длительность миграции;
• экономические выгоды от проекта.
Изначальные характеристики СУБД Oracle, от которых зависит трудоемкость предстоящей миграции, можно оценить по следующим пяти категориям:
• параметры объектов;
• специфические особенности;
• синтаксис;
• пакеты;
• параметры развертывания.
На основе этих категорий составляется консолидированный индекс совместимости БД, который помогает достаточно быстро оценить возможность миграции конкретного экземпляра БД в Oracle в PostgreSQL. Среди параметров объектов БД наиболее интересны структура и размер таблиц и индексов, используемые ограничения, структура представлений. К тому же необходимо учитывать наличие таких опций Oracle, как сжатие данных или индекс-таблицы.
Трудоемкость миграции сильно зависит от использования в приложении специфических особенностей экземпляра БД Oracle измерения, хранимые шаблоны, Advanced Queuing, пространственные объекты, XML-объекты.
Особенности использования конструкций языка PL/SQL в БД Oracle требуют разделить их на три части: поддерживаются, имеют альтернативу и не поддерживаются в PostgreSQL. Перед миграцией необходимо определить, какие из встроенных пакетов Oracle используются в хранимых процедурах, триггерах и функциях.
Параметры развертывания характеризуют степень использования в развернутом экземпляре Oracle таких функций, как DBLink, репликации, Real Application Cluster (RAC), создание резервных БД, ASM (automated storage management) и AWR (automatic workload repository).
На длительность миграции влияет множество других условий, основные из которых указаны ниже:
• структура и размер БД;
• структура и размер клиентского приложения;
• знания и опыт технических специалистов;
• наличие других текущих проектов;
• организационные ресурсы и бюджет;
• временные рамки;
• имеющаяся серверная и сетевая инфраструктура.
Экономические выгоды от проекта в первую очередь связаны с сокращением затрат на содержание СУБД и зависят от следующих факторов:
• выбранная стратегия миграции;
• конкретные БД и приложения для миграции;
• количество переносимых экземпляров;
• параметры серверной платформы.
После того как проведена оценка параметров проекта на основе факторов совместимости БД, рассчитана длительность проекта и экономические выгоды, принимается решение о проведении миграции базы данных с Oracle на PostgreSQL.
Наиболее типичными ошибками при миграция структур данных являются:
• конфликт зарезервированного слова,
• проблема в различной реализации функций,
• неподдерживаемые на данный момент функции.
Конфликт зарезервированного слова возникает в случае, когда название столбца таблицы совпадает с зарезервированным в PostgreSQL словом. Например, в качестве названий столбцов нельзя использовать слова time и date. Проблема с различной реализацией функций заключается в том, что функции поддерживаются обеими СУБД, но они имеют различный синтаксис. Поэтому при миграции синтаксис либо автоматически будет изменен для соответствия PostgreSQL, либо необходимые модификации придется сделать вручную.
Также существует ряд функций Oracle, которые пока не поддерживаются в PostgreSQL и, соответственно, не могут быть перенесены. Например, Automatic Storage Management (ASM) или Flashback database. Высокая совместимость PostgreSQL с большинством расширений SQL, используемых в Oracle, позволяет встроенным в приложения SQL запросам работать практически без изменений.
Ошибки выбора СУБД
Отсутствие цели создания БД и конкретных задач, которые должны решаться с помощью БД. Предприятие может работать и приносить прибыль, даже если организация бизнес-процессов не идеальна. Оптимизируйте бизнес-процессы предприятия, его организационную структуру, разработайте ключевые показатели деятельности. А потом приступайте к автоматизации.
«Скупой платит дважды». Вовсе не обязательно, что ваш выбор — это самая дорогая система из имеющихся на рынке, но и не самая дешевая. Ставить стоимость во главу угла неправильно: при этом упускаются из виду другие важнейшие факторы. Задайте себе вопрос: что обойдется дешевле?
Требовать невозможного. Многие заказчики имеют неверное представление о функциональности СУБД, например, хотят автоматизировать с помощью нее документооборот или бюджетирование.
Действовать в одиночку. Благие намерения ИТ-директоров могут не совпадать с точкой зрения топ-менеджеров компании. Иногда расхождение во взглядах может носить принципиальный характер. Чрезвычайно важно найти компромисс и сформировать целостное видение задач и целей всеми руководителями компании до начала проекта.
Выводы
Разработчики СУБД позиционируют свои продукты для выполнения оперативных транзакций, создания хранилищ и специализированных применений.
СУБД для выполнения онлайновых транзакций (OLTP) — чаще всего используются в режиме реального времени, в широком спектре деловых приложений (ERP, CRM и пр.) и отвечают высоким требования по производительности, масштабируемости, надежности, безопасности. Как правило, такие продукты представлены в виде нескольких вариантов, предназначенных для промышленной эксплуатации и разработки решений. OLTP-системы поставляются компаниями CA, IBM, Microsoft, Oracle, Software AG и Sybase, а также в рамках открытых проектов, включая Ingres, MySQL и PostgreSQL. PostgreSQL и MySQL это две мощные СУБД с открытым исходным кодом, имеющие большую инсталляционную базу. Тем не менее, MySQL пока остается самой популярной СУБД с открытым кодом.
Хранилища данных ориентированы на задачи по принятию решений с использованием разнообразных средств бизнес-аналитики. Такие продукты имеют хороший набор средств извлечения и преобразования информации. В этом назначении широко применяют традиционные средства тех же фирм IBM, Microsoft, Oracle, Ingres, но очень серьезные позиции тут занимает специализированное программное обеспечение от таких компаний, как Greenplum, Netezza, Sybase и Teradata.
Специализированные СУБД необходимы для решения специфических задач, связанных с использованием, например, мобильных устройств или XML-приложений. Как правило, подобные системы применяются в виде встроенных компонентов, поставляемых конечным пользователям третьими ИТ-компаниями (производителями оборудования, независимыми разработчиками программного обеспечения). Подобные СУБД выпускают как крупные софтверные вендоры (IBM, Microsoft, Oracle, Sybase), так и относительно небольшие разработчики (Mark Logic, Progress, Software AG).
Лидерами рынка СУБД на данный момент являются компании IBM, Oracle, Microsoft (около 90% рынка), а на рынке СУБД, предназначенных для создания хранилищ данных, — IBM, Oracle, Microsoft, Sybase и Teradata. Предпочтительной платформой для хранилищ является СУБД Oracle DB2, на втором месте — Microsoft SQL Server.
СУБД с открытым кодом становятся все более привлекательными для корпоративных заказчиков, которые надеются снизить затраты на управление БД и избежать зависимости от конкретных поставщиков. По мнению аналитиков Forrester Research, рынок свободно распространяемых СУБД сейчас находится на пике своей зрелости, предлагая широкий выбор продуктов, качественную поддержку и обширную экосистему вокруг каждого из решений. Лидерами этого рынка являются СУБД Ingres, MySQL и PostgreSQL. Они отличаются высоким уровнем обработки транзакций и обеспечивают эффективные платформы БД для различных приложений. СУБД с открытым исходным кодом, как минимум, не уступающие, а в ряде случаев превосходящие, по возможностям другие СУБД, активно применяются в различных предметных областях.
Опыт показывает, что подобрать СУБД, удовлетворяющую всем требованиям, практически невозможно. Часто применяются решения о совмещении двух СУБД, которые в совокупности удовлетворяют большинству требований и упрощают создание БД. СУБД, выпускаемые компаниями Oracle и IBM, превосходят по возможностям и производительности СУБД с открытым исходным кодом.
Переход на новую версию СУБД можно делать только после выхода первого пакета обновлений, который обычно появляется через 6—12 месяцев после выпуска основного варианта. Смену версий СУБД надо проводить через одну версию. Это связано часто с тем, что новые версии СУБД ориентируются и на новые версии ОС.
Покупка и развертывание готового программного обеспечения обычно обходиться дешевле, чем разработка и внедрение равноценного заказного решения. Каждая СУБД, даже адаптированная, меньше подходит для конкретных потребностей и всех тонкостей бизнеса, чем программа, написанная и сделанная специально — и это при условии, что вообще удастся найти готовый продукт, который можно приспособить под нужды конкретного предприятия.
Любую СУБД можно купить и установить практически сразу же. Если требуется ее адаптация, то это может занять больше времени в зависимости от объема требуемых изменений. При выборе СУБД нужно обратить внимание на:
Литература
Перечень вопросов для самопроверки