Динамически измеряемая распределенная гетерогенная платформа реляционной базы данных

Изобретение относится к системе распределенных баз данных, которые динамически масштабируются в отношения числа серверов, формирующих базы данных, и их топологии, и способу ее работы. Техническим результатом является устойчивость к аппаратной неисправности и повышение производительности. Система распределенных баз данных включает: по крайней мере один сервер порядка действий, который получает задачи с реляционной базы данных сервера порядка действий, применяемой на платформе РСУБД, и управляет повторяющимися запланированными и одноразовыми ситуативными задачами, и запросами базы данных; по крайней мере один модуль управления процессом; несколько серверов баз данных, хранящих данные и выполняющих операции под руководством по крайней мере одного модуля управления процессом; и несколько агентов платформы, каждый из которых предоставляет коммуникационные сервисы платформы клиента базы данных для по крайней мере одного модуля управления процессом под руководством по крайней мере одного сервера порядка действий, при этом по крайней мере один модуль управления процессом передает вызовы удаленных процедур на одном или нескольких серверах баз данных агентам платформы тех соответствующих серверов баз данных, где агенты платформы передают результаты исполнения вызовов обратно на модуль управления процессом. 2 н. и 19 з.п. ф-лы, 3 ил.

 

[0001] Изложенные варианты изобретения относятся, в общем, к системе и способам работы распределенных баз данных, которые динамически масштабируются в отношении числа серверов, формирующих базы данных, и их топологии.

[0002] Распределенная обработка данных включает в себя использование распределенных систем, которые являются системами программного обеспечения, где компоненты, находящиеся на сетевых компьютерах, взаимодействуют и координируют свои действия для достижения общей цели. Хотя распределенные системы имеют множество разновидностей, все распределенные системы используют действующие одновременно или резервные компоненты и восприимчивы к одиночным отказам компонентов. Примеры распределенных систем включают системы баз с сервисно-ориентированной архитектурой, массовые многопользовательские онлайн игры и одноранговые приложения.

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

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

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

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

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

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

[0009] Как минимум один изложенный вариант изобретения представляет систему, которая динамически масштабируется в соответствии с числом серверов, формирующих Распределенную Базу Данных (РБД), и топологию РБД. Таким образом, изложенный вариант изобретения также представляет способы, с помощью которых серверы базы данных могут быть добавлены или удалены без прерывания работы системы, и топология РБД может быть динамически изменена, чтобы соответствовать актуальной необходимости ее пользователей и приложений.

[0010] Как минимум один изложенный вариант изобретения представляет систему, которая устойчива к сбоям на предмет аппаратной неисправности и также устойчива к сбоям на предмет нарушения целостности данных. Так, устойчивость к аппаратной неисправности обеспечивается в виде дублирования копий данных на любом количестве серверов. Более того, изложенный вариант изобретения также представляет способы, которые сохраняют целостность данных, используя принцип пространственно-временного индексирования, который сохраняет и управляет данными в соответствии со временем и положением внутри используемой памяти. Таким образом, хранимые данные могут демонстрировать, какие данные находятся в определенном месте в течение определенного времени.

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

[0012] ФИГУРА 1 иллюстрирует один вариант архитектуры системы РБД, в которой изложенные варианты могут применяться для осуществления улучшений путем замещения различных компонентов и улучшенной функциональности.

[0013] ФИГУРА 2 иллюстрирует один вариант разработки архитектуры системы, который включает стандартно существующую функциональность, связанную с сервером порядка действий, и модуль управления процессом встроен с помощью одного или нескольких процессоров и/или серверов, с дополнительной добавленной функциональностью для связи с по крайней мере одним встроенным сервером баз данных, связанным с каждой платформой, поддерживаемой архитектурой системы.

[0014] ФИГУРА 3 иллюстрирует вариант устройства, которое может использоваться для осуществления или содержания встроенного оборудования функционирования, включая встроенный сервер, используемый в архитектуре системы РБД изложенных вариантов осуществления.

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

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

[0017] Обычные РБД являются, в общем и целом, отдельной базой данных, состоящей из нескольких серверов баз данных в фиксированной топологии сети. Фиксированная топология сети гарантирует целостность и согласованность данных, хранящихся в РБД. Далее, гарантия целостности сохраненных в РБД данных требует применения концепции двухфазной фиксации.

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

[0018] Архитектура системы РБД, осуществляемая в соответствии с изложенным вариантом, отличается от обычной топологии сети тем, что она динамична и задается физическим сервер-членом РСУБД, и топология исполнения определяется сервером порядка действий, описанным здесь же. Сервер порядка действий организует выполнение запросов на серверах членов РБД, эффективно создавая другую топологию РБД с каждым выполнением запросов.

[0019] Обычно необходимая двухфазная фиксация не требуется в РБД рассматриваемых вариантов, так как пространственно-временной фактор хранения данных и схема классификации применяется в рассматриваемых вариантах. Более конкретно, схема пространственно-временного хранения является, как минимум, пятимерным индексом, включающим идентификатор объекта, время и трехмерную пару пространственных координат, а также детализацию конечного времени, когда данные были введены в сервер-член РСУБД. Данная схема адресации эффективно отвечает на запрос "Какие были данные в это время и в этом месте, и когда они стали видны?" В результате, последнее время детализации делает обычно необходимый транзакционный протокол двухфазной фиксации не нужным.

[0020] Изложенные варианты изобретения представляют динамически масштабируемую распределенную гетерогенную платформу реляционной базы данных, используемую для сбора и распространения информации. Распределенная База Данных (РБД) представляет собой репозиторий данных, состоящий из двух или более Реляционных Систем Управления Базами Данных (РСУБД), установленных на компьютерных серверах, которые могут быть территориально рассредоточены.

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

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

[0023] Пространственно-временное индексирование исключает необходимость применения двухфазной фиксации, обычно реализуемой в РБД, что соответствует современному состоянию техники. Рассматриваемые варианты поддерживают данные РБД в шестой нормальной форме, как описано у К.Дж. Дэйта, Временные Данные и Реляционная Модель, Морган Кауфманн, 2002.

[0024] В соответствии с изложенными вариантами, грид-архитектура баз данных обеспечивает устойчивость к аппаратной неисправности путем распределения данных по нескольким серверам для формирования сегментов данных и реплик данных.

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

Чисто теоретически, сегмент данных может рассматриваться как горизонтальная секция в РБД. Таким образом, каждая отдельная область может рассматриваться как сегмент базы данных.

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

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

[0028] Расположения сегмента данных сервера определяются с использованием линейного хеширования. РБД, представленная в соответствии с рассматриваемыми вариантами, представляет одинаковые функциональные сегменты данных и концепции реплик данных (реплика данных представляет собой копию данных, которая имеет центральное значение на другом сервере) распределением данных среди множества серверов, но не использует сегмент данных или концепцию реплик данных. Однако, в соответствии с рассматриваемым вариантом, данные разделены на части и хранятся на нескольких серверах, согласно пространственно-временной концепции, описанной выше.

[0029] Эта стратегия создает радиально-базисную схему хранения, основанную на пространственных характеристиках данных. Однако, в соответствии с рассматриваемым вариантом, несколько РСУБД серверов могут иметь частично совпадающее пространственное хранение, что создает естественное копирование данных, которое отличается от грид-реплик данных тем, что копированные данные присваиваются не определенному серверу, а пространству внутри РБД. Таким образом, пространства хранения внутри РБД могут быть повторяющимися среди нескольких экземпляров сервера.

[0030] При осуществлении, рассматриваемые варианты могут быть использованы для улучшения производительности архитектуры системы, как показано на ФИГ. 1, где системная архитектура РБД 100 включает в себя как минимум один Бэк-офис Сервер Базы Данных 105, сервер порядка действий 110, модуль управления процессом 115, приводимый в действие с помощью одного или более процессоров и/или серверов, и как минимум один встроенный сервер базы данных 120.

[0031] Бэк-офис Сервер Базы Данных (БСБД) 105 хранит данные, собранные со встроенного сервера базы данных 120. Сервер порядка действий ПО представляет собой механизм планирования задач, используемый для удаленного планирования исполнения задач на удаленных серверах. Модуль управления процессом 115 выполняет задачи, представленные сервером порядка действий на удаленных серверах, согласно Вызовам Удаленных Процедур (ВУП), и отсылает обратно статус успеха или неудачи ВУП. Встроенный сервер базы данных собирает данные, производимые системой управления поездом, системой контроля за поездом и системой помощи машинисту (например, коммерчески доступные системы марки New York Air Brake торговой марки "LEADER").

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

[0033] Таким образом, рассматриваемые варианты могут использовать модуль управления процессом для передачи ВУП для выполнения на удаленном сервере подходящему агенту платформы удаленного сервера; в результате этот агент платформы передает результаты исполнения ВУП обратно на модуль управления процессом. Агенты платформы могут использовать простую клиент-серверную архитектуру на основе сокета.

[0034] Различные РСУБД платформы используют свои собственные протоколы для связи. Более того, различные РСУБД платформы также используют свои собственные SQL синтаксические условные обозначения. Агенты платформы устроены так, чтобы пересылать протокол и синтаксис определенных задач РСУБД платформы таким образом, что платформа настроена на термины протоколов связи и синтаксических условных обозначений. Так, агент платформы Oracle устроен так, чтобы принимать сообщение от сервера порядка действий и преобразовывать это сообщение в сохраненную программу исполнения ВУП, допускаемую РСУБД Oracle, и затем вернуть результаты данного выполнения обратно на сервер порядка действий. Таким же образом, агент платформы Informix предоставляет сервисы для реализации РСУБД Informix. Добавление новой РСУБД платформы к РБД является просто вопросом добавления агента платформы на данную платформу. Это обеспечивает прозрачный межсетевой переход РСУБД для всех РСУБД серверов с разрешением РБД функционировать всем членам серверам вместе в одном комплексе.

[0035] Различные платформы могут поддерживаться такой стратегией агента платформы, включая, например, Oracle, Sybase, PostgreSQL, Informix, MySQL, IrmniDB, DB2, MariaDB, Percona и SQL* Server.

[0036] Соответственно, как показано на ФИГ. 2, рассматриваемые варианты обеспечивают производительность архитектуры системы, которая включает стандартно существующую функциональность, связанную с сервером порядка действий 210, и модуль управления процессом 215 встроен с помощью одного или нескольких процессоров и/или серверов, с дополнительной добавленной функциональностью для связи с по крайней мере одним встроенным сервером баз данных 220, связанным с каждой платформой, поддерживаемой архитектурой системы.

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

[0038] Например, как показано на ФИГ. 2, удаленные серверы баз данных 230 могут быть использованы на различных платформах сервера базы данных, создавая распределенную гетерогенную сеть баз данных. Таким образом, как показано в ФИГ. 2, сервер базы данных MySQL 23 ОС может быть использован на платформе MySQL. Такой удаленный сервер базы данных MySQL 230С обеспечивает и гетерогенную распределенную структуру базы данных, и также предоставляет связь с несколькими серверами, например, встроенными серверами MySQL 230С. Таким образом, эти встроенные серверы MySQL 230 могут быть динамически добавлены или удалены из сети 200. Как описано ниже, в одной возможной реализации, каждый из этих встроенных серверов MySQL 23 ОС (или любых других серверов 230 A-D) может обращаться за данными на сервер, размещенный в поезде или локомотиве или другом транспортном средстве, от которого ожидаются данные. Такая реализация особенно полезна, так как присоединение и перемещение таких встроенных компонентов может быть необходимо в результате запускания в эксплуатацию или отключения поезда.

[0039] Использование серверов порядка действий и других компонентов рассматриваемых вариантов создает возможность концепции динамической топологии РБД. Причина, по которой топология динамична в том, что определенные серверы (например, те, что расположены удаленно на поездах), могут быть недоступны к адресации запроса через агент платформы. Серверы постоянно включаются в сеть и выходят из сети. Так, топология может потенциально меняться в зависимости от и для каждого индивидуального запроса и основываясь на серверах, которые находятся в сети и выключены из сети (и в постоянном, и во временном режиме).

[0040] Единственное требование состоит в том, чтобы удаленный сервер базы данных 230A-D имел модель данных, которая будет сопоставима с моделями данных, используемых на других платформах, например, Oracle, Sybase, PostgreSQL, Informix, MySQL, IrifiniDB, DB2, MariaDB, Percona и SQL* Server. Другими словами, каждая платформа должна иметь составляющие компоненты или процессы, которые могут проецироваться на другие составляющие компоненты или процессы других платформ.

Вышеописанное применение агентов платформы является результативным механизмом для получения таких функциональных возможностей. Таким образом, модуль управления процессом 215 передает ВУП для выполнения на каком-либо удаленном сервере 230A-D на подходящем данному удаленному серверу агенте платформы 225A-D. Последующее исполнение на одном из удаленных серверов 230A-D является результатом того, что агент платформы 225A-D передает результаты выполнения ВУП обратно на модуль управления процессом 215, используя простую клиент-серверную архитектуру на базе сокета и/или файловую.

В этом случае, модуль управления процессом 215 реализуется как динамически масштабируемая гетерогенная сеть процессоров управления, которая принимает задачи со связанного сервера порядка действий 210 и координирует удаленные выполнения ВУП между удаленными серверами баз данных 230A-D.

[0041] В соответствии с рассматриваемыми вариантами, сервер порядка действий 210 может использоваться как комплекс таблиц реляционной базы данных и связанных хранимых процедур, и может быть использован на любой из вышеуказанных платформ баз данных. Система 200 может включать один или несколько серверов порядка действий 210. Серверы порядка действий 210 могут быть динамически добавлены и удалены из распределенной сети баз данных.

[0042] Каждый сервер порядка действий 210 получает свою задачу для выполнения от реализации реляционной базы данных сервера порядка действий, которая может быть реализована на любой платформе РСУБД.

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

[0044] Следовательно, рассматриваемая архитектура системы 200 включает динамически масштабируемую гетерогенную сеть агентов платформы 225, которая обеспечивает коммуникационные сервисы особой платформы клиента базы данных с модулем(ями) управления процессом 215 под руководством сервера(ов) порядка действий 210.

[0045] Модуль(и) управления процессом 215 может применяться в качестве изолированных выполняемых программных инструкций, работающих на одном или нескольких серверах. Каждый модуль управления процессом 215 получает задачи для выполнения на удаленных серверах баз данных 230A-D со связанного сервера порядка действий 210. Модуль управления процессом 215 связан с отдельным сервером порядка действий 210. Однако, несколько модулей управления процессом 215 могут быть связаны с отдельным сервером порядка действий 210 с целью баланса нагрузки и устойчивости к сбоям.

[0046] Модули управления процессом 215 связаны с их соответствующим сервером порядка действий 210 с помощью подходящего агента платформы, так как платформа базы данных применяется на своем сервере порядка действий 210. Модули управления процессом 215 отсылают статус исполнения своих удаленных действий обратно на их связанный сервер порядка действий 210. Модули управления процессом 215 получают свои удаленные задачи для исполнения с помощью опроса связанного с ними сервера порядка действий 210. Сервер порядка действий 210 направляет текущие задачи для исполнения модулям управления процессом 215, и в том числе, если предыдущие задачи для исполнения не были выполнены.

[0047] Модули управления процессом 215 координируют связь между удаленными серверами баз данных 230 в форме "один ко многим", то есть один модуль управления процессом 215 к одному или ко многим удаленным серверам баз данных 230. Соответственно, модуль управления процессом 215 может выполнить ВУП на отдельном удаленном севере базы данных 230 и направить результаты исполнения на один или несколько сервер-адресатов. Таким образом, серверы могут быть добавлены или удалены из архитектуры системы РБД, и можно контролировать их доступность для выбора членов серверов среди архитектуры системы РБД. Это позволяет создать группу внутри группы серверов для осуществления обмена данными друг с другом и контроля доступности данных.

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

[0049] Каждое исполнение задач может содержать любое число сервер-источников, наряду с нулем или несколькими сервер-адресатами, где извлеченные и измененные данные с сервер-источников передаются на все конечные определенные серверы в течение цикла исполнения задач. Данная схема выполнения аналогична операциям Соединяющей Машины Альфа Бета, где операция Альфа, в данном случае, является выполнением сохраненной программы на произвольном числе сервер-источников, а операция Бета является передачей результатов выполнения Альфа, распространяя их по всем сервер-адресатам. См. В. Дэниэл Хиллис, Соединяющая Машина, стр. 62.

[0050] Соответственно, исполнения задач на сервер-источнике и передача данных на сервер-адресат могут отличаться при каждом выполнении, эффективно меняя топологию архитектуры системы РБД с каждым циклом выполнения. Таким образом, и число серверов баз данных 230, и число серверов порядка действий 210, обеспечивающих планирование задач удаленных задач для исполнения на удаленных серверах баз данных в асинхронной форме, динамически масштабируется.

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

[0052] Такое устройство динамического перемещения в сочетании со схемой пространственно-временной организации данных позволяет всей компьютерной системе работать, как гиперсферная реляционная база данных с массовым распараллеливанием. Более того, архитектура системы 200 также имеет в качестве результата динамически масштабируемую гетерогенную сеть модулей управления процессом 215, которые принимают задачи со связанных серверов порядка действий 210 и координируют удаленные исполнения ВУП между удаленными серверами баз данных 230 с помощью агентов платформы 225.

[0053] Так, используя агенты платформы 225, система 200 способна предоставить платформу определенной базы данных клиентских коммуникационных услуг для различных модулей управления процессом 215. Например, агент платформы Oracle 225D выполняет взаимодействие с клиентом Oracle, в свою очередь агент платформы MySQL 225С выполняет взаимодействие с клиентом MySQL.

[0054] Агенты платформы 225 являются легковесными одноранговыми агентами, которые ожидают ВУП по предварительно заданному TCP/IP адресу и порту, посылаемым с модуля управления процессом 215, для ретрансляции на платформу базы данных, которую они обслуживают, по адресу, определенному модулем управления процессом 215. Результаты ВУП исполнения ретранслируются обратно на модуль управления процессом 215 агентом платформы после окончания исполнения.

[0055] Модуль управления процессом 215 затем отсылает полученные результаты вместе с конечными адресами агентам платформы, которые обслуживают сервер-адресаты.

[0056] В конце концов, запрос базы данных выполняется на исходном сервере базы данных, и результаты запроса ретранслируются любому количеству конечных серверов баз данных. Файловый агент посылает командные файлы на исходный сервер базы данных для исполнения и ретранслирует файлы обратно на модуль управления процессом 215.

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

[0058] Расширение реляционного каталога сервером может хранить ограниченный размер (данные могут быть семантически сгруппированы вместе) данных, сохраненных внутри каждого отдельного члена сервера в архитектуре системы РБД.

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

[0060] Соответственно, должно быть понятно, что отдельные серверы порядка действий 210 могут принимать свои задачи путем постоянного опроса РСУБД, с которой они связаны при помощи подходящего для данной РСУБД агента платформы (агенты платформы описаны в разделе три).

[0061] Форма представления исполнения задач может быть двухсторонней, список левосторонних (LHS) серверов-источников, и правосторонних (RHS) серверов-адресатов. Таким образом, в одном из применений, сервер порядка действий может начать процесс исполнения с представления ВУП как сохраненной программы исполнения на всех LHS серверах, используя подходящие агенты платформы для каждого сервера. Агенты платформы могут затем передавать результаты исполнения с каждого LHS сервера обратно на сервер порядка действий, который представляет сохраненную программу исполнения ВУП на каждом RHS сервере, снова используя подходящий агент платформы для каждого RHS сервер-адресата. Сервер порядка действий может затем сообщить об успехе или неудачи исполнения на базу данных порядка действий и далее провести опрос в данной базе данных на предмет другой задачи для исполнения.

[0062] В этом случае, неудачные исполнения могут быть предприняты повторно как новые исполнения, пока все исполнения LHS и RHS не будут иметь успех. В результате, серверам порядка действий не надо сохранять никакие данные статусов ошибок для исполнения задач, так как эта информация предоставляется базой данных порядка действий всей архитектуры системы.

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

[0064] Положительный Контроль Движения Поезда (РТС) относится к обычной общеизвестной технологии, которая разработана для предотвращения столкновения между поездами, схода с рельсов из-за превышения скорости, несчастных случаев или ранений работников железнодорожного полотна, работающих в пределах разрешенных ограничений, в результате несанкционированного вторжения поезда, и также предотвратить движения поездов по стрелке, оставленной в неправильном положении. Хотя системы РТС сильно различаются в сложности и степени детализации, основанной на уровне автоматизации и функционала, который они выполняют, используемой архитектуре системы и уровню контроля поезда, которому они могут соответствовать, системы РТС нетерпимы к противоречиям, в том, что это системы сигнализации и контроля поездов на базе процессора (см. Заголовок 49 Свода нормативных актов, Часть 236, Глава Н), которые используют и компьютерные, и радио каналы связи для осуществления функций РТС, таких как наблюдение и контроль движений поезда для обеспечения повышенной безопасности.

[0065] Более конкретно, РТС требует, чтобы поезд получал информацию о своем местоположении и безопасном пути следования, то есть "команду на движение". Оборудование в поезде улучшает эти команды на движение и при этом препятствует небезопасному движению. Системы РТС используют Глобальную Спутниковую Навигационную систему (GPS) для отслеживания движения поезда. Таким образом, РТС используется для обеспечения интервального регулирования поездов или предотвращения столкновений, контроля максимальной скорости, временного ограничения скорости и гарантии безопасности работников железнодорожного полотна.

[0066] ФИГ. 3 иллюстрирует вариант устройства, которое может использоваться для осуществления или содержания встроенного оборудования на поезде, включая встроенный сервер, используемый в архитектуре системы РБД изложенных вариантов осуществления. Таким образом, для осуществления РТС задач интеллектуальная система поезда, обеспечивающая осуществление задач на встроенном сервере, может включать (но не ограничиваться) оборудование, показанное на ФИГ. 3. Относительно реализации, интеллектуальная система поезда 300 может включать один или несколько компьютерных блоков обработки данных 305, которые могут быть соединены с памятью 310 (применяемой в качестве общеизвестных и коммерчески доступных программируемых и/или доступных только для чтения или перепрограммированных устройств памяти) Память 310 может служить для хранения компьютерных инструкций, связанных с или реализующих и контроль программного обеспечения 315 и операционной системы, или окружающей среды 320 для предоставления задач, включенных в одно или несколько компьютерных приложений, и закодированный пакет программного обеспечения и/или различные названные или включенные подпрограммы. Эти инструкции могут использоваться для осуществления инструкций, включенных в способы и определения, описанные выше.

[0067] Более того, интеллектуальная система поезда может также включать один или несколько коммуникационных портов 325, которые позволяют и принимать и передавать сообщения и сигналы (как сигнал, полученный от радиопередатчика на дороге), данных и инструкции по контролю в соответствии с рассматриваемыми вариантами. Далее, интеллектуальная систем поезда 300 может включать человеко-машинный интерфейс 330, который может включать, например, дисплей, позволяющий оператору получать и просматривать данные, используемые или выработанные интеллектуальной системой поезда 300, предоставлять инструкцию или вводить указание для контроля над программным обеспечением 315, получать доступ к данным, включенным в память 310, и т.д. В результате, человеко-машинный интерфейс 330 может также включать другие общеизвестные характеристики, включая клавиатуру, мышь, сенсорную панель, различные кнопки и переключатели, и т.д.

[0068] Различные преимущества могут быть достигнуты при анализе и получении доступа к данным, полученным в результате использования РТС системы, например, информация, полученная и проанализированная РТС системой, может разрешить встроенным или внешним системам контролировать поезд и входящий в его состав локомотив для увеличения топливной эффективности и осуществления диагностики локомотива для усовершенствования обслуживания. Так как данные, используемые РТС системой, передаются беспроводным способом, другие приложения также могут использовать эти данные.

[0069] Таким образом, дальнейшее применение осуществляется благодаря использованию и наличию доступа к оборудованию, показанному в ФИГ. 3 в комплексе с архитектурой системы РБД и способами, изложенными здесь же.

[0070] Должно быть понятно, что различные соединения между элементами предлагаются здесь в описании, следующем далее; однако, эти соединения в общем, и если не предусмотрено иное, могут быть как прямыми, так и непрямыми, как постоянными, так и кратковременными, и как целевыми, так и общими, и эта характеристика не предназначена для ограничения в этом отношении.

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

[0072] Также, должно быть понятно, что функциональность, описанная в связи с различными описанными компонентами различных вариантов изобретения, соединенными или разделенными таким способом, что архитектура изобретения окажется чем-то другим, чем однозначно изложенное в данном документе. Более того, должно быть понятно, что если не предусмотрено иное, не существует обязательного требования, чтобы способ операций был представлен в показанном порядке; так, специалист в данной области техники определит, что некоторые операции могут быть представлены одним или несколькими другими порядками и/или синхронно.

[0073] Различные компоненты изобретения могут быть применимы в других комбинациях, работающих с ними, под контролем или в сочетании с различными другими сущностями или физическими лицами.

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

[0075] В результате, очевидно для специалистов в данной области техники, что описанные иллюстративные варианты являются только примерами, и что могут быть сделаны различные изменения в рамках объема изобретения, как отмечено в прилагаемой формуле изобретения.

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

по крайней мере один сервер порядка действий, который получает задачи для исполнения с реляционной базы данных сервера порядка действий, применяемой на платформе РСУБД, отличающийся тем, что по крайней мере один сервер порядка действий управляет и повторяющимися запланированными задачами, и одноразовыми ситуативными задачами, и запросами базы данных;

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

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

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

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

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

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

4. Система по п. 1, отличающаяся тем, что

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

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

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

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

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

9. Система по п. 1, отличающаяся тем, что каждый из множества агентов платформы связан с одной из платформ Oracle, Sybase, PostgreSQL, Informix, MySQL, InfiniDB, DB2, MariaDB, Percona and SQL* Server.

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

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

по крайней мере один агент-сервер, который получает задачи для исполнения с реляционной базы данных сервера порядка действий, применяемой на платформе РСУБД, отличающийся тем, что по крайней мере один сервер порядка действий управляет и повторяющимися запланированными задачами, и одноразовыми ситуативными задачами, и запросами базы данных;

по крайней мере один модуль управления процессом, принимающий задачи для исполнения с по крайней мере одного связанного сервера порядка действий;

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

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

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

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

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

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

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

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

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

серверу, а пространству внутри архитектуры системы.

19. Способ по п. 11, отличающийся тем, что каждый из множества агентов платформы связан с одной из платформ Oracle, Sybase, PostgreSQL, Informix, MySQL, InfmiDB, DB2, MariaDB, Percona and SQL* Server.

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

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