EA027808B1 - Система управления базой данных - Google Patents

Abstract

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

Description

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

Уровень техники

За прошедшие годы системы управления базами данных (СУБД) прочно вошли в обиход и широко применяются в составе прикладных программных систем для многих отраслей человеческой деятельности. Поначалу системы управления базами данных создавались в расчете на обслуживание многих пользователей, называемых клиентами, одним физическим сервером. Это обусловлено относительной простотой, с которой в одномашинной системе можно обеспечить транзакционность базы данных, удовлетворив четыре стандартных требования к транзакционной системе: атомарность, согласованность, изолированность и надежность операций с данными (англ. ЛСГО - ЛЮписПу. СопЧЧспсу. Εοΐαΐίοη. ИигаЬййу).

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

Известен ряд подходов к созданию СУБД с ЛСГО-транзакциями в одномашинном варианте.

Ранние подходы основаны на использовании различных средств блокировки доступа к данным: исключительные и неисключительные блокировки, блокировки операций чтения, блокировки операций записи, блокировки с множественным конкурентным чтением и исключительной записью, причем блокировки могут применяться к индивидуальным объектам или записям, а также к странице памяти или диапазону записей.

Поздние подходы основаны на управлении конкурентным доступом с помощью многоверсионности (англ. МУСС - МиШУегЧоп Сопсиггепсу Соп1то1), суть которых заключается в использовании временных меток или увеличивающихся значений идентификаторов транзакций, ассоциированных с последовательными версиями каждой записи. Каждой транзакции разрешено читать новейшую версию из множества записей, для которых временная метка или идентификатор меньше временной метки или идентификатора читающей транзакции. Таким образом, каждому клиенту на время каждой транзакции предоставляется логический снимок базы данных, обладающий тем свойством, что вносимые клиентом изменения в базу данных невидимы другим клиентам до момента фиксации транзакции. Этот способ управления эффективнее блокировок с точки зрения накладных расходов, он позволяет добиться того, что читающие транзакции не блокируют пишущих, а пишущие транзакции не блокируют читающих.

В последнее время из-за развития глобальной сети Интернет возникла устойчивая тенденция увеличения количества обслуживаемых клиентов и объемов данных до предельных значений, с которыми может справиться один сервер. Кроме того, возникло новое требование обеспечения высокой готовности баз данных. Чтобы справиться с растущими требованиями, используются различные варианты вертикального и горизонтального масштабирования. Вертикальное масштабирование предполагает повышение производительности системы путем увеличения производительности компонентов одной машины, например, через увеличение числа процессоров, объема оперативной памяти, пропускной способности контроллеров ввода-вывода и числа задействованных параллельно дисковых устройств хранения. Г оризонтальное масштабирование предполагает повышение производительности многомашинной системы путем увеличения количества машин, называемых узлами, выполняющих одну и ту же функцию. Горизонтальное масштабирование удобнее и эффективнее вертикального масштабирования, а также выгоднее с экономической точки зрения, позволяя экстенсивно увеличивать производительность системы добавлением дешевых узлов потребительского уровня. Однако горизонтальное масштабирование требует значительно более сложного программного обеспечения.

В получивших широкое распространение реляционных СУБД, часто применяется кластерный подход, когда логический сервер состоит из нескольких узлов, каждый узел обладает процессором и оперативной памятью, а все узлы разделяют общий избыточный массив независимых дисков, соединенных с узлами высокопроизводительным контроллером ввода-вывода. При таком подходе все узлы разделяют общие данные во внешней памяти, через которую происходит синхронизация состояний узлов. Благодаря общей внешней памяти в кластере узлов обеспечивается единое управление временем и логическое упорядочивание всех транзакций для всех узлов. Положительной стороной этого подхода является обеспечение ЛСГО-транзакций, но он является экономически затратным и имеет низкий потолок масштабирования, особенно в отношении роста количества клиентов базы данных.

Тиражирование данных (англ. герПсаБоп) между несколькими серверами СУБД является другим подходом к масштабированию СУБД. При этом один узел считается главным и содержит основную ко- 1 027808 пию данных, с которой синхронизируются копии данных на других узлах. При выходе из строя главного узла его функция передается другому узлу. Примером этого подхода служит СУБД, состоящая из пары узлов, где один узел выполняет редко возникающие транзакции записи, а другой узел выполняет часто возникающие транзакции чтения. Тиражирование данных происходит в одном направлении, а узлы выполняют разные функции. Очевидными проблемами этого подхода являются недостаточные универсальность и масштабируемость, а также нарушение согласованности данных - клиент при чтении продолжает получать устаревшие данные до тех пор, пока не выполнится тиражирование обновленных данных.

Экономически целесообразным выглядит подход, основанный на федерализации данных, когда федеративная база данных создается как надстройка-медиатор, интегрирующая несколько отдельных баз данных, которые расположены на соединенных вычислительной сетью независимых узлах. Медиатор отвечает за создание общего логического представления (модели) данных и изолирует клиентов от распределенной физической природы данных. Положительной стороной этого подхода является возможность использования готовых одномашинных транзакционных СУБД для реализации баз данных отдельных узлов. Однако исключительно высокая сложность медиатора, необходимость использования дополнительного координатора транзакций с медленным и неустойчивым к отказам координатора двухфазным протоколом фиксации, перегруженность вычислительной сети, которые становятся особенно заметными с ростом количества клиентов и размера базы данных, делают указанный подход ресурсоемким и плохо масштабируемым.

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

Секционирование (англ. ратйютид) - еще один подход, применяемый для создания распределенных систем управления базами данных. Он основан на разделении логической базы данных на отдельные части, хранимые на нескольких физических узлах. Секционирование может быть горизонтальным, когда в реляционной базе данных разделение таблиц происходит по строкам, или вертикальным, когда разделение таблиц происходит по колонкам.

Одним из видов горизонтального секционирования является шардинг (от англ. кйатбтд), применяемый также к объектным и другим системам управления базами данных не реляционного типа. Суть шардинга заключается в распределении объектов логической базы данных по физическим базам данных на узлах в соответствии со значением ключа объекта или значением некоторой хеш-функции от ключа объекта. В качестве примера можно привести разделение всех почтовых адресов на непересекающиеся диапазоны значений почтового индекса и распределение этих диапазонов вместе с включенными в них адресами среди узлов. Таким образом, географически близкие адреса с большой вероятностью попадут на один и тот же узел. Когда нужно избежать диспропорций между количеством объектов на узлах, используют хеш-функцию, например, функция суммирования всех цифр номера паспорта с делением результата на количество узлов позволяет получить номер целевого узла для каждого объекта и распределить записи с паспортными данными равномерно среди всех узлов.

Подход на основе шардинга или секционирования базы данных имеет ряд недостатков. Среди них необходимость реализации двухфазного протокола фиксации транзакций, который, как известно, является медленным и неустойчивым к отказам координатора, а также нарушение требований ЛСГО для транзакций, охватывающих объекты на нескольких узлах. Труднопреодолимой проблемой этого подхода становится упорядочивание транзакций разных клиентов, пришедших одновременно на разные узлы и охватывающие одни и те же данные, которые распределены между несколькими узлами. Упорядочивание транзакций с помощью временных меток требует согласования системных часов всех узлов с уровнем точности, который на практике оказывается не достижим. Именно поэтому в этом подходе трудно реализовать управление конкурентным доступом с помощью многоверсионности. Малопригодными являются также блокировки, приводящие в распределенной системе к бесконечным ожиданиям. Кроме того, в этом подходе труднореализуемой или недопустимо медленной становится операция соединения таблиц записей (операция ΙΟΙΝ реляционной базы данных). В терминах объектных баз данных трудно становится реализовать запрос множества главных и подчиненных объектов, расположенных на разных узлах. Особенно в отношении запросов с условием попадания значений атрибутов записей или объектов в заданный диапазон.

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

Еще один подход основан на использовании распределенного транзакционного кэша. Суть его заключается в том, что все объекты базы данных, включая каталоги, записи таблиц, фрагменты индексов, а также другие данные и метаданные (т.н. атомы), распределяются в нескольких копиях среди множества транзакционных узлов, которые выполняют роль кэш-памяти. При этом как минимум один из узлов кэшем не является (т.н. архивный узел), а обеспечивает постоянное хранение базы данных. Операции редактирования объектов затрагивают архивный узел и все транзакционные узлы, где к моменту редактирования оказались кэш-копии объектов. Для этого с каждым объектом ассоциирован список ссылок на

- 2 027808 узлы, где имеются его копии. Любой из транзакционных узлов может выполнить запрос пользователя, обеспечивая перетекание на него всех используемых для выполнения запроса данных. Копирование объектов на транзакционные узлы и согласование их копий выполняются по необходимости. Для обеспечения согласованности данных каждый узел ведет счетчик последней фиксации транзакции. Этот подход наиболее близок предлагаемому изобретению по достигнутому техническому результату, поскольку позволяет реализовать эластично масштабируемую систему управления базами данных с поддержкой АСГО-транзакций, в которой узлы могут быть даже географически распределены. Однако необходимость иметь архивный узел, на котором база данных помещается целиком, ограничивает возможности масштабирования и универсальность данного подхода. По сути проблема эффективного хранения и быстрого редактирования базы данных большого размера перекладывается на архивный узел. Труднопреодолимой проблемой этого подхода являются также полнотекстовая индексация и поиск по ключевым словам, когда объем индексных данных оказывается слишком большим для одного узла.

В известных подходах часто выполняется разделение между логической и физической схемами базы данных, когда логическая схема, используемая для проектирования базы данных, транслируется в физическую схему, используемую для реализации базы данных с помощью конкретной СУБД. Логическая схема оперирует высокоуровневыми понятиями, например, для ЕК-модели (от англ. ΕηΙίΙνКе1айопвЫр шойе1) - это сущности, атрибуты сущностей, связи между сущностями. Физическая схема оперирует низкоуровневыми понятиями, например, для реляционной базы данных - это таблицы, поля, индексы. Причем в известных подходах понятие связь между сущностями не является концепцией интерфейса с СУБД, а лишь моделируется тем или иным способом, что не позволяет эффективно управлять прямыми и обратными связями между распределенными среди узлов объектами и автоматически выполнять необходимую денормализацию данных для сокращения внутренней коммуникации между узлами и быстрого выполнения запросов.

Подводя итог, можно констатировать, что известные подходы отвечают многим, но не всем требованиям, предъявляемым к современным базам данных. В действительности требуется система управления базами данных, обеспечивающая хорошее горизонтальное масштабирование при росте количества пользователей и объемов данных, при этом поддерживающая шардинг данных, когда функции постоянного хранения данных распределены между узлами, т.е. ни один из узлов не содержит целиком всей копии базы данных. Такая система должна обеспечивать атомарность, согласованность, изолированность и надежность транзакций, т.е. удовлетворять АСГО-требованиям. Система должна быть децентрализованной и обеспечивать высокую готовность и отказоустойчивость за счет средств резервирования и хранения избыточных копий объектов и метаданных на нескольких узлах. В дополнение к этому такая система управления базами данных должна предоставлять пользователю средства работы со структурированными данными (объектами), двоичными данными большого размера (файлами), а также средства высокопроизводительного полнотекстового поиска данных по ключевым словам.

Сущность изобретения

Задачей изобретения является получение многопользовательской распределенной системы обработки данных, в которой ни один из узлов не содержит полного множества всех объектов базы данных.

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

Еще одной задачей изобретения является получение многопользовательской распределенной системы обработки данных, обеспечивающей высокую степень готовности.

Еще одной задачей изобретения является получение многопользовательской распределенной системы обработки данных, обеспечивающей высокую степень отказоустойчивости.

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

В соответствии с одним из аспектов настоящего изобретения все перечисленные задачи решаются за счет горизонтального секционирования данных путем распределения (шардинга) и постоянного хранения объектов базы данных на нескольких узлах вычислительной сети с возможностью пересечения подмножеств объектов любых двух узлов, когда ни один узел не обязан хранить полное множество всех объектов базы данных, а также за счет управления прямыми и обратными логическими ссылками между объектами, когда для каждого объекта создается и поддерживается актуальным логический список обратных ссылок на объекты, содержащие прямые ссылки на данный объект, на хранящем объект узле хранятся ключи всех объектов, ссылающихся на данный объект, причем с каждым из этих ключей ассоциируется список обратных ссылок на объекты, расположенные на данном узле, а прямые ссылки на объекты, расположенные на других узлах, заменяются ссылками на узлы, с которых целевые объекты можно получить по ключу ссылающегося на них объекта, а также за счет упорядочивания объектов по значениям одного или нескольких полей и распределения копий объектов среди нескольких узлов базы данных таким образом, что все множество значений полей, участвующих в упорядочивании, делится на диапазоны, и каждому диапазону ставится в соответствие узел базы данных, где хранятся копии объектов, включенные при упорядочивании в этот диапазон, а также за счет передачи между узлами базы дан- 3 027808 ных сообщений с командами, позволяющими сохранять и извлекать объекты по запросам клиентов с проверкой условия запроса на тех узлах, где хранятся копии объектов, без передачи всех требуемых для проверки условия запроса индексных данных и копий объектов на один узел, координирующий выполнение запроса клиента. В основе эффективного горизонтального масштабирования системы управления базой данных лежит способ выдачи объектам базы данных уникальных значений первичных ключей, в котором уникальные значения первичных ключей выдаются каждым узлом независимо от других узлов и без обращения к третьей стороне, уникальные значения первичных ключей распределяются каждым узлом во всем диапазоне возможных значений первичных ключей равномерно небольшими группами. Для обеспечения согласованности данных каждый узел содержит увеличивающийся счетчик логического времени, используемый для выдачи меток времени, причем для любых двух значений счетчика времени определено отношение строгого порядка, счетчик времени увеличивается перед каждым внутренним событием узла, каждый узел передает текущее значение счетчика времени другим узлам при отправке любых сообщений, каждый узел при приеме сообщения от другого узла увеличивает свой счетчик времени так, чтобы он был больше наибольшего из текущего значения и принятого с сообщением значения счетчика времени, значение счетчика времени возвращается в каждом ответе на запрос клиента базы данных, хранится клиентом во время работы с базой данных и передается вместе с каждым запросом для согласованного доступа к данным.

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

Перечень чертежей

На фиг. 1 схематически представлен один из вариантов топологии СУБД.

На фиг. 2 представлена схема аппаратных компонентов одного узла.

На фиг. 3 показана схема программных компонентов узла в разрезе ролей координатора и участника транзакции.

На фиг. 4 показан пример графа объектов, которые содержат ссылки друг на друга и распределены некоторым образом среди узлов базы данных.

На фиг. 5 показана детализированная структура объектов и ссылок для примера из фиг. 4.

На фиг. 6 показана детализированная структура ревизий объектов для примера из фиг. 5.

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

На фиг. 8 показана блок-схема, помогающая понять способ, с помощью которого выполняются транзакции извлечения объектов из базы данных.

На фиг. 9 показана блок-схема, помогающая понять способ, с помощью которого выполняются транзакции сохранения объектов в базу данных.

- 4 027808

На фиг. 10 показана блок-схема, дополняющая фиг. 9 и помогающая понять способ, с помощью которого выполняется сохранение объектов на узле-участнике в фрагмент базы данных.

На фиг. 11 показана первая часть блок-схемы, помогающей понять способ, с помощью которого выполняются транзакции поиска объектов в базе данных.

На фиг. 12 показана вторая часть блок-схемы, помогающей понять способ, с помощью которого выполняются транзакции поиска объектов в базе данных.

На фиг. 13 представлен пример некоторой исходной системы управления базой данных, масштабируемой различными способами до вариантов, показанных на фиг. 14.

На фиг. 14 показаны варианты масштабирования системы управления базой данных из фиг. 13. Сведения, подтверждающие возможность осуществления изобретения

Сведения, подтверждающие возможность реализации изобретения, изложены далее в разделах Аппаратно-программное устройство, Структуры данных, Методы обработки данных.

Аппаратно-программное устройство.

Частью данного изобретения является изображенный на фиг. 1 вариант многопользовательской масштабируемой распределенной транзакционной системы управления базами данных 18. СУБД 18 включает в себя некоторое множество узлов от N1 до N8, взаимодействующих друг с другом на равноправной основе через вычислительную сеть 19. Так, например, узел N1 может напрямую обмениваться сетевыми сообщениями с узлами от N2 до N8. Обмен сообщениями происходит в асинхронном режиме, чтобы обеспечить максимальную пропускную способность системы при обработке запросов клиентов.

Более детально архитектуру системы раскрывает фиг. 2, на которой показан состав аппаратных компонентов типичного узла 20. Согласно фиг. 2 типичный узел 20 содержит центральный процессор 25, который общается с одним или несколькими клиентами 21 через сетевой интерфейс 27 и вычислительную сеть 22. Одновременно узел 20 общается с другими такими же узлами через сетевой интерфейс 28 и вычислительную сеть 24. Центральный процессор 25 также взаимодействует с оперативной памятью 26, в которой хранится копия программы управления базой данных 29, реализующая предпочтительный вариант данного изобретения. При работе этой программы обеспечивается оперативное хранение объектов базы данных 30, выполняются запросы клиентов, обеспечивается коммуникация с такими же программами других узлов и решаются сопутствующие задачи. Центральный процессор 25 дополнительно взаимодействует через устройство ввода-вывода 31 с устройством энергонезависимой постоянной памяти 32, например с устройством накопления данных на жестких дисках. Устройство постоянной памяти 32 хранит последовательно записанные (т.н. сериализованные) данные объектов 33 и двоичные файлы 34 базы данных.

Обычно вычислительные сети 22 и 24 представляют собой физические подсети вычислительной сети 19 или логические маршруты внутри вычислительной сети 19. Разделение вычислительной сети 19 на независимые подсети обычно выполняется по соображениям безопасности и производительности, хотя и не является обязательным. Вычислительная сеть 22 должна обеспечивать высокую пропускную способность и допускает относительно большие времена задержки при передаче сообщений в силу удаленности клиентов. Вычислительная сеть 22 обычно использует технологии глобальной сети Интернет и содержит устройство балансировки запросов 23, которое маршрутизирует и равномерно распределяет запросы клиентов среди всех узлов, подключенных к сети 22. Вычислительная сеть узлов 24 должна обеспечивать высокую пропускную способность и малое время задержки сообщений в сети при межузловой коммуникации и обычно основана на технологиях локальных сетей ЕШете! и оптоволоконных линий связи.

В качестве протокола передачи сообщений вычислительные сети 22 и 24 могут использовать протокол ТСР (англ. Тгапвт188юп Οοηίτοί Рго1оео1 - протокол управления передачей), являющийся протоколом транспортного уровня сети Интернет и обеспечивающий надежную передачу потока данных через установленное соединение. Кроме того, в качестве протокола передачи сообщений в сетях 22 и 24 могут использоваться протоколы прикладного уровня, например протокол НТТР (англ. НурегТех! ТгапзГег Рго1оео1 - протокол передачи гипертекста), который является основным протоколом всемирной паутины (т.н. веб), работает поверх протокола ТСР, обеспечивает диалоговое взаимодействие в режиме запросответ, имеет средства типизации данных и задания контекстных данных (т.н. куки), возможности переадресации запросов и их мультиплексирования в рамках одного соединения, а также позволяет легко преодолевать сетевые экраны. Может также использоваться протокол прикладного уровня §ОАР (англ. §1тр1е ОЬ)ес1 Асееве Рго1оео1 - простой протокол доступа к объектам), используемый веб-службами для обмена структурированными сообщениями и работающий поверх протокола НТТР, а также другие подобные протоколы. Рассматриваемый вариант СУБД поддерживает в качестве базового протокола передачи сообщений несколько протоколов, в частности протоколы ТСР и НТТР, выбираемые через параметры конфигурации системы, причем протокол ТСР предпочтительно используется для взаимодействия между узлами (из соображений производительности), а протокол НТТР - для взаимодействия с клиентами 21 (с целью преодоления сетевых экранов и обеспечения доступа к базе данных веб-клиентов).

В предпочтительном варианте осуществления изобретения используется объектно-ориентированная парадигма программирования (ООП). Согласно парадигме ООП объекты представляют собой динамически создаваемые экземпляры классов, объединяющие в себе данные (т.н. свойства) и подпрограммы их

- 5 027808 обработки (т.н. методы). Классы являются описаниями динамических модулей, экземпляры которых объекты -можно создавать в неограниченном количестве в отличие от статических модулей структурного программирования. Классы как типы данных могут расширять другие классы (т.н. наследование) и переопределять работу методов за счет использования механизма косвенного вызова подпрограмм (т.н. полиморфизм). Специалистам в данной области техники должно быть очевидным, что изобретение может быть реализовано как с использованием, так и без использования средств ООП.

На фиг. 3 изображен состав программных компонентов типичного узла 20, который может выступать в двух ролях: 1) координатор транзакции, 2) участник транзакции. В рассматриваемом варианте осуществления изобретения любой узел способен выполнять как одну из ролей, так и одновременно обе указанные роли. Согласно фиг. 3 узел 40 выступает в качестве координатора транзакций, предоставляя клиентам интерфейс и обеспечивая доступ к базе данных, а узел 60 выступает в качестве участника транзакций, обеспечивая оперативное и постоянное хранение данных. Таким образом, узлы 40 и 60 функционально идентичны, а при работе в той или иной роли в них задействуется тот или иной набор функциональных модулей. Модули и связи, которые задействуются, отмечены непрерывной линией, а модули и связи, которые не задействуются, - пунктирной линией.

Узел-координатор транзакций 40 с помощью сетевой службы приема клиентских запросов 41 принимает запросы от клиентов базы данных 21 через вычислительную сеть 22.

Сетевая служба приема клиентских запросов 41 представляет собой интерфейс связи клиента с СУБД и является веб-службой. В предпочтительном варианте осуществления изобретения служба 41 основана на протоколе НТТР. Служба 41 выполняет две задачи: десериализацию - последовательное чтение данных клиента из входящего сетевого потока и восстановление из этих данных объектов запроса; сериализацию - преобразование объектов, полученных в результате выполнения запроса, в поток последовательных данных с передачей их через сеть клиенту. В качестве формата данных при сериализации и десериализации обычно используется текст на некотором языке разметки документов с простым формальным синтаксисом, например на языке ХМЬ (от англ. ехЮгМЫе Магкир Ьапдиаде - расширяемый язык разметки).

Сетевая служба приема клиентских запросов 41 передает десериализованные запросы ядру выполнения клиентских запросов 42, преобразующему команды более высокого уровня клиента в последовательность команд более низкого уровня системы. В общих чертах, ядро выполнения клиентских запросов обеспечивает синтаксический разбор, компиляцию и оптимизацию клиентских запросов, а затем выполнение команд управления над другими объектами системы. Команды выполняются над такими объектами, как менеджер системных транзакций 43, список баз данных 44, фрагмент базы данных 45, канал связи с другим узлом 54, а также над подчиненными им объектами.

Клиентские запросы могут быть представлены в виде объектов некоторого программного интерфейса СУБД или в виде текстовых описаний на некотором языке, таком, например, как язык ЗОБ (от англ. 81гис1игеб Онегу Ьапдиаде - язык структурированных запросов). Язык ЗОБ применяется в системах управления реляционными базами данных.

В рассматриваемом варианте осуществления изобретения предложены следующие виды запросов клиента к базе данных: Сохранить объекты, Извлечь объекты, Найти и извлечь объекты по условию. За каждым видом запроса стоят соответствующие классы, описывающие объект запроса и объект ответа, передаваемые между клиентом 21 и ядром выполнения запросов 42.

Согласно фиг. 3 фрагменты базы данных 45 и 65 хранят и обслуживают подмножества данных логической базы данных. Таких фрагментов на одном узле может быть много, поскольку в рассматриваемом предпочтительном варианте реализации изобретения узел поддерживает работу одновременно с несколькими независимыми базами данных в рамках одной и той же инфраструктуры узлов. Фрагменты всех независимых баз данных одного узла собраны в списки 44 и 64. Каждая база данных идентифицируется именем, а списки баз данных 44 и 64 обеспечивают доступ к нужному фрагменту по имени базы данных.

Ядро выполнения клиентских запросов 42 на узле-координаторе транзакций 40 использует лишь те модули фрагмента базы данных 45, которые необходимы для координации транзакций, а именно конфигурацию базы данных 46, менеджер транзакций 48 и генератор ключей 50. Хранение данных обеспечивают фрагменты базы данных на узлах-участниках, например фрагмент 65 на узле-участнике 60. Во фрагменте базы данных 65 задействуются лишь те модули, которые необходимы для обеспечения хранения данных и транзакционной работы с ними, а именно конфигурация базы данных 66, менеджер транзакций 68, первичный индекс 67, вторичные индексы 69, ссылочные индексы 71, постоянное хранилище 72 и файловое хранилище 73.

Для выполнения клиентского запроса ядро 42 превращает клиентский запрос в множество внутренних запросов к фрагментам на других узлах, где находятся запрашиваемые данные. Внутренние запросы передаются ядру выполнения внутренних запросов 74 каждого вовлеченного в транзакцию узлаучастника 60 через логический канал связи 55 узла-координатора и через соответствующий ему логический канал связи 75 узла-участника. Двунаправленный логический канал связи создается между каждой парой узлов. Он обеспечивает прозрачное взаимодействие ядра выполнения клиентских запросов 42 и

- 6 027808 ядра выполнения внутренних запросов 74 с фрагментом базы данных на другом узле так, будто он расположен на том же узле, что и ядро запросов.

Передача сообщений с внутренними запросами и прием сообщений с ответами выполняется каналом связи с помощью очередей исходящих и входящих сообщений. Очередь исходящих сообщений 56 обслуживается сетевой службой отправки сообщений 58, которая изымает запросы из очереди и передает их со своего узла, в частности узла 40, сетевой службе приема сообщений 79 на узле-участнике 60. Сетевая служба приема сообщений 79 ставит входящие запросы в очередь входящих сообщений 77. Ядро выполнения внутренних запросов 74 изымает запросы из этой очереди и выполняет их. Результирующие ответы на внутренние запросы попадают в очередь исходящих сообщений 76. Сетевая служба отправки сообщений 78 изымает исходящие ответы из этой очереди и передает их с узла-участника 60 на узелкоординатор 40, где они попадают сетевой службе приема сообщений 59, которая ставит ответы в очередь входящих сообщений. Входящие ответы ассоциируются каналом связи 55 с исходящими запросами и возвращаются ядру выполнения клиентских запросов 42.

Чтобы сообщение с ответом можно было сопоставить сообщению с запросом, каждое сообщение содержит идентификатор пары запрос-ответ. Идентификатор выдается сообщению с запросом, путешествует вместе с ним на вызываемый узел, затем копируется из сообщения с запросом в сообщение с ответом и возвращается на вызывающий узел.

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

Согласно фиг. 3 в рассматриваемом варианте реализации изобретения фрагмент базы данных узла содержит следующие модули: конфигурация базы данных, менеджер транзакций, генератор ключей, первичный индекс, вторичные индексы, ссылочные индексы, файловое хранилище, постоянное хранилище. Перечисленные модули рассмотрены ниже.

Конфигурация базы данных 46 (на узле-координаторе) и 66 (на узле-участнике) содержит объекты, описывающие структуру базы данных. В рассматриваемом варианте реализации изобретения конфигурация базы данных включает определения типов объектов, определения способов упорядочивания объектов по значениям одного или нескольких полей (т.н. индексы базы данных), список узлов размещения базы данных, карты размещения индексов среди узлов, карты размещения файлов среди узлов, принимаемый для базы данных уровень резервирования. Определение типа объектов (т.н. сущности базы данных) состоит из определений скалярных и ссылочных полей объектов этого типа. Для ссылочных полей (т.н. отношений) указываются соответствующие им в адресуемых объектах поля с обратными ссылками. Значения обратных ссылок отслеживаются и, в случае необходимости, автоматически добавляются, удаляются или корректируются системой управления базой данных при установке пользователем прямых ссылок. Ссылочные поля могут быть списковыми (наиболее распространенный случай) и одиночными. Списковое ссылочное поле содержит множество ссылок, одиночное ссылочное поле содержит одну ссылку. Обратной ссылкой для любого ссылочного поля может быть одиночное или списковое поле в адресуемом объекте. Способы упорядочивания объектов по значениям одного или нескольких полей в рассматриваемом варианте реализации изобретения классифицированы следующим образом: первичный индекс, вторичные индексы, ссылочные индексы. Все виды индексов и карты размещения индексов среди узлов рассмотрены ниже.

Согласно фиг. 3 фрагмент базы данных узла содержит менеджер транзакций. Менеджер транзакций 48 (на узле-координаторе) и 68 (на узле-участнике) обеспечивает управление распределенными транзакциями. Механизм распределенных транзакций подробно рассмотрен ниже в описании изобретения. Менеджер транзакций обеспечивает средства создания, старта, фиксации и отката транзакций. Он включает в себя список текущих транзакций, реестр активных клиентов, генератор временных меток транзакций, а также сборщик мусора, обеспечивающий удаление устаревших ревизий объектов и объектов состояния транзакций.

Кроме набора менеджеров транзакций - по одному на каждый фрагмент базы данных - узел содержит менеджер системных транзакций, показанный на фиг. 3 блоками 43 и 63 в узлах 40 и 60 соответственно. Менеджер системных транзакций обеспечивает атомарное и согласованное выполнение административных запросов клиента, в частности запросов создания, удаления и конфигурирования баз данных. Функционально менеджер системных транзакций ничем не отличается от менеджера транзакций фрагмента базы данных, поскольку является экземпляром их общего класса. Отличие заключается в том, что системные транзакции всегда охватывают все узлы СУБД, причем как узел-координатор транзакции, так и узлы-участники транзакции.

Генератор ключей 50 используется узлом-координатором для создания уникальных первичных ключей объектов базы данных. В рассматриваемом варианте реализации изобретения первичный ключ представляет собой 64-битное целое число. Чтобы ключи, выдаваемые разными узлами, не повторялись,

- 7 027808 часть битов в значении ключа служит для кодирования номера узла, выдавшего ключ. Способ выдачи первичных ключей приведен ниже в описании структур данных настоящего изобретения.

Первичный индекс 67 на узле-участнике представляет собой фрагмент словаря, отображающего первичные ключи объектов в ячейки хранения объектов. Добавление в словарь нового ключа и соответствующей ему ячейки хранения объекта происходит на узле атомарно для клиентских запросов. В рассматриваемом варианте реализации изобретения атомарность обеспечивается за счет механизма блокировок. Ячейка хранения объекта создается один раз при добавлении в словарь нового первичного ключа и при редактировании объекта не пересоздается. Она хранит список ревизий объекта и использует механизм МУСС для управлении конкурентным доступом с помощью многоверсионности. Первичный индекс распределяется среди узлов СУБД на основании заданной в конфигурации базы данных 46 (на узлекоординаторе) и 66 (на узле-участнике) карты размещения первичного индекса. Карта размещения первичного индекса используется узлом-координатором для определения узлов-участников транзакции. В некотором варианте реализации изобретения карта размещения первичного индекса может быть построена следующим образом. Множество возможных значений первичного ключа объекта разбито на непрерывные диапазоны. Каждому диапазону поставлен в соответствие список узлов, на которых хранятся копии объектов с ключами из данного диапазона. Наличие избыточных копий объектов необходимо для обеспечения высокой степени готовности и устойчивости системы к отказам узлов. Карта размещения первичного индекса применяется для доступа к объекту по его ключу. По значению ключа объекта определяется номер диапазона первичного индекса. По номеру диапазона выбирается список узлов, где хранятся копии объекта. Из списка узлов выбирается любой узел для чтения объекта. На выбранном узле по значению ключа в первичном индексе отыскивается ячейка хранения объекта и из нее, в соответствии с временной меткой клиента, выбирается ревизия объекта. Более подробно структура карты размещения первичного индекса и способ ее применения приведены ниже в описании настоящего изобретения.

Вторичные индексы 69 на узле-участнике - это фрагменты вторичных индексов в данном фрагменте базы данных. У каждого вторичного индекса существует идентификатор, назначаемый в конфигурации базы данных 46 (на узле-координаторе) и 66 (на узле-участнике) и используемый в запросах клиентов. По идентификатору выбирается требуемый вторичный индекс. Вторичный индекс представляет собой упорядоченный по значениям одного или нескольких полей набор объектов. Поля, по которым происходит упорядочивание, образуют вторичный ключ. Если в любой заданный момент времени вторичному ключу соответствует не более одного объекта, вторичный ключ считается уникальным. Неуникальному вторичному ключу может соответствовать несколько объектов. Вторичный индекс распределяется среди узлов СУБД на основании заданной в конфигурации базы данных 46 (на узле-координаторе) и 66 (на узле-участнике) карты размещения вторичного индекса. Карта размещения вторичного индекса аналогична карте размещения первичного индекса с той лишь разницей, что разбиваемые на диапазоны ключи вторичного индекса могут состоять из нескольких полей различных типов. Карта размещения вторичного индекса может быть составлена так, что на одном узле окажутся несколько диапазонов одного и того же вторичного индекса. Все диапазоны вторичного индекса, хранимые на одном узле, составляют фрагмент вторичного индекса. Физически каждый фрагмент вторичного индекса реализуется через хорошо известные специалистам в данной области структуры данных с характерным набором операций - упорядоченный динамический массив и/или двоичное дерево. Для обеспечения многоверсионного доступа к объектам в настоящей реализации изобретения во вторичный индекс включаются ревизии объектов вместе с ячейками хранения объектов. Уникальному вторичному ключу в такой структуре данных могут соответствовать несколько ревизий одного и того же объекта. При этом уникальность вторичного ключа обеспечивается для любой заданной временной метки на уровне ячеек хранения объектов.

Ссылочные индексы 71 на узле-участнике - это логические упорядочивания ссылок в списковых ссылочных полях объектов. Упорядочивание выполняется в соответствии со значениями одного или нескольких скалярных полей объектов, адресуемых ссылками. Например, представим, что в базе данных некоторой социальной сети объект класса Пользователь содержит списковое ссылочное поле Группы пользователя. Ссылочный индекс позволяет упорядочить в этом поле ссылки на объекты класса Группа по значению поля Название группы. В терминах реляционных баз данных ссылочный индекс соответствует вторичному индексу для таблицы отношений между сущностями. У каждого ссылочного индекса существует идентификатор, назначаемый в конфигурации базы данных 46 (на узле-координаторе) и 66 (на узле-участнике) и используемый в запросах клиентов.

Постоянное хранилище 72 на узле-участнике представляет собой средство сохранения (сериализации) объектов фрагмента базы данных в один или несколько файлов на внешний носитель данных, например на жесткий диск, а также средство загрузки (десериализации) объектов из этих файлов в оперативную память. Сохранение объектов в постоянное хранилище происходит периодически. Момент сохранения может быть выбран разным: фиксация транзакции, сборка мусора в базе данных, явный запрос пользователя на сохранение объектов в постоянном хранилище. Загрузка объектов из постоянного хранилища выполняется во время запуска узла СУБД, а также при перезагрузке узла, что эквивалентно сценарию запуска узла. К постоянному хранилищу предъявляются требования быстрой последовательной

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

Файловое хранилище 73 на узле-участнике обеспечивает хранение данных типа ВЬОВ (от англ. Βίпагу Ьагде ОВ)ес1 - двоичный большой объект) в файловой системе на внешних носителях узлов СУБД, например на жестких дисках. В настоящем изобретении набор данных типа ВЬОВ представляется в виде особого файлового объекта базы данных. Файловые объекты, как и обычные объекты, могут иметь скалярные и ссылочные поля для хранения данных, а также принимать участие в транзакциях наравне с обычными объектами. Одним из предопределенных скалярных полей файлового объекта является имя логического файла в базе данных. По этому полю построен вторичный индекс с уникальным ключом, чтобы можно было выполнять поиск файловых объектов по имени. В отличие от других объектов каждый файловый объект имеет логическое поле для хранения своего набора данных типа ВЬОВ. Набор данных хранится не в оперативной памяти, а на внешнем носителе, обычно на файловой системе. С набором данных файлового объекта предусмотрены следующие операции: Чтение целиком, Чтение блока, Добавление блока в конец, Перезапись целиком. Различные реализации изобретения могут дополнительно поддерживать операцию Перезапись блока, но это серьезно усложняет управление ревизиями файлового объекта и замедляет совместный доступ к набору данных со стороны разных клиентов из-за необходимости использовать дополнительные блокировки.

Набор данных типа ВЬОВ каждого файлового объекта (данные файла) распределяется среди узлов СУБД на основании заданного в конфигурации базы данных 46 (на узле-координаторе) и 66 (на узлеучастнике) правила размещения файлов в файловом хранилище. Правило определяет набор узлов, среди которых происходит размещение файлов, и размер блока непрерывной записи на один узел. Запись файловых данных на узлы из набора происходит блоками по кругу с учетом заданного в конфигурации базы данных уровня резервирования (если он больше нуля, один и тот же блок данных попадает на несколько смежных узлов). В момент записи строится или обновляется карта размещения файла. Она сохраняется в одном из внутренних системных полей ревизии файлового объекта. Карта размещения файла используется для чтения данных файла. По ней для любого участка файла можно определить местоположение блоков этого участка на узлах базы данных.

Структуры данных.

На фиг. 4 изображен пример графа объектов. Объекты содержат ссылки друг на друга и распределены некоторым образом среди узлов базы данных. В примере предполагается, что объекты принадлежат двум разным классам: и (от англ. Икег - пользователь) и С (от англ. Сгоир - группа) и имеют соответственно обозначения И1, И2, ИЗ и С1, С2, С3. Объекты класса и ссылаются на объекты класса С. Так объект И1 ссылается на объекты С1 и С2, объект И2 ссылается на объекты С2 и СЗ, а объект ИЗ ссылается на объекты С1 и СЗ. Эти ссылки с точки зрения объектов класса И считаются прямыми. Они показаны на фиг. 4 сплошными линиями. Прямым ссылкам соответствуют обратные ссылки: из объектов С1 и С2 на объект И1, из объектов С2 и СЗ на объект И2 и из объектов С1 и СЗ на объект ИЗ. Обратные ссылки показаны на фиг. 4 пунктирными линиями. Отметим, что для объектов класса С прямые ссылки показаны пунктирными линиями, а обратные ссылки - сплошными линиями. В примере предполагается, что согласно карты размещения первичного индекса объекты И1 и И2 оказались на узле N1, объекты С1 и С2 оказались на узле N2, а объекты ИЗ и СЗ оказались на узле №. При этом ссылки между объектами ИЗ и СЗ связывают объекты одного узла, а остальные ссылки связывают объекты разных узлов.

На фиг. 5 для вышеуказанного примера показан детализированный способ хранения объектов и ссылок. На узле N1 хранятся объекты И1 и И2, на узле N2 хранятся объекты С1 и С2, на узле № хранятся объекты ИЗ и СЗ. Названные объекты распределены среди узлов в соответствии со значением своего первичного ключа и картой размещения первичного индекса. Объекты И1, И2, ИЗ, С1, С2, СЗ хранят значения скалярных полей. В каждом объекте ссылки на другие объекты заменены ссылками на узлы, с которых другие объекты можно получить по первичному ключу ссылающегося на них объекта. Для этого узлы содержат вспомогательные объекты, помеченные символом * и предназначенные для хранения обратных ссылок на свои основные объекты. Вспомогательные объекты примера: И1*, И2*, ИЗ*, С1*, С2*, СЗ*.

Объекты И1, И2, ИЗ, С1, С2, СЗ имеют первичные ключи соответственно КИ1, КИ2, КИЗ, КС1, КС2, КСЗ, по которым их можно отыскать в первичном индексе. Кроме скалярных полей эти объекты содержат некоторое списковое ссылочное поле, показывающее, как организовано хранение ссылок. Для объектов класса И это поле И^С, а для объектов класса С поле С^И. В терминах некоторой гипотетической социальной сети, включающей классы Пользователь и Группа, поле И^С соответствует отношению Группы пользователя, а поле С^И - отношению Члены группы.

В объектах И1, И2, ИЗ в поле И^С хранятся ссылки на соответствующие узлы, где размещены объекты С1, С2, СЗ. В частности, в объекте И1 в поле И^С хранится ссылка И1^№ на узел N2, в объ- 9 027808 екте И2 в поле И^С хранятся ссылки υ2^Ν2 и υ2ΑΝ3 на узлы N2 и N3, а в объекте ИЗ в поле И^С хранятся ссылки υ3ΑΝ2 и υ3ΑΝ3 на узлы N2 и N3. Аналогично в объектах С1, С2, СЗ в поле С^И хранятся ссылки на соответствующие узлы, где размещены объекты С1, С2, С3. В частности, в объекте С1 в поле С^И хранятся ссылки С1 ^>N1 и С1 ^N3 на узлы N1 и N3, в объекте С2 в поле С^И хранится ссылка С2^Ш на узел N1, а в объекте С3 в поле С^И хранятся ссылки С3^Ш и С3 ^N3 на узлы N1 и N3. Таким образом, прямые ссылки на объекты заменены в объектах И1, И2, И3, С1, С2, С3 ссылками на узлы.

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

Вспомогательные объекты И1*, И2*, И3*, С1*, С2*, С3* имеют первичные ключи соответственно КИ1, КИ2, КИ3, КС1, КС2, КС3, по которым их можно отыскать в первичном индексе. Эти объекты содержат списковое ссылочное поле, показывающее, как организовано хранение обратных ссылок. Для объектов И1*, И2*, И3* это поле И^С, а для объектов С1*, С2*, С3* - поле С^И, что в терминах упомянутой выше гипотетической социальной сети соответствует отношениям Группы пользователя и Члены группы.

На каждом узле, где размещены объекты И1, И2, И3, хранятся вспомогательные объекты С1*, С2*, С3*, содержащие обратные ссылки основных объектов в пределах этого узла. Аналогично на каждом узле, куда распределены объекты С1, С2, С3, хранятся вспомогательные объекты И1*, И2*, И3*, содержащие обратные ссылки основных объектов в пределах этого узла.

В частности, на узле N1 вспомогательный объект С1* содержит в поле С^И ссылку С1^И1 на объект И1. На этом же узле вспомогательный объект С2* содержит в поле С^И ссылки С2^И1 и С2^И2 на объекты И1 и И2. На этом же узле вспомогательный объект С3* содержит в поле С^И ссылку С3^И2 на объект И2.

На узле N2 вспомогательный объект И1* содержит в поле И^С ссылки И1^С1 и И1^С2 на объекты С1 и С2. На этом же узле вспомогательный объект И2* содержит в поле И^С ссылку И2^С2 на объект С2. На этом же узле вспомогательный объект И3* содержит в поле И^С ссылку И3^С1 на объект И1.

На узле N3 вспомогательный объект С1* содержит в поле С^И ссылку С1^И3 на объект И3. На этом же узле вспомогательный объект С3* содержит в поле С^И ссылку С3^И3 на объект И3. На этом же узле вспомогательный объект И2* содержит в поле И^С ссылку И2^С3 на объект С3. На этом же узле вспомогательный объект И3* содержит в поле И^С ссылку И3^С3 на объект С3.

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

Дополненные структуры данных, необходимые для обеспечения работы механизма многоверсионности, показаны на фиг. 6 как расширения обычного объекта И1 и вспомогательного объекта С1* из фиг. 5 до уровня представления ячеек хранения объектов и списка ревизий.

Объект И1 на узле N1 представлен в виде ячейки хранения НИ1, в которой ссылка О^И1В адресует связный список ревизий объекта. Первой ревизией в списке хранится самая новая ревизия И1В, созданная в рамках транзакции Т2. Ревизия содержит первичный ключ КИ1 (общий для всех ревизий объекта), ссылку ТАГ2 на транзакцию Т2, ссылку Р^И1А на предыдущую ревизию И1А, обратную ссылку Н^НИ 1 на ячейку хранения НИ 1 (через нее можно добраться до любой ревизии), значения хранимых в ревизии скалярных полей РИ 1В и значения хранимых в ревизии ссылочных полей, из которых на фиг. 6 показано лишь поле И^С со ссылкой И1^№. Метка времени ревизии И1В хранится в транзакции Т2 в поле ТСШ. Предыдущая ревизия И1А содержит первичный ключ КИ1 (такой же как и в ревизии И1В), ссылку ТАГ1 на транзакцию Т1 (в рамках которой ревизия была создана), пустую ссылку РА№Ъ на

- 10 027808 предыдущую ревизию (предыдущая ревизия отсутствует), обратную ссылку Н^НИ 1 на ячейку хранения Ни1, значения хранимых в ревизии скалярных полей РШЛ и значения хранимых в ревизии ссылочных полей, из которых на фиг. 6 показано лишь поле И^О без ссылок.

Вспомогательный объект О1* представлен в виде ячейки хранения НО1*, в которой ссылка О^О1*А адресует единственную ревизию О1*А (в примере предполагается, что у объекта О1* существует лишь одна ревизия). Ревизия О1*А содержит первичный ключ КО1, ссылку Т^Т2 на транзакцию Т2 (в рамках которой ревизия была создана), пустую ссылку Р^Ы1Ь на предыдущую ревизию (предыдущая ревизия отсутствует), обратную ссылку Н^НО1* на ячейку хранения НО1*, значения хранимых в ревизии ссылочных полей, из которых показано лишь поле О^И со ссылкой 01^-НШ.

Показанная на фиг. 6 структура хранения ревизий объектов предполагает, что временные метки ревизий хранятся не в самих ревизиях, а в объектах транзакций, в частности Т1 и Т2. Объект транзакции впервые создается на узле-координаторе и дублируется на каждом узле-участнике, где в рамках транзакции обновляются объекты. Объект транзакции идентифицируется временной меткой, например транзакция Т1 идентифицируется временной меткой ΤΟΝ1, транзакция Т2 идентифицируется временной меткой ΤΟΝ2. На фиг. 6 считается, что транзакция Т2 выполнена после транзакции Т1 и временная метка ТСШ больше временной метки ТСШ. Каждый объект транзакции содержит список ссылок Т^Н на ячейки хранения объектов, обновляемых на узле в рамках транзакции. На фиг. 6 предполагается, что в транзакции Т1 на узле N1 обновился лишь объект И1, поэтому объект Т1 содержит в поле Т^Н единственную ссылку Т1^НИ1 на ячейку хранения НИ1. В транзакции Т2 на узле N1 обновились два объекта - И1 и О1*, поэтому объект Т2 содержит в поле Т^Н ссылку Т1^НИ1 на ячейку хранения НИ1 и ссылку Т1^НО1* на ячейку хранения НО1*.

Показанная на фиг. 6 структура хранения ревизий объектов И1 и О1* может быть расширена до любого количества ревизий, объектов, транзакций и узлов путем обычного повторения элементов.

На фиг. 7 показана схема, позволяющая понять предложенный в изобретении и реализованный в системе способ размещения объектов среди узлов базы данных. Генератор ключей 50 содержит внутренний беззнаковый целочисленный счетчик 80. Ширина ячейки счетчика в предпочтительном варианте осуществления изобретения составляет 64 бита или больше. Часть ячейки в диапазоне битов от О до В атомарно наращивается на единицу при каждом обращении к генератору ключей 50 за новым значением. Часть ячейки в диапазоне битов от С до О отведена для номера узла. В них генератор ключей 50 вписывает один и тот же уникальный номер своего узла. Благодаря этому обеспечивается уникальность выдаваемых генератором числовых значений. Числовое значение счетчика 80 преобразуется в беззнаковое числовое значение первичного ключа 81 следующим образом. Часть битов от А до В в счетчике 80 симметрично отображается таким образом, что меняются местами биты А и В, биты А плюс один и В минус один, биты А плюс два и В минус два и так далее до симметричной перестановки всех указанных битов, часть битов от О до А в счетчике 80 не участвуют в симметричной перестановке. Получаемый в результате такой генерации первичный ключ 81 оказывается уникальным в базе данных, на большой выборке равномерно распределен в диапазоне своих возможных значений и на малой выборке сгруппирован с некоторым количеством других последовательно выданных первичных ключей. На этом свойстве первичного ключа основан способ размещения адресуемого ключом объекта на узлах базы данных - значение первичного ключа 81 транслируется по карте размещения первичного индекса 82 в один из узлов размещения объекта.

Карта размещения первичного индекса 82 может включать несколько распределений объектов среди узлов базы данных, из которых последнее по времени создания распределение применяется для размещения на узлах вновь создаваемых объектов, а все остальные распределения являются историческими и применяются для определения местоположения созданных в прошлом объектов. Например, на фиг. 7 показаны три распределения: распределение объектов 83, распределение объектов 84 и последнее текущее распределение объектов 85. Каждое новое распределение объектов в карте размещения первичного индекса создается администратором базы данных по необходимости, например при добавлении новых узлов-участников, на которых планируется размещение первичного индекса.

Распределение объектов состоит из набора неперекрывающихся диапазонов беззнаковых числовых значений первичного ключа, от минимального нулевого значения до максимально возможного значения МАХ. Для каждого диапазона указывается список узлов, на которые сохраняются объекты с первичными ключами из данного диапазона. Количество узлов в диапазоне зависит от заданного в конфигурации базы данных уровня резервирования. Если уровень резервирования равен нулю (режим работы без резервирования), список узлов в диапазоне состоит из одного узла. Если уровень резервирования равен единице (режим с одним горячим резервом), список узлов в диапазоне состоит из двух узлов. Если уровень резервирования равен двум (режим с двумя горячими резервами), список узлов в диапазоне состоит из трех узлов. Уровень резервирования может быть сколь угодно большим. В предпочтительном варианте реализации изобретения он ограничен значением три (режим работы с тремя горячими резервами) из экономических соображений. Пример карты размещения первичного индекса на фиг. 7 создан для режима работы с одним горячим резервом каждого узла, расположенным на соседнем узле, причем в распре- 11 027808 делении 83 заданы три равновеликих диапазона на трех узлах, в распределении 84 заданы два равновеликих диапазона на двух узлах, в распределении 85 заданы пять равновеликих диапазонов на пяти узлах.

Распределение объектов содержит начальное и конечное значения счетчика 80 генератора ключей, в диапазоне которых объектам выдавались или выдаются первичные ключи. Если числовое значение счетчика 80, полученное обратным преобразованием из первичного ключа 81 некоторого объекта, находится между этими значениями, то размещение данного объекта определяется данным распределением. В примере на фиг. 7 начальное и конечное значения счетчика 80 для распределения 83 равны нулю и одному миллиарду соответственно, начальное и конечное значения счетчика 80 для распределения 84 равны одному миллиарду плюс один и полутора миллиардам соответственно, начальное и конечное значения счетчика 80 для распределения 85 равны полутора миллиардам плюс один и максимально возможному значению МАХ счетчика 80. Для 64-битного счетчика значение МАХ равно двум в шестьдесят четвертой степени.

Когда администратор базы данных создает новое распределение для объектов первичного индекса, оно применяется лишь к новым объектам - в карте размещения первичного индекса создается новое распределение, в котором начальное значение счетчика 80 устанавливается на единицу больше максимального известного в базе данных значения и конечное значение счетчика 80 не ограничивается. При этом в предыдущем распределении объектов фиксируется конечное значение счетчика 80 на уровне максимального известного в базе данных значения (начальное значение не изменяется). В результате создается новое поколение объектов с новым размещением на узлах базы данных. Такой способ создания поколений размещения объектов предполагает, что значения счетчика 80 являются числовыми, выдаются объектам последовательно от меньших значений к большим и могут быть восстановлены из значений первичного ключа 81 симметричной перестановкой битов от В до А.

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

Методы обработки данных.

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

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

Каждый узел базы данных имеет свой отдельный счетчик времени, представляющий собой целое число большой разрядности. В рассматриваемом варианте изобретения это 64-битное целое число. Счетчик времени выдает по запросам метки времени, представляющие собой пару чисел: номер узла и значение счетчика времени для этого узла. Из двух меток времени та больше, у которой больше значение счетчика, а при равенстве счетчиков та метка времени больше, у которой больше номер узла. Две метки времени с одинаковыми значениями номера узла и счетчика времени считаются равными.

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

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

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

- 12 027808

Таким образом каждый клиент работает с базой данных в своем относительном времени. Если некоторому клиенту необходимо прочитать данные, измененные другим клиентом, то для согласованного чтения правильных данных первому клиенту необходимо сначала согласовать свою метку времени с меткой времени второго клиента.

Специалистам в данной области должно быть очевидно, что такой способ управления временем в распределенной системе является усовершенствованием часов Лампорта. Первое усовершенствование заключается в том, что счетчик времени содержит номер узла, благодаря чему для всех значений счетчиков узлов определено отношение строгого порядка и, следовательно, все события в системе строго упорядочены. Второе усовершенствование заключается в том, что клиент не имеет своего счетчика времени, но при этом является переносчиком значений счетчиков времени, опосредовано участвуя в синхронизации времени узлов. Все это позволяет обеспечитесь согласованность данных при маршрутизации запросов клиента к разным узлам системы.

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

Читающая транзакция создается ядром выполнения клиентских запросов 42 в менеджере транзакций 48 и удаляется сразу после выполнения запроса. При создании читающая транзакция получает метку времени, которая используется для извлечения зафиксированных к этому моменту времени ревизий объектов и пропуска более поздних ревизий. Значение метки времени для читающей транзакции выбирается так, чтобы оно было в диапазоне между меткой времени клиента и текущей меткой времени узла. Предполагается, что метка времени клиента не больше метки времени узла, в противном случае выполняется синхронизация времени узла с временем клиента, чтобы указанное предположение всегда было верно.

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

Пишущая транзакция создается ядром выполнения клиентских запросов 42 в менеджере транзакций 48, помещается в список активных транзакций и остается в нем после выполнения запроса. Для пишущих транзакций выполняется коллективная фиксация, поэтому пишущая транзакция остается в списке активных транзакций до тех пор, пока информация о ее фиксации или откате не распространится на все вовлеченные в транзакцию узлы, после чего транзакция утилизируется работающим в фоне процессом сборки мусора. Каждая пишущая транзакция имеет уникальный идентификатор, называемый ключом, по которому транзакцию можно быстро найти в списке активных транзакций. Для обеспечения уникальности ключи транзакции представляют собой временные метки, выдаваемые самостоятельно узломкоординатором, который вместе с выдачей очередного ключа продвигает свой счетчик времени. Кроме ключа пишущая транзакция хранит список номеров узлов, которые вовлечены в транзакцию. Этот список используется для адресной рассылки команд фиксации или отката транзакции, а также для выяснении состояния транзакции, если узел-координатор не смог выполнить рассылку команд фиксации или отката. После фиксации пишущая транзакция хранит также временную метку фиксации, которая используется читающими транзакциями для доступа к снимку базы данных на определенный момент времени, как было описано выше.

При выполнении запроса атрибуты пишущей транзакции, включая ключ транзакции и список вовлеченных в транзакцию узлов, передаются ядру выполнения внутренних запросов 74 каждого вовлеченного узла-участника. Ядром выполнения внутренних запросов 74 в менеджере транзакций 68 создается копия транзакции с указанными атрибутами, которая помещается в список активных транзакций. После выполнения запроса ядром выполнения внутренних запросов 74 транзакция переводится в состояние готовности к фиксации. В этом состоянии может произойти как фиксация, так и откат транзакции, что определяется результатами выполнения транзакции на других узлах. При переводе транзакции в состояние готовности вычисляется текущая временная метка узла базы данных, которая запоминается в атрибутах транзакции и возвращается ядру выполнения клиентских запросов 42 на узле-координаторе.

После получения успешных результатов выполнения транзакции с узлов-участников ядром выполнения клиентских запросов 42 транзакция переводится в состояние готовности на узле-координаторе, при этом вычисляется текущая временная метка узла базы данных, которая запоминается в атрибутах транзакции. Для всех временных меток, собранных с вовлеченных в транзакцию узлов, вычисляется максимальное значение, которое используется в качестве временной метки фиксации транзакции.

Фиксация транзакции сначала выполняется на узле-координаторе, после чего запрос на фиксацию на узлах-участниках ставится в специальную очередь и результат транзакции возвращается клиенту. Запрос на фиксацию содержит ключ транзакции, временную метку фиксации и список вовлеченных в транзакцию узлов. Очередь запросов на фиксацию транзакций обрабатывается параллельным процессом, ко- 13 027808 торый периодически выбирает накопившиеся запросы и в пакетном режиме отправляет команды фиксации узлам базы данных. Список узлов, которым рассылаются команды фиксации, формируется как объединение множеств всех узлов из всех накопившихся запросов. Откат транзакций выполняется аналогичным образом, только вместо команд фиксации узлам-участникам рассылаются команды отката. Таким образом, фиксация или откат транзакций на узлах-участниках происходит асинхронно в пакетном режиме, что существенно уменьшает для клиента задержку времени между посылкой запроса и получением ответа, а также снижает внутренний сетевой трафик системы. Этот подход выгодно отличается от двухфазного механизма фиксации.

При выполнении нескольких пишущих транзакций в тех случаях, когда транзакции одновременно обновляют несколько объектов, расположенных на нескольких узлах, может произойти конфликт транзакций. Поясним его на примере. Предположим, что транзакции Т1 и Т2 обновляют объекты А и В, расположенные на узлах N1 и N2 соответственно. Каждая из этих транзакций обновляет оба объекта. Сценарий может оказаться следующим. В один и тот же момент времени транзакция Т1 обновила объект А, а транзакция Т2 обновила объект В. В следующий момент времени транзакция Т1 пытается обновить объект В, который уже изменен транзакцией Т2 и еще не зафиксирован, а транзакция Т2 пытается обновить объект В, который изменен транзакцией Т1 и тоже еще не зафиксирован. Наблюдается конфликт транзакций. Если обе транзакции выполнят ожидание фиксации, возникнет бесконечная блокировка. Поэтому при обнаружении конфликта выполняется откат транзакции, и клиент получает результат с признаком конфликта. В предпочтительном варианте осуществления изобретения предпринимаются меры для преодоления конфликта. Клиент базы данных в автоматическом режиме пытается повторить запрос после небольшой задержки в надежде, что следующая попытка окажется бесконфликтной. После нескольких безуспешных попыток, количество которых определяется конфигурацией клиента, клиент сообщает о возникшем конфликте пользователю. Пользователь принимает решение продолжить попытки выполнить запрос или отложить действие до тех пор, пока другие клиенты не завершат работу с данными, ставшими причиной конфликта.

На случай отказа узла-координатора 40 или сбоя вычислительной сети узлов 24 при передаче команд фиксации или отката в менеджере транзакций 68 имеется очередь запросов на выяснение результатов транзакций, которые перешли в состояние готовности к фиксации, но по какой-то причине не были зафиксированы. Запросы в эту очередь помещаются менеджером транзакций 68 на узле-участнике вместе с переводом транзакции в состояние готовности к фиксации и непосредственно перед возвратом результата транзакции вызывающему ядру выполнения клиентских запросов на узле-координаторе. Очередь запросов на выяснение результатов транзакций обрабатывается параллельным процессом, который периодически выбирает накопившиеся запросы и в пакетном режиме отправляет их вовлеченным в транзакции узлам базы данных. Для каждой транзакции запрос отправляется сначала узлу-координатору, а потом узлам-участникам. Узел-координатор вычисляется среди вовлеченных в транзакцию узлов по значению ключа транзакции (ключ транзакции представляет собой метку времени с закодированным в ней номером узла-координатора). Если в результате опроса всех вовлеченных в транзакцию узлов обнаруживается, что на одном из узлов транзакция была зафиксирована или ей был сделан откат, то в такое же состояние фиксации или отката транзакция переводится на узле, выполняющем опрос. Если окончательное состояние транзакции после опроса всех вовлеченных в транзакцию узлов оказывается не определено, запрос на выяснение результата транзакции снова ставится в обрабатываемую очередь, чтобы через некоторое время попытка выяснить результат транзакции повторилась. Для оптимальной работы интервал времени между обслуживаниями очереди запросов на выяснение результатов транзакций должен быть значительно больше интервала времени между обслуживаниями очереди запросов на фиксацию и откат транзакций.

Основываясь на изложенных выше структурах хранения объектов и ссылок (фиг. 5 и 6) и методе транзакционной работы с объектами, рассмотрим метод извлечения объектов из базы данных. Сделаем это на примере выполнения некоторого запроса на извлечение Пользователя И2 вместе со всеми Группами О, на которые Пользователь И2 ссылается через поле И^О. Блок-схема выполнения запроса показана на фиг. 8.

На шаге 90 ядро выполнения клиентских запросов 42 некоторого узла-координатора N4 принимает от клиента запрос вида Извлечь объекты, параметрами которого являются временная метка ΟΟΝ клиента, первичный ключ объекта КИ2, имена классов запрашиваемых объектов и и О, а также имя ссылочного поля О >0. через которое выбираются подчиненные объекты.

На шаге 91 менеджер транзакций 48 создает в списке активных транзакций читающую транзакцию Т с меткой времени ΤΟΝ. Значение временной метки выбирается так, чтобы она была не меньше временной метки клиента, но не больше временной метки узла. Метка времени ΤΟΝ используется для чтения зафиксированных к этому времени ревизий объектов и для отбрасывания более поздних изменений данных. На этом шаге фактически происходит продвижение логического времени клиента вперед, причем клиент немного отстает по времени от системы, что обеспечивает в большинстве случаев бесконфликтное чтение и редактирование данных. Величина отставания времени клиентов от времени системы может

- 14 027808 динамически корректироваться в зависимости от текущей загрузки системы.

На шаге 92 ядро выполнения клиентских запросов 42 запрашивает ревизию объекта с первичным ключом КИ2 на момент времени ΤΟΝ. Для этого на основании значения первичного ключа КИ2 и карты размещения первичного индекса определяется узел, где находится объект. В рассматриваемом примере это узел N1. Далее на узел N1 передается запрос 93, содержащий временную метку ΤΟΝ и ключ КИ2.

На шаге 94 ядро выполнения внутренних запросов 74 узла N1 выбирает по первичному ключу КИ2 в первичном индексе 67 фрагмента базы данных 65 ячейку хранения объекта. В этой ячейке выбирается последняя зафиксированная ревизия объекта И2 на момент времени ΤΟΝ, допустим ревизия И2Л. Ревизия И2Л возвращается в ответе 95 ядру выполнения клиентских запросов 42 на узле N4.

На шаге 96 ядро выполнения клиентских запросов 42 запрашивает подчиненные объекты класса С, на которые ссылается ревизия И2А. Для этого путем обращения к полю И^С ревизии И2А определяются узлы, где хранятся подчиненные объекты. В примере на фиг. 5 это узлы N2 и N3. Далее два подчиненных запроса 97 и 98 адресуются параллельно ядру выполнения внутренних запросов 74 на узле N2 и ядру выполнения внутренних запросов 74 на узле N3. Параметрами каждого подчиненного запроса являются временная метка ТС^ первичный ключ КИ2 и поле И^С.

На шаге 99 ядро выполнения внутренних запросов 74 узла N2 отыскивает по первичному ключу КИ2 ячейку вспомогательного объекта И2* и выбирает из нее последнюю зафиксированную ревизию на момент времени ТОМ Эта ревизия содержит в поле И^С ссылки на ячейки хранения объектов класса С, размещенные в первичном индексе 67 фрагмента базы данных 65 на узле N2. Из поля И^С выбирается массив обратных ссылок, состоящий согласно фиг. 5 из одной ссылки И2^С2, указывающей на ячейку хранения объекта С2. По этой ссылке на узле N2 выбирается последняя зафиксированная ревизия объекта С2 на момент времени ТОМ допустим С2А, и копия этой ревизии возвращается в ответе 101 на подчиненный запрос 97.

Аналогично, на шаге 100 ядро выполнения внутренних запросов 74 узла N3 отыскивает по первичному ключу КИ2 ячейку вспомогательного объекта И2* и выбирает из нее последнюю зафиксированную ревизию на момент времени ТОМ Эта ревизия содержит в поле И^С ссылки на все ячейки объектов класса С, которые согласно карте размещения первичного индекса хранятся на узле N3. Из поля И^С выбирается массив обратных ссылок, состоящий согласно фиг. 5 из одной ссылки И2^С3 на ячейку хранения объекта С3. По этой ссылке на узле N3 выбирается последняя зафиксированная ревизия объекта С3 на момент времени ТОМ допустим С3А, и копия этой ревизии возвращается в ответе 102 на подчиненный запрос 98.

На шаге 103 ядро выполнения клиентских запросов 42 достраивает взаимные ссылки между всеми полученными ревизиями объектов (ревизиями И2А, С2А, С3А в рассматриваемом примере).

На шаге 104 читающая транзакция Т исключается из списка активных транзакций и передается на утилизацию. Утилизация памяти всех завершившихся транзакций выполняется периодически менеджером транзакций. Механизм утилизации рассмотрен ниже в описании изобретения.

На шаге 105 полученный граф объектов возвращается клиенту вместе с новой временной меткой ТОМ Эту временную метку клиент должен передать в следующем обращении к серверу.

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

Основываясь на изложенных выше структурах хранения объектов и ссылок (фиг. 5 и 6) и методе транзакционной работы с объектами, рассмотрим метод сохранения объектов в базу данных. Сделаем это на примере выполнения некоторого запроса на обновление скалярных данных Группы С1 и Пользователя И2 и добавление Пользователя И2 в Группу С1. Блок-схема выполнения запроса показана на фиг. 9.

На шаге 110 ядро выполнения клиентских запросов 42 некоторого узла-координатора N4 принимает от клиента запрос вида Сохранить объекты, параметрами которого являются временная метка ССN клиента, первичный ключ КС1 объекта С1, значения скалярных полей РС1 объекта С1, первичный ключ КИ2 объекта И2, значения скалярных полей РИ2 объекта И2, ссылка С1^И2 из объекта С1 на объект и2.

На шаге 111 в объектах достраиваются обратные ссылки, в частности достраивается ссылка И2^С1 из объекта И2 на объект С1.

На шаге 112 ядро выполнения клиентских запросов 42 узла N4 создает пишущую транзакцию Т с ключом, равным увеличенному значению временной метки узла N4. Транзакция переводится в фазу выполнения операций и помещается в список активных транзакций менеджера транзакций 48.

На шаге 113 ядро выполнения клиентских запросов 42 узла N4 запрашивает с узлов новейшие зафиксированные ревизии объектов С1 и И2. Это делается по рассмотренному выше методу и согласно показанной на фиг. 8 блок-схеме извлечения объектов. В результате исполнения сценария этой схемы на шаге 114 из первичного индекса 67 фрагмента базы данных 65 узла N1 извлекается некоторая ревизия И2Х объекта И2 и возвращается ядру выполнения клиентских запросов 42 на узле N4. Аналогично на

- 15 027808 шаге 115 из первичного индекса 67 фрагмента базы данных 65 узла N2 извлекается некоторая ревизия С1Х объекта 01 и возвращается ядру выполнения клиентских запросов 42 на узле N4.

На шаге 116 ядро выполнения клиентских запросов 42 создает объекты 01Υ и υ2Υ как копии ревизий соответственно 01Х и и2Х, в которых обновлены скалярные поля Р01 и Ри2 и увеличены на единицу номера ревизий. На этом шаге дополнительно создаются вспомогательные объекты 01*Υ и υ2*Υ, содержащие обновления для списков обратных ссылок, которые согласно фиг. 5 хранятся в объектах 01* и υ2* на узлах соответственно N1 и N2. Объект 01*Υ представляет собой обновление для объекта 01* на узле N1 и содержит ссылку 01^-Ш в добавочном списке ссылок для поля 0^П. Объект υ2*Υ представляет собой обновление для объекта υ2* на узле N2 и содержит ссылку Ш^-01 в добавочном списке ссылок для поля Ъ >0.

На шаге 117 ядро выполнения клиентских запросов 42 по картам размещения вторичных индексов вычисляет узлы хранения ревизий 01Х, 01Υ, υ2Χ, υ2Υ во вторичных индексах. В примере сценария, показанного на фиг. 9, считается, что построены два вторичных индекса - вторичный индекс по некоторым скалярным полям объектов класса 0 и вторичный индекс по некоторым скалярным полям объектов класса υ. При этом считается, что выпадает следующее размещение ревизий объектов 01 и υ2 во вторичных индексах: ревизия 01Х - на узле N1, ревизия 01Υ - на узле N3, ревизии υ2Χ и υ2Υ - на узле N2. Полученное размещение означает, что новая ревизия 01Υ объекта 01 оказалась в другом диапазоне вторичного индекса по сравнению с предыдущей ревизией 01Х и должна быть размещена на другом узле, новая ревизия υ2Υ объекта υ2 размещается на том же самом узле, что и предыдущая ревизия ШХ.

Учитывая размещение ревизий 01Υ, υ2Υ, 01Х, ШХ в первичном и вторичных индексах, объекты распределяются среди узлов-участников следующим образом. На шаге 118 узел N1 принимает: ревизию υ2Υ для включения в первичный индекс, ревизию 01*Υ для включения в первичный индекс как вспомогательный объект, номер ревизии 01Х для изъятия объекта из вторичного индекса на данном узле. На шаге 119 узел N2 принимает: ревизию 01Υ для включения в первичный индекс, ревизию υ2*Υ для включения в первичный индекс как вспомогательный объект, ревизию υ2Υ для включения во вторичный индекс. На шаге 120 узел N3 принимает ревизию 01Υ для включения во вторичный индекс. Каждый узел-участник принимает еще идентификатор транзакции Т, в рамках которой выполняется сохранение объектов.

Далее каждый из узлов-участников выполняет одинаковую последовательность действий, показанную на фиг. 9 шагами 121, 124, 127 и 130. На узле N1 ядро выполнения внутренних запросов 74 выполняет следующие действия. На шаге 121 регистрируется пишущая транзакция Т. Транзакция переводится в состояние выполнения операций и помещается в список активных транзакций менеджера транзакций 68. На шаге 124 во фрагменте базы данных 65 в первичном индексе 67 сохраняются ревизии υ2Υ и 01*Υ и во вторичном индексе 69 сохраняется признак изъятия объекта с ревизией 01Х из вторичного индекса. Операции этого шага более подробно пояснены на фиг. 10. На шаге 127 транзакция Т переводится в состояние готовности к фиксации и вычисляется временная метка ΚСN1 этой транзакции. Временная метка РСШ вычисляется как увеличенное на единицу значение временной метки узла. На шаге 130 запрос на выяснение результата транзакции Т ставится в очередь транзакций, ожидающих результата. Временная метка РСШ возвращается в ответе 133 ядру выполнения клиентских запросов 42 на узел-координатор N4.

Аналогично на узле N2 ядро выполнения внутренних запросов 74 выполняет следующие действия. На шаге 122 регистрируется пишущая транзакция Т. Транзакция переводится в состояние выполнения операций и помещается в список активных транзакций менеджера транзакций 68. На шаге 125 во фрагменте базы данных 65 в первичном индексе 67 сохраняются ревизии 01Υ и υ2*Υ и во вторичном индексе 69 сохраняется ревизия υ2Υ. На шаге 128 транзакция Т переводится в состояние готовности к фиксации и вычисляется временная метка КСШ этой транзакции. Временная метка КСШ вычисляется как увеличенное на единицу значение временной метки узла. На шаге 131 запрос на выяснение результата транзакции Т ставится в очередь транзакций, ожидающих результата. Временная метка КСШ возвращается в ответе 134 ядру выполнения клиентских запросов 42 на узел-координатор N4.

Аналогично на узле N3 ядро выполнения внутренних запросов 74 выполняет следующие действия. На шаге 123 регистрируется пишущая транзакция Т. Транзакция переводится в состояние выполнения операций и помещается в список активных транзакций менеджера транзакций 68. На шаге 126 во фрагменте базы данных 65 во вторичном индексе 69 сохраняется ревизия 01Υ. На шаге 129 транзакция Т переводится в состояние готовности к фиксации и вычисляется временная метка РСШ этой транзакции. Временная метка РСШ вычисляется как увеличенное на единицу значение временной метки узла. На шаге 132 запрос на выяснение результата транзакции Т ставится в очередь транзакций, ожидающих результата. Временная метка РСШ возвращается в ответе 135 ядру выполнения клиентских запросов 42 на узел-координатор N4.

На шаге 136 ядром выполнения клиентских запросов на узле N4 транзакция Т переводится в состояние готовности к фиксации и вычисляется временная метка К.С№) этой транзакции. Временная метка К.С№) вычисляется как увеличенное на единицу значение временной метки узла.

- 16 027808

На шаге 137 вычисляется новая временная метка ΊΌΝ, равная максимуму из временных меток ΚΗΝΟ, Κ£Ν1, ΚΗΝ2, ΚΤΝ3.

На шаге 138 выполняется фиксация транзакции Т с временной меткой Τί'.'Ν. Фиксация затрагивает лишь узел-координатор Ν4.

Фиксация транзакции на узлах-участниках выполняется позже в асинхронном режиме. Для этого на шаге 139 запрос на завершение фиксации транзакции Т на узлах-участниках Ν1, Ν2, Ν3 ставится в очередь транзакций, ожидающих завершение фиксации. Запросы из этой очереди выбираются асинхронным процессом, который рассылает команды фиксации узлам-участникам. Механизм фиксации транзакций является практически однофазным и не требует от клиента ожидания фиксации транзакции на всех узлах. Достаточно переключить транзакцию в состояние готовности на всех узлах, чтобы считать транзакцию логически зафиксированной. Участие в транзакции двух и более узлов обеспечивает необходимую гарантию надежности механизма транзакций и его устойчивости к отказам одного из узлов. Дополнительной оптимизацией при фиксации является рассылка узлам команд в пакетном режиме, когда в одном сообщении узлу приходит сразу несколько команд фиксации для нескольких завершенных транзакций.

На шаге 140 клиенту отправляется новая временная метка ТСИ, используемая им впоследствии для выполнения операций извлечения и поиска объектов. Гарантируется, что клиент прочитает новейшие к времени ΤСN ревизии объектов и не увидит данные в прошлом относительно этой временной метки.

На фиг. 10 показана блок-схема, дополняющая фиг. 9 и помогающая понять способ, с помощью которого выполняются сохранение объектов на узле-участнике в фрагмент базы данных в рамках транзакции сохранения объектов.

Предназначенный для сохранения список объектов 141 передается в цикл обработки 142, в котором для каждого объекта О из входного списка 141 выполняются операции, начиная с 143 и заканчивая 152.

На шаге 143 определяется заданный во входном списке режим сохранения объекта О - создание нового объекта или обновление существующего. Если запрашивается создание нового объекта, то на шаге 144 в первичном индексе создается новая ячейка НО для хранения объекта О. Эта операция выполняется атомарно. Если запрашивается обновление существующего объекта, то на шаге 145 в первичном индексе отыскивается существующая ячейка НО объекта О.

На шаге 146 объект О атомарно добавляется в список ревизий ячейки НО. Структура списка ревизий была рассмотрена выше в описании фиг. 6. Список ревизий является однонаправленным, элементы следуют от новейшей ревизии к старейшей ревизии, ссылка на начало списка содержится в ячейке хранения объекта. С каждым элементом списка ассоциирована транзакция, в рамках которой была создана ревизия объекта. Объект транзакции хранит временную метку, с которой транзакция была зафиксирована. Ссылка на транзакцию является пустой, если транзакция была утилизирована, причем в таком случае значение временной метки фиксации уже не имеет значения, поскольку утилизируются лишь те транзакции, время фиксации которых гарантированно находится в прошлом относительно метки времени любого клиента. Объект О добавляется в начало списка ревизий ячейки НО, причем это происходит лишь при условии, что предыдущая ревизия зафиксирована на момент операции и не превышает по номеру ревизию объекта О. Если указанное условие не выполняется, то это свидетельствует о конфликте транзакций один и тот же объект обновляется одновременно несколькими клиентами.

На шаге 147 проверяется, не возник ли конфликт транзакций, и если конфликта нет, то происходит переход к следующему шагу 148. В случае конфликта транзакций цикл 142-153 прерывается и на шаге 154 устанавливается признак отката транзакции.

В цикле 148-152 объект О добавляется во вторичные индексы, заданные для объекта О в исходном списке. Запрос на добавление объекта О в некоторый вторичный индекс 8 поступает от узлакоординатора лишь в том случае, если вторичный ключ объекта О в индексе 8 приходится на размещенный на данном узле диапазон. От узла-координатора может поступить запрос на исключение объекта О из вторичного индекса 8 на данном узле в том случае, если в транзакции создана более новая ревизия объекта, размещаемая в другом диапазоне вторичного индекса 8 на другом узле-участнике.

Вторичный индекс бывает двух типов - с уникальными и неуникальными ключами. На шаге 149 делается проверка типа вторичного индекса 8. Если это индекс с уникальными ключами, на шаге 150 выполняется проверка, не возникает ли конфликт вторичного ключа объекта О с вторичными ключами существующих объектов в индексе 8. Если обнаруживается конфликт вторичного ключа в индексе 8, цикл 148-152 прерывается и на шаге 154 устанавливается признак отката транзакции. Если конфликт вторичного ключа не обнаружен, или же вторичный индекс 8 построен с неуникальными ключами, на шаге 151 объект О добавляется во вторичный индекс 8.

Цикл 148-152 выполняется для каждого вторичного индекса 8, запрошенного для объекта О в исходном списке 141.

На шаге 155 признак успешного сохранения объектов в фрагмент базы данных, или признак отката транзакции, возвращается ядру выполнения внутренних запросов 74. В случае отката транзакции ядро выполнения внутренних запросов 74 целиком отменяет операцию сохранения списка объектов в фрагмент базы данных.

Основываясь на изложенных выше структурах хранения объектов и ссылок (фиг. 5 и 6) и методе

- 17 027808 транзакционной работы с объектами, рассмотрим метод поиска объектов в базе данных по значениям скалярных полей. Сделаем это на примере поиска и извлечения некоторого количества Пользователей и для каждого Пользователя - некоторого количества ассоциированных с ним Групп. Блок-схема выполнения запроса показана на фиг. 11 и фиг. 12.

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

На шаге 160 ядро выполнения клиентских запросов 42 некоторого узла-координатора N4 принимает от клиента запрос вида «Найти и извлечь объекты», параметрами которого являются временная метка ССN клиента, класс и искомых объектов, вторичный индекс δ (в котором следует выполнить поиск объектов), вторичный ключ δυ начального объекта (с которого следует выполнять последовательную фильтрацию), уточняющий первичный ключ Ки пропускаемого объекта, условие фильтрации Си объектов класса и по значениям скалярных полей, предельное количество Νυ извлекаемых объектов класса и, имя ссылочного поля и >0 для выбора подчиненных объектов, класс О подчиненных искомых объектов, ссылочный индекс К (построенный по полю и^О и обеспечивающий нужный порядок следования объектов класса О в объектах класса и), условие фильтрации СО объектов класса О по значениям скалярных полей, предельное количество N0 извлекаемых объектов класса О в каждом объекте класса и.

На шаге 161 менеджером транзакций 48 в списке активных транзакций создается читающая транзакция Т с временной меткой Τί','Ν. Значение временной метки выбирается так, чтобы она была не меньше временной метки клиента, но не больше временной метки узла. Метка времени ΤСN используется для чтения зафиксированных к этому времени ревизий объектов и для отбрасывания более поздних изменений данных. На этом шаге фактически происходит продвижение логического времени клиента вперед, причем клиент немного отстает по времени от системы, что обеспечивает в большинстве случаев бесконфликтное чтение и редактирование данных. Величина отставания времени клиентов от времени системы может динамически корректироваться в зависимости от текущей загрузки системы.

На шаге 162 ядро выполнения клиентских запросов 42 выбирает из конфигурации базы данных 46 карту размещения вторичного индекса δ, находит в этой карте соответствующий ключу δи начальный узел вторичного индекса, на котором следует выполнить двоичный поиск и фильтрацию объектов. В рассматриваемом на фиг. 11 примере предполагается, что начальным узлом становится узел N1. С этого узла из вторичного индекса δ запрашиваются зафиксированные на момент времени ΤСN объекты класса и, удовлетворяющие условию Си, в количестве не более ΝΗ начиная с объекта с вторичным ключом δи и первичным ключом Ки, пропуская этот объект. Для этого в запросе 163 на целевой узел передаются временная метка ТСЮ класс извлекаемых объектов и, вторичный индекс δ, вторичный ключ δ^ первичный ключ Ки, условие фильтрации Си, предельное количество объектов ΝΗ

На шаге 164 ядро выполнения внутренних запросов 74 узла-участника двоичным поиском отыскивает во вторичном индексе δ первый объект с вторичным ключом δΗ Если первичный ключ Ки не задан, с этого момента начинается фильтрация объектов с помощью временной метки ΤСN и условия Си. Если первичный ключ Ки задан, последовательным просмотром объектов с ключом δи во вторичном индексе δ отыскивается объект с первичным ключом Ки. Сразу следом за этим объектом начинается фильтрация объектов с помощью временной метки ΤСN и условия Си. Во фрагменте вторичного индекса на данном узле содержатся все ревизии всех объектов, в которых вторичные ключи включены в диапазон данного узла. Это значит, что при проходе по вторичному индексу в выборку могут попадать несколько ревизий одного и того же объекта. Чтобы это исключить, применяется следующий метод фильтрации. Для каждой выбираемой из вторичного индекса ревизии осуществляется проверка, является ли она ближайшей к временной метке ΤСN ревизией. Согласно фиг. 6, каждая ревизия (например, и 1В) содержит ссылку на ячейку хранения объекта (например, Ни1), ссылку на объект транзакции (например, Т1) с временной меткой фиксации (например, Τί'Ν1) и ссылку на следующую ревизию (например, и1А). Через ячейку и связный список доступны все ревизии объекта. Имея ревизию, ядро выполнения внутренних запросов обращается к ячейке хранения объекта, проходит по связному списку ревизий и отыскивает в нем ревизию с ближайшей к ΤСN временной меткой, меньшей либо равной Τί','Ν. Затем выполняется проверка, совпадает ли эта ревизия с ревизией, взятой из вторичного индекса. Если - нет, то ревизия, взятая из вторичного индекса, пропускается. Если - да, выполняется проверка, что ревизия зафиксирована. Если ревизия не зафиксирована, выполняется попытка фиксации на лету. Неудача на стадии фиксации на лету вызывает досрочно прекращение операции 164 с возвратом узлу-участнику и затем клиенту признака конфликта с другим параллельным запросом. В ответ клиент может выждать некоторое время и повторить запрос в надежде, что с новой попыткой конфликта не будет. Если ревизия зафиксирована, к ней применяется условие фильтрации Си.

Условие фильтрации Си представляет собой булевское выражение над полями объекта. По результатам вычисления этого выражения ревизия или включается в результирующее множество {№}, или пропускается. Фильтрация объектов с помощью временной метки ΤСN и условия Си останавливается, если количество элементов в множестве {Щ} становится равным ΝΗ или достигнут конец фрагмента

- 18 027808 вторичного индекса 8 на данном узле. Результирующее множество {№} выбранных объектов, количество ΝΝυ выбранных объектов, вторичный ключ Ν8υ последнего элемента и первичный ключ ΝΚυ последнего элемента возвращаются в ответе 165 на узел-координатор.

На шаге 166 ядро выполнения клиентских запросов 42 узла-координатора проверяет, выбрано ли требуемое количество объектов. Для этого значение ΝΝυ сравнивается со значением Νυ. Если ΝΝυ меньше Νυ, фильтрацию объектов следует продолжить на следующем узле в следующем диапазоне вторичного индекса 8. Если требуется продолжить поиск, на шаге 167 значение Νυ уменьшается на величину ΝΝυ, вторичному ключу 8υ присваивается значение Ν8υ, первичному ключу Κυ присваивается значение ΝΚυ и поисковый запрос повторяется на следующем узле в следующем диапазоне вторичного индекса (если такой имеется). В примере на фиг. 11 следующим узлом для вторичного индекса 8 считается узел Ν2. На него передается поисковый запрос 168. Параметры запроса 168 полностью соответствуют параметрам запроса 163.

На шаге 169 следующий узел-участник отыскивает в своем диапазоне вторичного индекса 8 объект, следующий за вторичным ключом 8υ и первичным ключом Κυ. Этот объект соответствует началу диапазона вторичного индекса 8 на данном узле-участнике. Далее на шаге 169 выполняется фильтрация объектов, аналогичная фильтрации шага 164. В результате формируется ответ 170, эквивалентный описанному выше ответу 165. Этот ответ передается на узел-координатор, который снова выполняет проверку 166 и принимает решение о том, следует ли продолжить поиск объектов на следующем узле в следующем диапазоне вторичного индекса 8.

Если узел-координатор выбрал из вторичного индекса 8 необходимое количество объектов или все диапазоны вторичного индекса просмотрены, цикл опроса диапазонов прерывается, на шаге 171 все выбранные объекты сливаются в одно множество {υί} и начинается показанный на фиг. 12 выбор подчиненных объектов.

На шаге 172 ядро выполнения клиентских запросов 42 узла-координатора выделяет множество первичных ключей {Κυί} из множества {υί} выбранных объектов. Для каждого ключа из этого множества на узлах будут найдены вспомогательные объекты с таким ключом, из них через прямые ссылки будут извлечены подчиненные объекты, переданы на узел-координатор, объединены и ограничены по количеству. В результате для каждого объекта υί будет сформировано множество подчиненных объектов {О_)}, что обозначается как υί:{Ο_)}. Множество всех объектов υί вместе с их подчиненными объектами обозначается как {υί:{0(}}.

На шаге 173 ядро выполнения клиентских запросов 42 узла-координатора запрашивает на узлахучастниках зафиксированные на момент времени ΤСN объекты класса О, на которые вспомогательные объекты с ключами {Κυί} ссылаются через поле υ^Ο. Узлы-участники определяются на основании значений ключей {Κυί} и карты размещения первичного индекса на узлах. В параметрах запроса 174, передаваемого на каждый релевантный узел-участник, указываются: временная метка ΤΟΝ, ключи {Κυί} располагаемых на узле вспомогательных объектов, имя ссылочного поля υ^Ο для выбора подчиненных объектов, класс О выбираемых объектов, ассоциированный с полем υ^Ο ссылочный индекс К (который должен обеспечить нужный порядок просмотра и извлечения объектов), условие СО извлечения объектов и максимальное количество ΝΟ извлекаемых объектов.

Далее ядро выполнения внутренних запросов 74 каждого релевантного узла-участника выполняет одну и ту же последовательность действий, показанную на фиг. 12 в виде цикла 175-177. Тело цикла представлено блоком 176. В нем для каждого ключа Κυί из входного множества {Κυί} отыскивается зафиксированная на момент времени ΤСN ревизия вспомогательного объекта υί*. В этой ревизии из поля Е >С, извлекается ссылочный индекс К. Если это первое использование данного ссылочного индекса в данной ревизии объекта, то выполняется построение ссылочного индекса К путем сортировки первичного множества ссылок поля υ^Ο на основе значений скалярных полей адресуемых объектов. Через ссылки индекса К извлекаются зафиксированные на момент времени ΤСN объекты класса Ο, удовлетворяющие условию СΟ, в количестве не более ΝΟ. В результате для каждого ключа Κυί создается множество подчиненных объектов {Ο_|}, что обозначается как Κυί:{Ο_)}. Множество всех ключей Κυί вместе с ассоциированными с ними подчиненными объектами обозначается как {Κυί:{Ο_|}}. Это множество возвращается узлу-координатору в ответе 178 узла-участника.

На шаге 179 ядро выполнения клиентских запросов 42 узла-координатора собирает ответы {Κυί:{Ο_|}} всех задействованных узлов-участников. Для каждого ключа Κυί множества {Ο_|}, полученные со всех узлов, объединяются в один набор объектов в порядке следования объектов Ο_) в индексе К, затем из полученного набора выбирается не более ΝΟ объектов, и они ассоциируются с объектом υί. Так создается результирующее множество объектов {υί:{Ο_|}}. На шаге 180 во всех этих объектах достраиваются взаимные ссылки.

На шаге 181 менеджером транзакций 48 узла-координатора в списке активных транзакций удаляется читающая транзакция Т.

На шаге 182 полученный граф объектов {υί:{Ο_)}} возвращается клиенту вместе с новой временной меткой Τί'.'Ν. Эту временную метку клиент должен передать в следующем обращении к серверу.

- 19 027808

С целью обеспечения долговременного хранения объектов в базе данных, устойчивого к отключению питающей электроэнергии, зафиксированные объекты сохраняются в постоянное хранилище 72 (фиг. 3). Поскольку устройством хранения данных в постоянном хранилище обычно выступает дисковая память, объекты в нем находятся в файлах, и сохранение объектов в постоянное хранилище выполняется методом сериализации. Существуют несколько режимов сохранения объектов в постоянное хранилище: синхронное сохранение объектов в рамках транзакции, асинхронное сохранение объектов вне транзакций как дополнительная страховка на случай сбоя узла, создание снимка базы данных по запросу администратора базы данных. Режим сохранения объектов в постоянное хранилище выбирается администратором базы данных.

В рассматриваемом варианте осуществления изобретения во всех режимах применяется одинаковый метод записи объектов в файлы. В рамках этого метода каждый узел базы данных сериализует в свое локальное постоянное хранилище свой фрагмент базы данных. Набор логических файлов, содержащих все множество доступных объектов базы данных, состоит из снимка базы данных на какой-то момент времени (первый логический файл), приращения к этому снимку до текущего момента времени (второй логический файл) и метаданных о снимке и приращении (третий логический файл). Каждый логический файл может состоять из одного или нескольких физических файлов. Метаданные - это крайние временные метки логических файлов данных, количество и размер объектов в них, другие статистические данные об объектах.

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

Сохранение объектов в постоянное хранилище осуществляется параллельно различными процессами, обрабатывающими запросы клиентов. Чтобы уменьшить потери, связанные с синхронизацией доступа к единому логическому файлу приращения, в рассматриваемом варианте реализации изобретения применяется отдельный процесс сериализации и очередь запросов к нему. Другие процессы выступают инициаторами сохранения объектов в постоянное хранилище, когда атомарно помещают в очередь процессу сериализации запросы на сохранение объектов. Процесс сериализации пробуждается, когда в его очереди появляются запросы. Он вычитывает все запросы и сериализует объекты этих запросов до тех пор, пока очередь не опустеет. Затем он переводится в состояние ожидания до появления в очереди нового запроса.

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

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

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

Утилизацией ненужных объектов занимается периодический процесс сборки мусора, запускаемый в

- 20 027808 каждом фрагменте базы данных каждого узла СУБД. Параметрами процесса сборки мусора являются две временные метки, обозначаемые как ССNТ и С'С'НО. Временная метка ССNТ задает границу отсечения завершившихся пишущих транзакций, а временная метка ССNО - границу отсечения устаревших ревизий объектов. Значение временной метки ССNТ вычисляется как минимальное значение временной метки фиксации или отката среди всех активных пишущих транзакций. Значение временной метки ССNО вычисляется как минимальное значение среди всех временных меток читающих клиентов.

Процесс сборки мусора работает следующим образом.

Из списка активных транзакций выбираются зафиксированные или отмененные транзакции, в которых временная метка меньше временной метки ССNТ. В результате формируется список утилизируемых транзакций. Затем для каждой транзакции из этого списка выполняется цикл операций с включенными в транзакцию объектами. Для каждого включенного в транзакцию объекта выполняется поиск ближайшей ревизии, предшествующей временной метке ССNО. Эта ревизия считается старейшей доступной ревизией объекта, все более старые ревизии удаляются. Процесс сборки мусора завершается удалением списка утилизируемых транзакций вместе с включенными в него объектами.

Временные метки ССNТ и ССNО фрагмента базы данных периодически продвигаются вперед к минимальным значениям временных меток ССNТ и ССNО в других фрагментах базы данных на других узлах. Узлы с помощью вспомогательного системного процесса периодически обмениваются друг с другом сообщениями синхронизации временных меток. В процессе синхронизации вычисляются значения ССNТ и ССNО для фрагмента базы данных своего узла так, как описано выше. Затем собираются значения ССNТ и ССNО с других узлов из других фрагментов базы данных и помещаются в два массива: ССЭТЩ] и ССNО[N], где N - номер узла базы данных. В массивах ССЭТЩ] и ССNО[N] отыскиваются минимальные значения. Временные метки ССNТ и €.'€'N0 собственного фрагмента базы данных продвигаются вперед до этих минимальных значений. Полученные значения ССКГ и ССNО применяются в очередной сборке мусора.

Узел может содержать фрагменты нескольких баз данных. Это значит, что пара массивов ССКГЩ] и ССNО[N] существует в каждом фрагменте каждой базы данных, и на узле этих пар может быть много. Вспомогательный системный процесс узла обновляет все пары массивов всех фрагментов всех баз данных.

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

Все перечисленные способы могут использоваться в любой комбинации. Рассмотрим их на примере масштабирования системы, показанной на фиг. 13, до вариантов, показанных на фиг. 14. Общие для всех фигур чертежей детали системы: клиенты 21, посылающие запросы в вычислительную сеть клиентов 22 на устройство балансировки запросов 23, узлы-координаторы 184, принимающие запросы клиентов с устройства балансировки запросов 23 через вычислительную сеть клиентов 22, узлы-участники 183, соединенные с узлами-координаторами 184 через вычислительную сеть узлов 24 и обрабатывающие команды узлов-координаторов 184. На фиг. 13 узлы N4 и N5 работают в роли координаторов транзакций, узлы N1 и N2 работают в роли участников транзакций.

Вариант масштабирования 185 на фиг. 14 представляет собой систему, в которую добавлен узелкоординатор N6. Новый узел N6 не участвует в хранении данных, поэтому добавление узла выполняется очень быстро - достаточно включить новый узел в вычислительную сеть клиентов 22, вычислительную сеть узлов 24 и зарегистрировать узел на устройстве балансировки запросов 23. Добавление узла в роли координатора транзакций позволяет перераспределить создаваемую клиентами нагрузку, уменьшить время ответа системы и в итоге - повысить готовность базы данных. Удаление узла-координатора позволяет высвободить избыточные ресурсы, когда нагрузка на систему спадает.

Вариант масштабирования 186 на фиг. 14 представляет собой систему, в которую добавлен узелучастник N3.

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

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

Если узел добавляется в карту размещения вторичного индекса или удаляется из нее, выполняется

- 21 027808 перераспределение вторичного индекса среди узлов базы данных. В зависимости от размера вторичного индекса и объема перемещаемых данных, перераспределение вторичного индекса может занимать некоторое ощутимое для клиентов базы данных время. В течение этого времени база данных может быть доступна клиентам только на чтение или не доступна.

Если узел добавляется для хранения данных файлов, в схеме размещения файлов создается новое правило размещения новых файлов. Схема размещения файлов аналогична показанной на фиг. 7 карте размещения первичного индекса с той лишь разницей, что вместо распределений с диапазонами в схеме размещения файлов задаются правила распределения файлов среди набора узлов. Каждое правило включает список узлов и размер блока данных, непрерывно записываемый на каждый узел и дублируемый на соседнем узле (или соседних узлах) в соответствии с заданным в конфигурации базы данных уровнем резервирования. Таких правил может быть много. Последнее по времени создания правило применяется для вновь создаваемых файлов. Остальные правила являются историческими и применяются для чтения и записи уже созданных файлов.

Таким образом, реализуются все перечисленные выше способы масштабирования базы данных в настоящем изобретении.

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

Изобретение раскрыто в некоторых вариантах реализации. Должно быть очевидно, что раскрытое устройство может быть реализовано с модификациями, не отступая от изобретения. Приложенная формула изобретения покрывает все множество вариаций и модификаций, находящихся в рамках сущности настоящего изобретения.

Claims (1)

1. ФОРМУЛА ИЗОБРЕТЕНИЯ

   1. Система управления базой данных, состоящей из объектов, распределенных среди нескольких узлов вычислительной сети, причем упомянутая система выполняет транзакции над объектами и содержит:

   A) средства распределения и постоянного хранения объектов базы данных на нескольких узлах таким образом, что отдельный узел содержит подмножество объектов, причем подмножества объектов любых двух узлов могут пересекаться или не пересекаться, и ни один узел не обязан хранить полное множество всех объектов базы данных;

   B) средства управления прямыми и обратными логическими ссылками между объектами на основе следующего принципа кодирования логических ссылок:

   ί) для каждого объекта создается и поддерживается актуальным логический список обратных ссылок на объекты, содержащие прямые ссылки на данный объект;

   ϊϊ) на хранящем объект узле хранятся ключи всех объектов, ссылающихся на данный объект, причем с каждым из этих ключей ассоциирован список обратных ссылок на объекты, расположенные на данном узле;

   ш) прямые ссылки на объекты, расположенные на других узлах, заменены ссылками на узлы, с которых целевые объекты можно получить по ключу ссылающегося на них объекта;

   C) средства упорядочивания объектов по значениям одного или нескольких полей и распределения копий объектов среди нескольких узлов таким образом, что все множество значений полей, участвующих в упорядочивании, делится на диапазоны, и каждому диапазону ставится в соответствие узел или несколько узлов, где хранятся копии объектов, включенные при упорядочивании в этот диапазон;

   Ό) средства сохранения и извлечения объектов по запросам клиентов базы данных путем передачи между узлами сообщений с командами, причем проверка соответствия объектов условию запроса выполняется на тех узлах, где хранятся копии объектов, без передачи всех требуемых для проверки условия запроса индексных данных и копий объектов на один узел, координирующий выполнение запроса клиента.