CC BY
64
Как мы видим, каждый раз вызывается нужная версия виртуальной функции.
Функция, которая была объявлена виртуальной, остается ею, сколько бы производных классов ни образовывалось. Но иногда в одном или нескольких производных классах переопределение виртуальной функции может отсутствовать. Тогда механизм подключения виртуальной функции сохраняется и вызывается функция класса, которая ближе к рассматриваемому классу. Если будет отсутствовать аспект виртуальной функции, это не нарушит механизм позднего связывания, и если у наследников такого класса появится аспект виртуальной функции, он будет вызываться без каких-либо нарушений.
Литература
1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. - М.: Бином; СПб.: Невский диалект, 2001. - 560 с.
2. Бьерн Страуструп. Язык программирование C++. М.: Бином, 2001. - 1099 с.
3. Г. С. Иванова. Объектно-ориентированное программирование. - МГТУ им. Н. Э. Баумана, 2002.
4. Курс: Основы информатики и программирования. Лекция №10: Основы объектно-
ориентированного программирования. Применение ООП к разработке программных проектов. Основные концепции ООП, www.intuit.ru/department/se/oip/10/
УДК 004.652.5
ОБЪЕКТНАЯ БАЗА ДАННЫХ ДЛЯ СТУДЕНТОВ
Неудачин Илья Георгиевич, к.ф.-м.н., доцент, Уральский федеральный университет имени первого Президента России Б.Н.Ельцина, Россия, Екатеринбург, [email protected]
Введение
ZODB (Zope Object DataBase) - система хранения объектов приложений, написанных на языке Python. Она обеспечивает язык программирования средствами, которые автоматически записывают объекты на диск и читают их снова, когда они требуются программой. Установка ZODB добавляет такие средства к Python. Пакет ZODB выделен из инфраструктуры разработки и Web-публикации объектов Zope [1, 2], для которой - это стандартная объектная база данных (ОБД). Изучая ОБД, студенты осваивают разнообразие архитектур баз данных. Так же как Python и Zope, ZoDB поставляется в открытых кодах (http://old.zope.org/Products/ZODB3.2), бесплатно и с лицензией, благоприятной для ее модификации студентами и дальнейшего применения.
1. Подробное описание инструментария
К выбору ZODB как предмета обучения приводят три основные причины. Во-первых, ZODB - открытый продукт. Что позволяет студентам, при желании, не только видеть, как что-то работает, но понимать, как это работает. Во-вторых, использование ZODB бесплатное. Это позволяет изучать, исследовать и приобретать опыт без больших расходов. В-третьих, можно изменять коды ZODB. Она интересна как пользователям и администраторам, так и тем, кто программирует на языке Python. Описываемый учебный материал частично применяется при подготовке студентов - бакалавров профиля «Вычислительные машины, комплексы, системы и сети: системная интеграция». ОБД дала логическую связку между учебными разделами программирования на языке Python и проектированием динамических Web-приложений в инфраструктуре Zope [3].
В ZODB хранится не только объект, но и его текущее состояние, информация о нём, а также как он используется. Т.е. запоминаются действия пользователя, что допускает отмену пользователем этих действий. ZODB поддерживает транзакции, версии, откат и, как следствие, - упаковку завершенных транзакций и версий. Эта мощная объектная система баз данных, которая может использоваться с Zope или без Zope.
67
Сама ZODB объектно-ориентированна, то есть описывается как пакет деревьев классов. В ней можно произвольно менять класс, задающий вид хранилища (Storage). Рассматривается программирование на языке Python для ZODB и для ее расширения с помощью компонента ZEO (Zope Enterprise Objects). Последний механизм добавляет масштабируемость и распределенность ОБД в сети.
Объекты экземпляра инфраструктуры Zope [4] хранятся базой данных ZODB в формате файла Data.fs (в автономном случае может быть другое имя файла), который полностью независим от платформы и ОС. Собственно, ядром ZEO является еще одно хранилище ServerStorage, которое обращается не к локальному Data.fs, а к удаленному серверу. Вторым компонентом ZEO является сервер. На основе ранее полученных сведений становится понятными место ОБД в архитектуре Zope и реализация интерфейса управления ее главными параметрами.
2. Время жизни объекта
Если речь идет о рядовой программе, то время жизни объекта некоторого класса, описанного в программе на языке Python, ограничивается временем выполнения этой программы. Ограничения снимаются путем сохранения объектов (точнее, значений полей объектов) в файле. Обычно используется логическая архитектура реляционной или объектной базы данных. Все эти средства позволяют делать объекты хранимыми (persistent). Как правило, при записи объекта производится его сериализация, а при чтении -десериализация. Сериализация - это процесс перевода какой-либо структуры данных в последовательность битов. Сериализация используется для передачи объектов по сети и для сохранения их в файлы. Обратной к операции сериализации является операция десериализации - восстановление начального состояния структуры данных из битовой последовательности.
Реляционные базы данных не специализируются на объектах, их назначение более универсальное, чем ОБД [5]. Реляционные базы данных сохраняют информацию в таблицах. Не трудно написать код Python, который создаст экземпляр объекта и заполнит его данными из таблиц. Немного больше усилий, и можно сформировать простой инструмент, обычно называемый объектно-реляционным преобразователем, для того чтобы делать это автоматически. Однако трудно сделать объектно-реляционную СУБД приемлемо быстрой. Бесхитростная реализация, подобная первому примеру, - слишком медленная, потому что она должна делать несколько запросов, чтобы обратиться к данным всего объекта. Более высокоэффективные объектно-реляционные преобразователи кэшируют объекты, чтобы улучшить эффективность, выполняя SQL запросы, только когда они фактически необходимы.
В настоящее время разработаны специализированные ОБД для объектов Python. Самое простое решение - объединить модуль pickle и модуль базы данных, чтобы сохранять и восстанавливать объекты. Фактически, модуль shelve, включенный в стандартную библиотеку Python, делает это. ZODB и ZEO относятся к базам данных с развитыми возможностями. Объектная база данных, подобная ZODB, просто сохраняет внутренние указатели объекта на объект. Чтение одиночного объекта происходит намного быстрее, чем выполнение связки запросов SQL и сборка результатов. Просмотр всех включений, следовательно, все еще остаётся неэффективным, но не чрезвычайно неэффективным.
Недостаток этого подхода состоит в том, что программист Python должен явно управлять объектами, читая объект, когда это необходимо, и записывать его в файл, когда объект больше не требуется. Конечно, ZODB в инфраструктуре Zope управляет объектами за вас, храня их в кэше, и записывая их на диск, если к ним не обратились некоторое время.
3. Архитектура ZODB
Автономная установка ZODB выглядит (рисунок 1) как пакет из нескольких каталогов, содержащих модули.
68
Рис. 1 - Пакет ZODB
Рис. 2 - Взаимодействие ОБД с приложением [6]
Компоненты, входящие в установку ZODB:
• Ядро ZODB, включая процессор хранения.
• Стандартные хранилища типа FileStorage.
• Модули классов хранения persistent.
• Модули для сохранения Б-ДЕРЕВЬЕВ Btrees.
• ZEO, сервер хранилища по подключению TCP/IP.
• ZConfig - пакет конфигурации Zope. Зачастую для одного и того же кода требуется использование различных хранилищ. Например, на станции разработчика это может быть FileStorage с тестовыми данными, а на рабочего сервере - ClientStorage с реальными данными. Поэтому удобно использовать конфигурации и конфигурационные файлы. С ZODB идет еще один «кусочек» Zope - это пакет ZConfig. Т.е. в коде клиентов нужно указать, какой конфигурационный файл будем использовать
• Документация.
Компоненты архитектуры базы данных ZODB предоставляют программисту много возможностей:
• Многочисленные виды памяти (Storage Interface).
• Поддерживаются разнообразные администраторы хранения, что позволяет сохранять объекты в файловой системе, во временной файловой системе, в файловой системе только для чтения, и в реляционной базе данных.
• Прозрачность. Действия ZODB прозрачны для объектов. Объекты, которые желательно хранить, потребуют только «встраивания» в класс Python Persistent.Persistence.
• Транзакции. ZODB работает с транзакциями, т.е. последовательности изменений для базы данных могут происходить в виде транзакции. Если ошибка возникла где-нибудь в транзакции, то транзакция не будет передана в базу данных.
69
• Возвраты (Undo). Многие администраторы хранения выходного буфера конкатенируют новые версии объектов к концу базы данных и хранят все старые изменения объекта. Эти администраторы позволяют вам вернуть базу данных обратно - в предыдущее состояние, транзакция за транзакцией.
• Высокая эффективность. ZODB имеет много эффективных расширений, включая объектный кэш «в памяти» с конфигурацией перестраиваемого размера.
На текущую версию ZODB часто ссылаются как на ZODB3.
4. Принцип работы ZODB
ZODB концептуально проста. Классы Python наследуют классу Persistent для связи с ZODB. Экземпляры хранимых объектов поступают из постоянного хранилища данных, типа дискового файла, когда программа нуждается в них, и кэшируются в оперативной памяти. ZODB улавливает модификации объектов. Когда команда Python типа obj.size = 1 выполнена, изменяемый объект отмечается как изменённый (dirty, «грязный»). По запросу, любые грязные объекты записываются во внешнее постоянное хранилище. Дополнительный атрибут dirty порожден передачей транзакции. Транзакции могут быть прерваны или прокручены обратно, что кончается отказом от любых изменений, а грязные объекты, возвращаются к их начальному состоянию, в котором транзакция началась.
Термин «транзакция» имеет специфическое техническое значение в информатике. Чрезвычайно важно, что содержание базы данных не разрушается программными или аппаратными сбоями. Большинство программ обеспечения баз данных предлагает защиту против такого искажения, поддерживая четыре полезных свойства ACID (Atomicity, Consistency, Isolation, Durability). Что означает: Атомарность, Согласованность,
Изолированность, Долговечность.
ZODB имеет почти полную ACID - совместимую поддержку транзакций (включая точки сохранения информации о текущем состоянии системы). ZODB обеспечивает три из этих свойств. Не в полной мере поддерживается только согласованность. ZODB не применяет понятие структура базы данных, следовательно, не имеет способа предписания согласованности структур.
5. Классы интерфейса хранения
Есть три основных интерфейса, поддерживаемых ZODB: Storage - хранилище, DB -база данных и классы Connection - подключений. Интерфейсы DB и Connection имеют одиночные реализации, но есть несколько различных классов, которые реализуют интерфейс хранения Storage.
• Классы хранения Storage находятся на самом низком уровне, и управляют сохранением и восстановлением объектов из некоторой формы долгосрочного хранения. Были написаны несколько различных типов Storage. Как, например, класс FileStorage, который использует регулярные дисковые файлы, или bsddb3Storage, который применяет базу данных Sleepycat Software BerkeleyDB. Можно написать новый класс Storage, который сохранит объекты в реляционной базе данных или в файле специального формата, например, если это лучше подходит конкретному приложению.
• Класс DB размещается на вершине хранилища, и обеспечивает взаимодействие между несколькими подключениями. Один экземпляр DB создается на один процесс.
• Наконец, класс Connection кэширует объекты, и перемещает их в и из хранилища объектов. Multi-threaded программа должна открыть отдельный экземпляр Connection для каждой нити. Различные нити могут затем изменять объекты и передавать их модификации независимо.
Подготовка к взаимодействию с ZODB происходит за три шага: нужно открыть объект хранилища Storage, затем создать экземпляр базы данных DB, который использует Storage, и получить подключение Connection из экземпляра DB. Все это описывают всего несколько
70
строчек кода:
from ZODB import FileStorage, DB
storage = FileStorage.FileStorage('test-filestorage.fs') #1
db = DB(storage) #2
conn = db.open() #3
#здесь выполняются операции с ОБД test-filestorage.fs
Можно легко задействовать совершенно другой механизм хранения данных, изменив первую строку (#1), которая открывает Storage (рисунок 2). Вышеупомянутый пример использует FileStorage. ZODB устанавливается с несколькими различными классами, которые обеспечивают интерфейс хранения Storage. Такие классы управляют записью объектов Python на физический носитель данных, которым может быть дисковый файл (класс FileStorage), BerkeleyDB файл (BerkeleyStorage), реляционная база данных (DCOracleStorage) или некоторая другая среда.
ZODB предлагает много различных способов хранения объектов, включая файлы, реляционные базы данных и специальное хранилище клиент/сервер, которое сохраняет объекты на удаленном сервере. Здесь был создан объект хранилища (тип FileStorage) и подключен к базе данных. Zope устанавливается с несколькими классами баз данных для хранения объектов, но один из них наиболее интересный - это ClientStorage из продукта ZEO.
6. Принцип работы ZEO
ZEO добавляет ClientStorage (новое хранилище Storage), которое не записывает объекты на физические носители, а только пересылает запросы по сети на сервер. Сервер, который управляет экземпляром класса StorageServer, просто действует как внешний интерфейс для некоторого физического класса хранения Storage. Это - довольно простая идея, которая открывает много возможностей.
Хранилище ClientStorage совершает TCP/IP подключение к StorageServer (сервер также предоставляет ZEO). Сервер обслуживает много различных процессов на одной или нескольких машинах, позволяя работать с одной и той же объектной базой данных и, следовательно, с одними и теми же объектами. Каждый процесс получает кэшируемую «копию» специфического объекта для быстродействия. Все ClientStorage, подключенные к StorageServer, общаются по специальному объектному протоколу с контролем аннулирования передачи и с кэшированием, чтобы синхронизировать все компьютеры. ClientStorage просто делает удаленные вызовы процедуры на сервер, который затем передает их регулярному классу хранения типа FileStorage. ZEO состоит из приблизительно 6000 строчек кода Python, исключая тесты. Текст относительно мал, потому что содержит код только для сервера TCP/IP и для нового типа хранения - ClientStorage.
Любое число процессов может создавать экземпляр ClientStorage и любое число нитей в каждом процессе может использовать этот экземпляр. ClientStorage интенсивно кэширует объекты локально, для того чтобы избежать использования несвежих данных. Сервер ZEO посылает сообщение аннулирования всем подключенным экземплярам ClientStorage при каждой операции записи. Такое сообщение содержит ID для каждого измененного объекта, позволяя экземплярам ClientStorage удалить старые данные этого объекта из их кэшей.
7. Пакет Btrees
Программисту ZODB словари Python не всегда подходят. Наиболее важный случай -тот, когда нужно сохранить очень большое отображение. Когда к словарю Python обращаются в ZODB, весь словарь должен быть расконсервирован и принесен в память из хранилища. Если сохранять что-то очень большое, типа базы данных 100000 пользователей, расконсервирование такого большого объекта будет медленным. Для хранения большого объема данных обычные словари не эффективны.
В ZODB есть пакет BTrees, реализующий B-tree. B-tree (по-русски произносится как Б-дерево) - это структура данных, дерево поиска. С точки зрения внешнего логического
71
представления - это сбалансированное, сильно ветвистое дерево во внешней памяти. BTrees содержит структуру дерева данных, которая ведёт себя подобно отображению, но распределяет ключи по ряду узлов дерева. Узлы сохраняются в отсортированном порядке. Затем только тогда узлы расконсервируются и переносятся в память, когда к ним обращаются, и все дерево не занимает память.
Рис 3. Пользователи ZODB по данным http://www.ohloh.net/p/zodb
Пакет BTrees имеет разнообразные структуры данных, специализированные для обработки ключей, которые действуют быстрее и используют меньше памяти. Есть пять модулей, которые обрабатывают различные варианты. Первые два символа имени модуля определяют типы ключей и значений в отображениях - O для любого объекта и I для целого числа. Модуль BTrees.IOBTree обеспечивает отображение, которое принимает целочисленные ключи и произвольные объекты как значения. Пять модулей называются OOBTree, IOBTree, OIBTree, и (новый модуль из ZODB 3.4) IIBTree. Два символа префикса повторяются в именах типов данных. Например, модуль BTrees.OOBTree определяет следующие типы: OOBTree, OOBUCKET, OOSET, и OOTREESET. Точно так же каждый из остальных четырех модулей определяет собственные варианты этих четырех типов.
Выводы
Рассмотрим некоторые достоинства ZODB:
• Родная объектная база данных (ОБД) для Python, т.е. любые объекты классов Python могут сохраняться в ZODB. Прозрачное хранение объектов Python.
• Транзакции. Хранение истории/возможность отмены.
• Удобный интерфейс к ZODB в Zope.
• Масштабируемая архитектура ОБД через ZEO.
• Эффективная поддержка больших двоичных объектов.
• Сменяемые хранилища.
• Открытые, модифицируемые коды.
• Кроссплатформенная.
• Не нужен SQL.
Однако у ZODB имеются и недостатки, перечисленные ниже:
• Необходимо знание языка Python на уровне выше среднего.
• Сильная ассоциация с Zope.
• Низкая популярность объектных баз данных вообще.
72
• Отсутствует интерфейс СУБД.
• Система транзакций и опция отмены добавляют к размеру файла ОБД лишние килобайты. Необходимо налаживать периодическую упаковку и чистку ОБД.
• Нет специализированного языка запросов для ZODB.
• Скудная документация вообще и на русском языке в частности.
• Не любые объекты классов Python могут сохраняться в ZODB, т. к. для полноценного ее использования достаточно большой процент объектов должен быть унаследован от специального класса persistent.
Преимущества ZODB превосходят ее недостатки, поэтому она популярна среди пользователей (рис. 3). Как видим, активность сообщества пользователей ZODB стабильна с 2005 года и даже имеет тенденцию роста по приведенной 100-бальной шкале.
Литература
1. Спикльмайр С. и др. Zope. Разработка Web-приложений и управление контентом: Пер. с англ. - М.: ДМК Пресс, 2003. - 464 с.
2. Неудачин И.Г. Среда Web-публикации объектов для студентов // Объектные системы - 2011: материалы III Международной научно-практической конференции. / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - с. 62-65.
3. Неудачин И.Г. Инфраструктура программирования в открытых кодах для студентов. //Теория
и практика применения свободного программного обеспечения: сборник трудов
участников Всероссийской молодёжной конференции с элементами научной школы. -Магнитогорск: МаГУ, 2011. - с. 57-64.
4. Неудачин И.Г. Объектный дизайн Web-порталов. Объектные системы - 2011 (Зимняя сессия): материалы V Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2011. -с. 63-67.
5. ORM как антипаттерн. Шитов Н.А., Галиаскаров Э.Г., Объектные системы - 2011 (Зимняя сессия): материалы V Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2011. -с. 72-76.
6. Andrew M. Kuchling. The MEMS Exchange Tools: A shortened version of the ZPUG slides,
presented at the Python10 conference, Feb. 6 2002. [Электронный ресурс]
http://www.amk.ca/talks/2002-02-06/
УДК 004.4
МОДЕЛИРОВАНИЕ СИСТЕМЫ ПЛАНИРОВАНИЯ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛИТЕЛЬНЫХ РЕСУРСОВ В ИССЛЕДОВАТЕЛЬСКИХ ЗАДАЧАХ
Жукова Светлана Александровна, к.т.н., доцент, Чайковский технологический институт (филиал) Ижевского государственного технического университета, Россия, Чайковский, otdel [email protected] Патютько Вадим Николаевич, студент, Чайковский технологический институт (филиал) Ижевского государственного технического университета, Россия, Чайковский
Введение
Важнейшим направлением повышения эффективности информационных технологий является развитие уровня автоматизации процессов комплексных поставок потребителям разнообразных сервисных процедур. Возрастает интерес к программному обеспечению, которое предоставляет удаленный доступ к ресурсам и сервисам в едином формате. Разработка такого программного обеспечения осуществляется с применением web-технологий, технологий открытых систем, среди которых особо актуальна технология «облачных вычислений» [1].
«Облачная» модель распространения и поддержки программного обеспечения предполагает использование программных приложений в режиме удаленного доступа. Суть
73
