Версія для друку

Архітектура двигуна МД 3

Версія : 3.0.2.0 ++

Внутрішню побудову двигуна МД 3 можна уявити у вигляді стопки шарів, функції яких ускладнюються від нижнього до верхнього. Нижче нижнього шару лежать файлові функції операційної системи.

Отже, є такі шари :

PoolManager

ObjectManager

SegmentManager

SpaceManager

BlockManager

шар шифрування

StreamManager

StreamManager здійснює найпростіші операції читання/запису файлу; він також перехоплює помилки файлових функцій, але оскільки він стоїть дуже низько, обробка помилок в більшості випадків здійснюється у вищих шарах.

Шар шифрування здійснює шифрування/дешифрування БД. Оскільки він є зашифрованим, то більше про нього не говоримо.

BlockManager управляє блоками даних. Оскільки в ієрархічній СУБД все повинно бути ієрархічним, то і доступ до даних здійснюється за ієрархічною схемою. Блок – це фундаментальний об’єкт, який має дві основних властивості : по-перше, він є учасником загального дерева блоків; по-друге, він зберігає інформацію змінної довжини. Цей шар уже має досить інформації, щоб намагатись реагувати на помилки файлової системи; реакція може полягати у спробі відремонтувати пошкоджений блок або замінити його "протезом" заради збереження загальної працездатності двигуна.

SpaceManager веде облік вільних місць всередині файлу БД. Коли якась порція файлового простору звільняється, він бере її на облік, утворюючи блок вільного простору; коли хтось запитує певну порцію файлового простору, він спочатку дивиться, чи нема підходящого вільного блоку всередині файлу, і тільки якщо такого блоку нема, виділяє місце в кінці файлу. В попередніх версіях МД місце завжди виділялось в кінці файлу, і тому при інтенсивному редагуванні БД файл зростав досить швидко, а для утилізації невикористаного простору всередині файлу треба було стискати БД. Тепер стискати БД треба буде значно рідше.

SegmentManager є аналогом апарату таблиці розміщення файлів операційної системи. Його роль – вказати місце об’єкту всередині файлу БД за його ключем. Він не може жити без SpaceManager-а та StreamManager-а, але функції його досить прості.

ObjectManager є більш інтелектуальним шаром. Одиницею управління для нього є об’єкт – образ вершини дерева, який зберігається в БД. об’єкт складається з кількох блоків (число цих блоків є змінним, наперед не визначеним), тому даний шар дуже інтенсивно використовує сервіси BlockManager-а. На цьому шарі лежить основна відповідальність за "протезування" пошкоджених атрибутів, щоб вони не спантеличили весь двигун.

PoolManager управляє внутрішнім буфером об’єктів. При кожному запиті об’єкту, котрий поступає в двигун, він перш за все потрапляє сюди. Якщо потрібний об’єкт знаходиться в буфері (тобто в оперативній пам’яті), запит виконується значно швидше, ніж при потребі звертатись до файлу. Об’єкти, які найбільш інтенсивно використовуються, закріплюються в буфері; об’єкти, які не використовуються, поступово витісняються за алгоритмом LRU (least recently used – першим витісняється той, хто найдовше не був використаним). Буває аж дивно бачити, як буферу на 128 об’єктів вдається перехопити 90 % запитів ! Звісна річ, при модифікації або додаванні вершини об’єкт негайно записується на диск, а потім оновлюється його копія в буфері (в ЦК теж не дурні сидять).

Всі ці шари запаковані в один складний об’єкт – TMDStorage, сховище даних. Сховище з логічної точки зору є інтелектуальною надбудовою над файлом БД : для того, щоб відкрити файл БД і отримати з нього щось осмислене, треба створити об’єкт сховища. Один файл – одне сховище.

Але сховище є повністю невидимим, і користувач з ним безпосередньо не працює. У вікнах програми користувач бачить набори даних (datasets). Кожне вікно з даними володіє своїм набором даних, окрім того є певна кількість наборів даних для внутрішнього вжитку двигуна БД. Тому потрібен об’єкт "сеанс" (TMDSession), який управляє, з одного боку, сховищем, з другого боку – всіма наборами даних. В зоні відповідальності цього об’єкту лежить синхронізація відкритих наборів даних (наприклад, одна і та сама вершина є видимою в двох вікнах програми; користувач знищує цю вершину в одному вікні, а сеанс вимагає від другого вікна, щоб воно перемалювало свої дані у відповідності до нової ситуації. Оце й є синхронізація наборів даних).