Uirh : другие произведения.

Общие соображения о хранении данных

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
Ссылки:
Школа кожевенного мастерства: сумки, ремни своими руками
 Ваша оценка:
  • Аннотация:
    точнее о том куда следует развивать файловую систему. Написано как статья для какого-то журнала (т.е. в мутном псевдонаучном стиле) тоже пост-фактум (когда всё уже давно придумано) но всё же несколько раньше чем пресловутая "постановка задачи" (году в 95м)
   К вопросу о построении файловых систем следующего поколения.
  
   0. Под файловой системой понимается: способ долговременного хранения информации во внешней памяти, набор соглашений по этому поводу, программные средства, обеспечивающие выполнение этих соглашений и как правило являющиеся частью операционной системы. К первому поколению можно отнести системы предоставляющие прикладной программе доступ к физическим устройствам по "дисковым адресам". Второе поколение - традиционные файловые системы, самостоятельно распределяющие дисковое пространство и предоставляющие его пользователю в виде множества именованных бесструктурных последовательностей элементов (байтов или записей) неопределенной длины - файлов. Следовательно следующее поколение средств долговременного хранения данных будет "третьим".
  
   1. Явной, очевидной, вопиющей необходимости изменения структуры и организации файловой системы вроде как не наблюдается - существующая вполне справляется с возлагаемыми на неё обязанностями, но... Но с течением времени многое изменилось. Возросла производительность и объем памяти, предоставляемые аппаратными средствами, появились новые классы задач, усложнилась структура используемых информационных объектов... Внешне это выглядит так: файлы размножаются. Где раньше были единицы файлов, там сейчас десятки и сотни. Или иногда тоже несколько файлов, но в десятки и сотни раз большего объема. Типичный программный продукт, раньше представлял собой один выполняемый файл. В крайнем случае к нему добавлялась парочка файлов данных. Сейчас это каталог, набитый под завязку. (При этом как правило нельзя сказать, что функциональные возможности программных продуктов сильно расширились, по сравнению с тем что было раньше. Разве что интерфейс...) "Статус" файла сильно упал. Их создают по любому поводу и без повода. Эти, некогда чрезвычайные, действия нынче рассматриваются как вполне рядовые... В общем всё бы ничего, только вот файлов развелось очень уж много.
   Наблюдаемое вавилонское столпотворение (накопление сложности) является следствием усложнения приложений, обслуживаемых файловой системой. Его следует рассматривать как симптом всё более увеличивающегося семантического расстояния между "файловой" моделью представления данных и способами организации информации в прикладных задачах. Современные программные средства, и в частности "windows" стараются скрыть от пользователя действительную сложность окружающей его среды. И тем самым, к сожалению, загоняют болезнь вглубь. По-настоящему избавиться от излишней сложности можно только сокращением упомянутого семантического разрыва - переходом к более совершенной модели представления данных, реализацию которой и можно назвать файловой системой следующего поколения. (Только она уже не будет называться "файловой".)
  
   2. Не вдаваясь в подробности, хорошо всем известные, определим типичную "файловую" модель представления данных как набор именованных информационных объектов, традиционно именуемых "файлами". Каждый файл это модель "последовательного" носителя информации, на подобии магнитной ленты. То есть бесструктурная последовательность одинаковых информационных элементов (элементарных - байтов, или более сложных - записей) переменного размера, имеющая четко выделенное начало. Между собой файлы никак не связаны. Манипуляции с файлами моделируют соответствующие манипуляции с магнитной лентой: перед использованием файл следует "открыть" (поставить ленту на магнитофон) указав его по имени; после использования - "закрыть" (снять с магнитофона); возможны чтение и запись элементов данных, каждая из которых сдвигает "головку чтения/записи" на следующий элемент. Возможна перемотка, либо только к началу и к концу, либо к любому указанному элементу. (В последнем случае можно сказать, что существует некоторая координатная сетка.) Более развитые модели обладают средствами разделения области хранения файлов на подобласти (каталоги).
   "Файловая" модель обладает многими неоспоримыми достоинствами, среди которых следует особо отметить универсальность, простоту и интуитивную понятность. Кроме того, эта модель позволяет естественно изображать многие внешние устройства, как диски и ленты, так и линии связи.
  
   3. Характерные особенности файловой модели - бесструктурность хранимой информации и отсутствие информационных связей как между элементами данных, так и между файлами позволяют непосредственно представлять только простейшие информационные структуры. (Например "поток".) Более сложные - реализуются на следующих уровнях средствами (частично) системного и (в основном) прикладного программного обеспечения. Многочисленные попытки привнести структуру в элементы данных и организовать связи между ними именно на уровне файловой системы привели к появлению моделей баз данных. Среди которых наиболее широко известны три: "иерархическая", "сетевая" и "реляционная". А так же систем управления базами данных (СУБД), реализующих эти модели. Модели баз данных вполне универсальны, СУБД способны играть роль файловой системы. Но из за отсутствия интуитивной понятности этих моделей и чрезвычайной сложности даже минимально необходимого набора операций они не получили распространения за пределами предметной области, для которой были разработаны.
   Из этого можно сделать вывод, что не достаточно просто внести в модель представления данных некоторые необходимые средства - надо добиться чтобы эта новая модель получилась максимально понятной и простой в использовании.
  
   4. Модель информационной структуры общего вида можно представить себе в виде произвольного графа, нагруженного как по вершинам, так и по связям. Однако существующие аппаратно-программные средства позволяют строить только направленные графы, нагруженные по вершинам: цепочка смежно расположенных слов рассматривается как вершина, а связи образуются с использованием координатной сетки - системы адресации, присущей запоминающему устройству, где размещается модель. Впрочем этого тоже вполне достаточно для представления произвольной информационной структуры.
   Современные модели представления данных как в оперативной памяти, так и на внешних устройствах, предоставляют только зачаточные средства для реализации информационных структур. Этим и обуславливается излишняя сложность прикладного программного обеспечения, так как основная работа ложится на него. В частности, данные ничего "не знают" о своей организации, эти сведения "абсорбируются" в программном обеспечении, что идет ещё от архитектуры фон-Неймана.
   Поставим себе задачу: найти пути упрощения программного обеспечения предоставлением ему возможности отвечать только за алгоритм обработки информационной структуры и освобождения от забот об её организации - за счет совершенствования модели представления данных.
   Для информационной структуры, имеющей вид произвольного ориентированного графа, нагруженного по вершинам, от модели представления данных требуется две базовые возможности: а) представление вершин, для чего необходимо разделение информации на "порции" (записи, сегменты, области...), каждая из которых изображала-бы одну вершину; б) представление связей, для чего традиционно используется механизм ссылок. Причем достаточно иметь ссылку на всю вершину, а не на отдельное поле внутри представляющей её записи.
   Заметим, что недостаточно просто снять заботу о структуре элементов данных и связях между ними с прикладного программного обеспечения, переложить его на системное (а по возможности - частично на аппаратуру), предоставив прикладному уровню средства доступа к полям данных и навигации по связям. В результате этого получится новая редакция сетевой модели организации баз данных, столь же сложная и не удобная к использованию. И хотя она сама по себе может представлять определенный интерес, на роль файловой системы не годится. Необходимо двигаться дальше.
  
   5. Итак, файловая система берет на себя заботу о связях между элементами, призванными представить вершины графа. (Мы будем называть их "сегментами".) Это ведет к необходимости отличать указатель от данных других типов. Для защиты целостности файловой системы требуется производить контроль за манипуляциями над указателями. Для удобства реализации желательно чтобы указатель занимал один информационный элемент (слово, поле записи). Поэтому от символических имен файлов/сегментов придется отказаться. Вместо этого снабдим сегменты условными номерами. При необходимости сохранения символических имен можно ввести таблицы соответствия имен номерам. (Аналогичным образом организована система каталогов ОС UNIX.)
   Возможность прослеживать связи позволяет возложить на файловую систему и заботу о времени жизни сегментов: сегмент существует до тех пор, пока на него есть ссылки из других сегментов. Точнее говоря пока до него есть путь от "корня" файловой системы - выделенного сегмента, который существует всегда. Добиться этого можно как путем подсчета ссылок, так и с помощью регулярной сборки мусора - потерянных сегментов.
   Обратим внимание, что мы фактически вводим самоопределяемость данных. Точнее говоря самоопределяемость на уровне сегментов (или файлов) существует сама по себе. Сегмент (файл) "естественным" образом снабжен набором атрибутов (как минимум это размер и местоположение), который при необходимости может быть легко расширен. Мы распространяем это свойство вниз - на уровень элементарных значений, где начинаем выделять данные нескольких, как минимум двух, типов. (О реализации этого сейчас задумываться не будем.) А так же вверх - на надсегментный уровень, который сейчас рассмотрим - уровень объектов.
  
   6. Самостоятельную информационную единицу, призванную заменить файл, будем называть "объектом". Сегменты не самостоятельны и предназначены быть компонентами объекта. В предельном случае объект может состоять из одного единственного сегмента и являться полным функциональным аналогом файла. В более сложных случаях объект состоит из множества сегментов, связанных ссылками, среди которых выделяется один - корневой сегмент объекта. Остальные считаются подчиненными. Среди подчиненных сегментов могут встретиться корневые сегменты других объектов, являющихся компонентами данного.
   Внутренняя структура объекта, в отличии от файла, недоступна. Манипуляции с ним производятся с помощью набора абстрактных операций. Операции определяются при конструировании класса объектов в соответствии с его смыслом и функциональным назначением. Прикладные программы пишутся в терминах этих абстрактных операций и избавлены от необходимости (да и не имеют возможности) обращаться к деталям реализации объекта.
   Объект, точнее множество одинаково устроенных объектов - класс, реализуется определением внутренней структуры объекта и набора программ, выполняющих с объектом необходимые действия. (Их традиционно называют "методами".) Объект состоит из элементарных значений и других объектов (в виде ссылок на них), поэтому метод тоже пишется в терминах абстрактных операций объектов-компонент. (Кроме того, разумеется, используются встроенные операции, предоставляемые системой программирования.)
   Не будем дальше расписывать прелести объектной парадигмы, они общеизвестны. Заметим только, что прикладная программа может быть реализована тем же способом что и "системная" - набор методов. Более того между ними нет никакой границы - прикладные программы расширяют функциональные возможности файловой системы и вполне могут рассматриваться как её часть.
  
   7. Подведем некоторые предварительные итоги: оказывается, мы строим "объектную" модель представления информации.
   Основной структурной единицей является "объект". Он может быть снабжен собственным именем, помещенным в один из каталогов (тогда он будет видим и доступен пользователю), или может являться только одним из компонентов другого объекта. Вспомогательной структурной единицей является "сегмент". Это (так же, как и файл) последовательность элементов (байтов, слов или записей). Каждый объект имеет корневой сегмент, но не каждый сегмент является корневым сегментом какого либо объекта - некоторые содержат "сложные значения". Самой младшей структурной единицей является поле сегмента - вместилище элементарного значения.
   На всех трех уровнях данные самоопределяемы. На верхнем - объект принадлежит к некоторому классу и обрабатывается только с помощью заготовленных для этой цели процедур. Процедуры вызываются "по наименованию". При вызове не надо знать ни фактического местоположения процедуры, ни даже то, существует ли она вообще. Новые классы могут создаваться по мере необходимости. Существующие можно доопределять с помощью механизма "наследования". На среднем уровне сегмент снабжен набором атрибутов, которые существенно используются всеми работающими с ним процедурами. Набор этих процедур фиксирован. На нижнем уровне самоопределяемость частичная и зависит от реализации. Как минимум ссылки отличаются от данных прочих типов и производится контроль над манипуляциями с ними.
   Пользователю доступен верхний уровень модели. Прикладные программы фактически дополняют и расширяют его. Здесь модель представления данных описывается в терминах предметной области поэтому остается понятной при любой сложности. Средний уровень модели - типичная база данных с характерным, достаточно сложным и громоздким набором средств. Нижний уровень - элементарные значения и элементарные операции над ними, какие могут быть выполнены непосредственно аппаратурой.
  
   8. Если пользователю достаточно существующих в системе классов - никаких проблем не возникает. Однако если имеется необходимость определить новые классы, то для реализации методов необходим доступ к средствам среднего и нижнего уровня. При этом имеется единственная возможность избежать издержек, связанных с их сложностью и громоздкостью - отождествить со средствами, предоставляемыми системой программирования и тем самым сделать "невидимыми".
   Традиционный подход - средства операционной и файловой системы доступны в виде набора "системных вызовов" - удобен и естественен когда эти средства дополняют систему команд физической машины. Достраивают и развивают её архитектуру. В идеале должно быть незаметно, что одни средства "основные", а другие "дополнительные". Однако к нашему случаю это не относится.
   Система программирования с одной стороны предоставляет один или несколько алгоритмических языков, а с другой преобразует тексты на этих языках в последовательность команд, предназначенную для выполнения расширенной физической, или может быть виртуальной машиной. Эти команды предписывают операции над данными и обращения за этими данными к некоторым информационным структурам, отождествляемым с областями оперативной памяти. (Хотя это не всё - есть ещё "управление" и "интерфейс".)
   Выше мы уже обратили внимание, что средства нижнего уровня аналогичны набору операций физической машины. Аналогичны, но не тождественны - подавляющее большинство современных ЭВМ не имеют средств распознавания типов обрабатываемых данных. Осталось заметить, что средства среднего уровня по своему смыслу - обращения к информационным структурам - "сегментам". После этого можно утверждать, что те и другие составляют существенную часть некоторой виртуальной машины. Дополнив их недостающими средствами "управления" и "интерфейса" получим виртуальную машину, вполне пригодную для выполнения процедур верхнего объектного уроня - "методов".
   Таким образом, средства двух нижних уровней файловой системы не дополняют физическую машину (получилась бы эклектика), а сами являются компонентами некоторой виртуальной машины. При этом сегменты превращаются в элементы адресного пространства, а их поля - в переменные. Сегменты размещаются в долговременных запоминающих устройствах, следовательно эта виртуальная машина обладает "одноуровневой" памятью.
   Реализация рассматриваемой виртуальной машины не программной эмуляцией, а традиционным способом - в виде аппаратной машины, расширенной средствами операционной системы возможно в том случае, если архитектура этой машины включает поддержку двух ранее упоминавшихся базовых возможностей: "выделение вершин" графа и "отслеживание связей". Первое может реализоваться в виде разделения адресного пространства на сегменты, второе - использованием тегов. Но возможны и другие варианты. Для машины такой архитектуры рассматриваемая файловая система может являться основой для построения полноценной операционной системы.
  
   9. Особенности виртуальной машины обуславливаются её назначением, состоящем в интерпретации методов. Метод - подпрограмма, предназначенная для обслуживания объектов одного единственного типа. Не более одного за раз. Работающему методу должен быть доступен обрабатываемый объект, список аргументов, полученный при запуске, собственная область литералов, и всё. Доступ ко всем остальным областям памяти, за исключением выделенных для хранения его локальной информации, не нужен. Более того, всё остальное должно быть недоступно - для защиты от ошибок и от поползновений. Наиболее просто и естественно обеспечить это - запускать метод не как подпрограмму, а как самостоятельный процесс, в адресное пространство которого входят только те сегменты, которые должны быть ему доступны. При этом список аргументов и область литералов помещаются в отдельные сегменты.
   Недоступность объектов, на которые в распоряжении процесса есть ссылки, и всех сегментов, на которые у процесса ссылок нет, обеспечивается механизмом "потенциальной адресации", не позволяющим модифицировать указатели, а так же обращаться к корневым сегментам всех объектов, кроме одного единственного, доступного "непосредственно".
   Таким образом, виртуальная машина склонна к порождению множества мелких процессов, способных выполняться параллельно. Кроме случая, когда один процесс ожидает результат работы другого. Порождение процесса происходит при необходимости выполнения любых манипуляций над любым объектом. Оно является результатом акта "посылки сообщения" (другое название запуска метода "по наименованию") и сводится к формированию в отдельном сегменте списка аргументов (собственно "сообщение") и "отправки" его объекту. Отправка сообщения - элементарное действие с точки зрения процесса - целиком выполняется виртуальной машиной. Оно включает анализ объекта-адресата на предмет выявления класса, к которому он относится; анализ объекта, представляющего класс, с целью отыскания в его списке методов пригодного для выполнения заказанного действия; формирование нового процесса и запуск его. В результате отправки сообщения, процесс-отправитель получает указатель на порожденный процесс. Он может быть использован для контроля за состоянием процесса и получения результата его работы, а так же для обмена с ним сообщениями.
   Не трудно заметить, что предложенная модель предусматривает только одноместные операции - каждый метод имеет доступ только к одному единственному объекту. Для реализации двух- и многоместных операций можно использовать обмен сообщений между процессами. Процесс является "активным" объектом, способным самостоятельно реагировать на поступающие ему сообщения. (В отличии от "пассивных" объектов, реакция которых определяется набором методов класса.)
   Другим видом активных объектов являются объекты предназначенные для интерфейса с внешним миром и представляющие процессы, протекающие за пределами вычислительной системы. Они тоже самостоятельно реагирую на сообщения, точнее говоря транслируют сообщение наружу. Если интерфейсный объект представляет некоторое внешнее устройство, то полученное им сообщение преобразуется в управляющие сигналы к этому устройству. Интерфейсный объект, будучи подобающим образом настроен, способен сам посылать сообщения, извещающие об изменениях состояния объектов внешнего мира. Что является заменой системы прерываний.
  
   Заключение.
  
   10. Рассмотрены пути построения "продвинутой" файловой системы, предназначенной для сокращения семантического разрыва между предоставляемой ею моделью представления данных и информационными структурами прикладных задач, имеющими вид произвольного графа. Из произведенного анализа видно, что данная файловая система может служить основой полноценной операционной системы для одно- и многопроцессорных вычислительных машин, снабженных элементами архитектуры, частично или полностью отсутствующими у подавляющего большинства современных ЭВМ. Однако, можно предположить, что эти элементы будут непременной частью архитектур машин следующих поколений. Сейчас же данная система может быть реализована только программной интерпретацией.
   Остался нерассмотренным один аспект - одноуровневая память, присущая виртуальной машине, обслуживающей рассматриваемую файловую систему, не предполагает перенос своих объектов между разными вычислительными установками. Для этих целей должны быть предусмотрены специальные средства. В частности, должно быть введено понятие "контейнер", обобщающее различные физические носители информации. Введен механизм разрыва и соединения связей на границах контейнеров. Найдены способы установления тождественности и не тождественности объектов. Тогда перенос информации между машинами будет сводиться к выделению переносимых объектов в отдельный контейнер, управляемому разрыву связей переносимых объектов с оставшимися и восстановлению этих связей с аналогичными объектами другой файловой системы. Однако проблема переносимости объектов в системах с одноуровневой памятью далеко не проста и ещё ожидает своего решения.
 Ваша оценка:
Связаться с программистом сайта.

Новые книги авторов СИ, вышедшие из печати:
О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

Как попасть в этoт список

Кожевенное мастерство | Сайт "Художники" | Доска об'явлений "Книги"