Смекни!
smekni.com

Разработка системы автоматизации управления фермой СХПК "Алматы" (стр. 6 из 11)

В Microsoft SQL Server 6.5 механизм блокировок улучшен по сравнению с версией 6.0 и Sybase SQL Server поддержкой блокировок на уровне записей при вставке. Это увеличивает производительность вставки записей, но никак не решает другие проблемы со страничными, индексными или табличными блокировками. Поэтому, независимо от версии, обновление данных в архитектуре SQL Server все равно требует табличных или страничных блокировок для обеспечения целостности данных. [8]


2.9 Архитектура многоверсионности записей

InterBase обеспечивает оптимистические блокировки при помощи Архитектуры Многоверсионности Записей (Multi-Generational Architecture – [MGA]. Этот механизм создает оптимизированные версии для новых, удаленных или обновляемых записей, которые видны только в контексте конкретной транзакции, изменяющей данные. Реально, InterBase версионирует только изменяемые столбцы (поля) путем создания deltas. Это обеспечивает максимальную производительность и минимальные требования к дисковому пространству.

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

Страничные и табличные блокировки SQL серверов Microsoft и Sybase могут сильно влиять на производительность, когда многим пользователям требуется доступ к одним и тем-же данным (или находящимся на близлежащих страницах). Например, в реальных ситуациях, страничные блокировки в SQL Server могут замедлять доступ к данным (ожидание освобождения блокировок страниц, индексов или таблиц). Этот эффект может быть заметен в системах с большим объемом данных или когда пользователи выполняют создание длительных отчетов по данным в тот момент, когда другие пользователи модифицируют данные. Архитектура Многоверсионности записей InterBase гарантирует доступность данных на чтение для любых пользователей и в любое время. Клиентское приложение никогда не ждет доступности таблиц, записей или индексов, независимо от числа пользователей в системе или длительности и сложности какой-либо транзакции. Разработчики, использующие InterBase, автоматически получают максимум производительности приложений, безотносительно сложности обработки данных.

2.10 Двухфазное подтверждение транзакций

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

Транзакции характеризуются свойствами ACID:

- Atomicity (атомарность) - "все или ничего". Либо вся транзакция завершается, либо ни одна из ее частей. Если транзакция не может быть завершена, то все операции, произведенные внутри транзакции, отменяются;

- Consistency (целостность) - транзакция должна переводить базу данных из одного целостного состояния в другое. Целостность определяется бизнес-правилами (логикой базы данных) и вводится в действие приложением;

- Isolation (изоляция, изолированность) - Поскольку может возникать множество конкурентных транзакций, каждая транзакция должна быть изолирована от действий, производимых другими транзакциями. Т.е. транзакции должно "казаться", что она является единственной, выполняемой над базой данных;

- Durability (прочность)- Изменения, подтвержденные транзакцией, обязаны вступить в силу.

Если использовать в качестве примера снятие средств с расчетного счета, то все ACID-свойства должны иметь место. Представим что информация о получении товара хранится в одной БД, а информация о счете поставщика – в другой. В этом случае при регистрации счет-фактуры на полученные ТМЦ соответственно должен измениться счет поставщика, и выполняться это должно в одной транзакции. Такие ситуации обрабатываются при помощи двухфазного подтверждения транзакций (Two Phase Commit - 2PC). Это механизм, который применяет к изменениям в обоих базах данных свойства ACID.Двухфазное подтверждение транзакций имеет две отдельные фазы: подготовка и подтверждение. Если по какой-то причине процесс не может быть выполнен в течение фазы подготовки, например после регистрации счет-фактуры, но до изменения суммы счета поставщика, то транзакция должна быть отменена (rollback). Это гарантирует что на дебиторская задолженность поставщика будет соответствовать нашей кредиторской.

MicrosoftSQLServer и SybaseSQLServer требуют от разработчика программной обработки 2PC. InterBase обеспечивает автоматическую обработку 2PC в соответствии со всеми требованиями ACID без дополнительного программирования на любых платформах (Windows NT, DEC UNIX, HP-UX, Irix и т.д.). Это обеспечивает максимум легкости сопровождения при отсутствии дополнительных затрат.

2.11 Многоразмерные массивы

InterBase обеспечивает уникальный тип данных называемый Многоразменый Массив (Multi Dimensional Array [MDA]). Тип MDA не реализован ни в одной другой РСУБД. Тип MDA позволяет разработчику зранить массивы любой длины и до 16 измерений. Массивы предоставляют возможность хранения и представления данных в случаях, в большинстве невозможных для архитектуры SQL Server. Ключевой особенностью является производительность массивов. Дополнительно, если элемент массива содержит значение NULL, то Inter Base не выделяет для него дисковое пространство. В реляционных терминах, доступ к набору данных с одной стороны отношения, не имеющего соответствующего значения, потребует использования outer joun в любом запросе, использующем такое отношение. В большинстве РСУБД, производительность запросов с outer join невелика. Доступ к массивам Inter Base осуществляется другим способом, и поэтому не ухудшает скорость доступа к данным.

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

2.12 Обработка транзакций

Индустрия баз данных поддерживает несколько разных моделей транзакций для решения различных задач.

· OLTP:

Интерактивная обработка транзакций [OLTP] наиболее характерна для банковских операций. По такому сценарию, приложение выполняет серию коротких (по содержимому и по времени) транзакций. Приложению может потребоваться изменение одной-двух записей или небольшой отчет. Большие и длительные отчеты выполняются неинтерактивно.

· DSS:

Системы поддержки принятия решений (или анализа информации) [DSS] преназначены для поддержки длительных транзакций, таких как итоговые отчеты или статистический анализ. Этот тип систем зависит от относительно статического "вида" базы данных, для того чтобы обеспечить целостность данных на все время действия длительной транзакции.

· OLCP:

Интерактивная комплексная обработка [OLCP] является смесью моделей OLTP и DSS. Такая модель пытается поддержать баланс между этими двумя моделями, и предназначается для большинства реальных приложений. Такие требования приводят к необходимости иметь высокую производительность, возможность выполнения резервирования данных "на ходу", выполнять длительные запросы или длительные отчеты пока пользователи обновляют текущую информацию. Информация должна быть доступна в любое время без ограничения доступа как для OLTP так и для DSS транзакций.

SQL Server:

Архитектура SQL Server разработана для поддержки либо OLTP либо DSS, но не для одновременной поддержки обоих. Кроме этого, не поддерживается большинство требований к режиму OLCP для реальных приложений. Такие ограничения вызваны механизмом блокировок, используемым в SQL Server.

Borland Inter Base полностью поддерживает модель OLCP. Уникальная архитектура многоверсионности записей гарантирует, что пользователи транзакций OLTP не обнаружат блокировок при обновлении данных, используемых транзакциями DSS, в то время как транзакциям DSS гарантируется воспроизводимое чтение. Многоверсионность записей гарантирует воспроизводимость состояния БД как для чтения, так и возможность обновления данных независимо от уровня изоляции транзакции. Это снижает сложность и время разработки клиентских программ, и обеспечивает доступность корпоративных данных в любой момент.

2.13 Конфигурирование и настройка

· SQLServer:

Microsoft SQL Server и Sybase SQL Server имеют мириады конфигурационных опций и параметров настройки для оптимизации производительности базы данных. Многие их этих параметров достаточно сложны и могут влиять друг на друга. Только достаточно квалифицированный администратор БД может управлять всеми этими параметрами для настройки сервера. Например, в Sybase System 11 появилось более 200 параметров настройки. Это добавляет сложности к управлению сервером, стоимость обучения администратора БД, и предполагает что по мере усложнения используемой базы данных может потребоваться настройка севера.

· Inter Base:

Borland Inter Base автоматически конфигурируется и настраивается, и не требует никакого вмешательства администратора в настройки. Это максимально облегчает управление и сопровождение. В общем случае, у IB существует не более конфигурационных 20 параметров, которые практически никак не влияют друг на друга (основных параметров всего 3 - размер кэша и лимиты занимаемой памяти). Это сделано специально для уменьшения стоимости сопровождения и обслуживания. После установки, вмешательство администратора БД требуется разве что в случае катастрофического сбоя оборудования, или для регулярного выполнения bakup (который можно автоматизировать при помощи утилиты AT на Windows NT, или специальных утилит на UNIX).

2.14 Восстановление при сбоях

Автоматическое восстановление базы данных SQL Server включает в себя "воспроизведение" содержимого transaction logs. Этот процесс последовательно применяет к БД транзакции, сохраненные в transaction log для того чтобы восстановить состояние БД на момент последнего checkpint.