База данных объектов Zope

редактировать
База данных объектов Zope
Разработчик (и) Zope Foundation
Стабильный выпуск 5.6.0 / 11 июня 2020 г.; 4 месяца назад (2020-06-11)
Репозиторий github.com / zopefoundation / ZODB
Написано наPython
Операционная система Кросс-платформенный
Тип База данных объектов
Лицензия Общественная лицензия Zope
Веб-сайтwww.zodb.org

База данных объектов Zope (ZODB ) - это объектно-ориентированная база данных для прозрачного и постоянного хранения объектов Python. Он включен как часть Zope web сервер приложений, но также может использоваться независимо от Zope.

Функции ZODB включают в себя: транзакции, историю / отмену, прозрачно подключаемое хранилище, встроенное кэширование, мультиверсионный контроль параллелизма (MVCC) и масштабируемость по сети (с использованием ZEO).

Содержание
  • 1 История
  • 2 Реализация
    • 2.1 Основы
    • 2.2 Пример
    • 2.3 Единица хранения
    • 2.4 Атомарность
    • 2.5 Сохранение класса
  • 3 ZEO
    • 3.1 Подключаемые хранилища
    • 3.2 Технологии аварийного переключения
  • 4 Ссылки
  • 5 Внешние ссылки
История
  • Создано Джимом Фултоном из Zope Corporation в конце 90-х.
  • Начато как простая система постоянных объектов (POS) во время разработки Principia (который позже стал Zope)
  • ZODB 3 был переименован, когда произошли значительные изменения в архитектуре.
  • ZODB 4 был недолгим проектом по повторной реализации всего ZODB 3 с использованием 100% Python.
Реализация

Основы

ZODB хранит объекты Python, используя расширенную версию встроенной в Python сохраняемости объектов (pickle). База данных ZODB имеет единственный корневой объект (обычно словарь), который является единственным объектом, напрямую доступным из базы данных. Доступ ко всем другим объектам, хранящимся в базе данных, осуществляется через корневой объект. Объекты, на которые ссылается объект, хранящийся в базе данных, также автоматически сохраняются в базе данных.

ZODB поддерживает параллельные транзакции с использованием MVCC и отслеживает изменения объектов для каждого объекта. Только измененные объекты фиксируются. По умолчанию транзакции являются неразрушающими и могут быть отменены.

Пример

Например, у нас есть автомобиль, описанный с помощью 3 классов Автомобиль, Колесои Винт. В Python это можно представить следующим образом:

class Car: [...] class Wheel: [...] class Screw: [...] myCar = Car () myCar.wheel1 = Wheel () myCar.wheel2 = Wheel () для колеса in (myCar.wheel1, myCar.wheel2): wheel.screws = [Screw (), Screw ()]

Если переменная mycar является корнем устойчивости, тогда:

zodb ['mycar'] = myCar

Это помещает все экземпляры объекта (автомобиль, колесо, винты и т. д.) в хранилище, которое можно будет извлечь позже. Если другая программа устанавливает соединение с базой данных через объект mycar, выполняя:

car = zodb ['myCar']

И извлекает все объекты, указатель на автомобиль, хранящийся в carпеременная. Затем на более позднем этапе этот объект можно изменить с помощью кода Python, например:

car.wheel3 = Wheel () car.wheel3.screws = [Screw ()]

Хранилище изменяется, чтобы отразить изменение данные (после того, как коммит заказан).

Нет объявления структуры данных ни в Python, ни в ZODB, поэтому новые поля могут быть свободно добавлены к любому существующему объекту.

Единица хранения

Чтобы иметь место, класс Python Car должен быть производным от персистентности. Постоянный класс - этот класс хранит данные, необходимые для работы механизма сохранения состояния, такие как внутренний идентификатор объекта, состояние объекта и т. Д., Но также определяет границу устойчивости в следующем смысле: каждый объект, чей класс происходит от Persistent - это атомарная единица хранения (весь объект копируется в хранилище при изменении поля).

В приведенном выше примере, если Car- единственный класс, производный от Persistent, когда wheel3добавляется в car, все объекты должны быть записаны в хранилище.. Напротив, если Wheelтакже является производным от Persistent, то при выполнении carzz.wheel3 = Wheelв хранилище записывается новая запись для хранения нового значения Car, но существующее Wheelсохраняется, а новая запись для Carуказывает на уже существующую запись Wheelвнутри хранилища.

Механизм ZODB не гонится за модификациями через граф указателей. В приведенном выше примере carzz.wheel3 = something- это модификация, автоматически отслеживаемая механизмом ZODB, потому что carzzотносится к классу (Persistent) Car. Механизм ZODB делает это, помечая запись как грязную. Однако, если есть список, любое изменение внутри списка не замечается механизмом ZODB, и программист должен помочь, вручную добавив carzz._p_changed = 1, уведомив ZODB о том, что запись действительно изменилась. Таким образом, в определенной степени программист должен знать о работе механизма сохранения состояния.

Атомарность

Единица хранения (то есть объект, класс которого является производным от Persistent) также является единицей атомарности. В приведенном выше примере, если Carsявляется единственным постоянным классом, поток изменяет Wheel (должна быть уведомлена запись Car), а другой поток изменяет другой Wheelвнутри другой транзакции вторая фиксация завершится ошибкой. Если Wheelтакже является постоянным, оба Wheelмогут быть изменены независимо двумя разными потоками в двух разных транзакциях.

Постоянство класса

Постоянство класса - запись класса конкретного объекта в хранилище - достигается записью своего рода «полностью определенное» имя класса в каждую запись на диске.. В Python имя класса включает иерархию каталогов, в которой находится исходный файл класса. Следствием этого является то, что исходный файл сохраняющегося объекта не может быть перемещен. Если это так, машина ZODB не может определить местонахождение класса объекта при извлечении его из хранилища, что приводит к поломке объекта.

ZEO

Zope Enterprise Objects (ZEO) - это реализация хранилища ZODB, которая позволяет множеству клиентских процессов сохранять объекты на одном сервере ZEO. Это позволяет прозрачное масштабирование.

Подключаемые хранилища

  • Сетевое хранилище (также известное как ZEO) - позволяет нескольким процессам python загружать и хранить постоянные экземпляры одновременно.
  • Хранилище файлов - позволяет одному процессу Python взаимодействовать с файлом на диске.
  • relstorage - позволяет использовать постоянное хранилище резервных копий в качестве RDBMS.
  • Directory Storage - все постоянные данные хранятся как отдельный файл в файловой системе. Аналогично FSFS в Subversion.
  • Demo Storage - внутренняя часть в памяти для постоянного хранилища.
  • BDBStorage - которая использует серверную часть Berkeley DB. Сейчас заброшены.

Отказоустойчивые технологии

  • Zope Replication Services (ZRS) - коммерческое дополнение (с открытым исходным кодом с мая 2013 года), которое устраняет единую точку отказа, обеспечивая горячее резервное копирование для записи и загрузки. балансировка чтения.
  • zeoraid - решение с открытым исходным кодом, которое предоставляет сетевой прокси-сервер, который распределяет хранилища объектов и восстановление по ряду сетевых серверов.
  • relstorage - поскольку используются технологии РСУБД, это устраняет необходимость в сервере ZEO.
  • NEO - реализация распределенного (отказоустойчивость, балансировка нагрузки) хранилища.
Ссылки
Внешние ссылки
Последняя правка сделана 2021-06-23 11:23:16
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте