GT.M

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 09:30, 30 января 2019.

GT.M - это платформа разработки приложений баз данных для обработки транзакций в масштабах предприятия, лежащая в основе интегрированного промышленного прикладного пакета Sanchez Profile. Размер баз данных GT.M обычно составляет от 20 до 50 процентов таких же баз, написанных на базе промышленного SQL.

История создания

GT.M, аббревиатура для Greystone Technology M, была разработана Greystone Technology Corp в 1980-х годах. Это реализация стандарта ANSI M для AIX и Linux. В дополнение к сохранению традиционных особенностей M, GT.M также предлагает оптимизирующий компилятор, который создает объектный код, не требующий внутренних интерпретаторов во время выполнения.[Источник 1]

Система управления базами данных GT.M (Greystone Technology M) разработана Greystone Technology Corp. в 1998 г. GT.M - это платформа разработки приложений баз данных для обработки транзакций в масштабах предприятия, лежащая в основе интегрированного промышленного прикладного пакета Sanchez Profile. GT.M поставляется как в комплекте с Profile, так и отдельно, в виде коммерческого продукта. Кроме того, компания Sanchez Computer Associates опубликовала исходные коды СУБД GT.M и компилятора M-языка для x86 GNU/Linux. В комплект дополнительно включены SQL-сервер реляционных запросов Aida с драйверами ODBC/JDBC и пользовательским Java-интерфейсом, набор Delphi-компонентов Visual GT.M и библиотека поддержки CGI-интерфейса. [Источник 2]

Характеристики

  • GT.M представляет собой надежную, высокопроизводительную, мультипарадигменную база данных с открытой архитектурой. К одним и тем же данным может применяться одновременно реляционная, объектно-ориентированная и иерархическая концептуальные модели. Одновременный доступ хост-ориентированных и клиент-серверных приложений к этим данным осуществляется с помощью языков C/C++, SQL и M.
  • Данные GT.M хранятся без учета типа - попросту в виде неструктурированного массива байтов. Взаимосвязи между ними можно в равной степени корректно представить в виде иерархической структуры, многомерных разреженных массивов или контентно-ассоциативной памяти.
  • С точки зрения программирования доступ к содержимому БД осуществляется через постоянные глобальные переменные. Реляционные, объектно-ориентированные и навигационные модели хорошо согласуются с базой данных GT.M, что позволяет подобрать подходящую модель для каждого отдельного приложения или конкретной ситуации. Более того, к одним и тем же данным в одно и то же время применимы несколько моделей, что обеспечивает смешанный (гибридный) одновременный доступ.

Основные свойства

Следующие свойства являются основными для GT.M:

  • Формат. Данные хранятся в собственном формате Sanchez в виде B*-деревьев с высокоскоростным доступом.
  • Конфигурация. Взаимосвязи глобальных имен и диапазонов глобальных имен с диапазонами базы данных определяются при помощи глобальных каталогов.
  • Логические имена. Собственно глобальный каталог, а также все описываемые им диапазоны, могут представлять собой логические имена или переменные окружения, благодаря чему возможна реконфигурация базы данных или ее части без вмешательства в работу приложений.
  • Спецификация динамического глобального каталога. Любое обращение к базе данных может создать собственный глобальный каталог. Поэтому глобальный каталог, используемый в данный момент, может измениться в любое время.
  • Методы доступа. Стандартный метод доступа (Buffered Globals) предоставляет доступ к базе данных с помощью системы кэширования, оптимизированной для быстрой работы БД. Для того чтобы еще повысить производительность, предусмотрен дополнительный метод Mapped Memory, позволяющий отображать целые диапазоны БД на виртуальное адресное пространство.

Для обеспечения дополнительной пропускной способности на некоторых платформах база данных отображается на виртуальную память, доступную посредством 64-разрядных указателей (VLM).

  • Транзакции приложений. Транзакции уровня приложений реализуются посредством меток "начало транзакции" и "конец транзакции".

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

  • Безопасность. Для управления доступом GT.M использует механизмы защиты базовой ОС.
  • Выключение. Выход из СУБД подразумевает запуск утилиты, прекращающей работу всех процессов GT.M и освобождающей всю занятую ею память общего пользования. Диапазоны БД автоматически становятся неактивными при отсутствии обращений к ним пользователя. [1]

Преимущества гибкого моделирования

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

  • средства для составления наиболее полных отчетов работают на платформе Windows/PC и поддерживают реляционную модель. Это подходящая модель для большинства клиент-серверных приложений, а также для экспортирования.
  • иерархическая модель является естественным решением ряда задач, которые в реляционной модели сводятся к патологическим случаям. Например, рассмотрим запрос, в ответ на который нужно получить максимальное время доставки любой детали для любого выпускаемого изделия. Этот простой для GT.M запрос в традиционной реляционной базе данных может отнять кучу времени.
  • объектно-ориентированная модель может использоваться для реализации "вычислений по требованию", если такие вычисления требуют слишком больших затрат, для доступа к нерегулярно запрашиваемым данным, а также к данным, которые постоянно пересчитываются.

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

Гибкая конфигурация

GT.M обеспечивает гибкую конфигурацию базы данных, предоставляя каждому процессу собственное, логически цельное пространство имен глобальных переменных в произвольном количестве файлов БД. Это осуществляется при помощи файла глобального каталога, который либо находится в самом рабочем каталоге, либо задан логическим именем (OpenVMS) или переменной окружения (Unix). Файл глобального каталога определяет соответствие диапазона (ряд имен глобальных переменных) сегменту (файла, заданного по имени или неявно, по логическому имени или переменной окружения). Процесс разработки использует еще один файл базы данных для переменных Accounts и Transactions. Однако для упрощения тестирования он использует базу данных изделий для переменной People, которая имеет доступ только для чтения. Ее файл глобального каталога редко находится в текущем рабочем каталоге и поэтому для обращения к нему требуется логическое имя или переменная окружения. Исполняемые процессы могут изменять глобальные каталоги "на лету", по ходу работы, и даже обращаться к базе данных через специальный, а не через текущий, глобальный каталог. Два глобальных каталога могут устанавливать соответствие между сегментами (описываемыми как одинаковыми, так и различными глобальными переменными) и одним и тем же файлом базы данных. [2]

Другие выгоды, получаемые благодаря GT.M

  • Компактность. Благодаря специфической структуре и использования сжатия ключа базы данных GT.M часто в несколько раз компактнее таких же реляционных БД и традиционных SQL-серверов.
  • Мощность. GT.M поддерживает такие функции, как транзакции на уровне приложений через метки "старт транзакции" и "завершение транзакции".
  • Быстродействие. Базы данных GT.M зачастую обрабатывают транзакции гораздо быстрее (в комбинированном режиме чтения/записи), чем обычные реляционные базы данных. Это преимущество особенно ценно для сильно загруженных систем, поскольку компактность базы данных GT.M снижает нагрузку на систему ввода/вывода, которая иногда является более узким местом, чем центральный процессор.
  • Надежность. В состав GT.M входят такие функции, как обработка исключительных ситуаций, протоколирование событий и восстановление, что позволяет создавать надежные и устойчиво работающие приложения.

Основная проблема GT.M

Рисунок 1 - Аналитика в GT.M

GT.M надежна и обслуживает большое количество специфичных транзакций без каких-либо усилий в отличие, от многих других SQL. Однако все проблемы начинаются тогда, когда нужно сделать простейшую аналитику, передать данные в аналитические системы или автоматизировать процесс. Долгое время решением данной проблемы были постоянные «выгрузки». [Источник 3]

CSV файлы формировались процедурами, написанными на языке M (MUMPS), и каждая такая выгрузка разрабатывалась, тестировалась и внедрялась высококвалифицированными специалистами. Усилия, затрачиваемые на разработку каждой выгрузки, были огромными, а содержимое двух разных выгрузок могло существенно пересекаться между собой. Случалось такое, что заказчики требовали выгрузки, на несколько полей отличные от существующих, и приходилось делать все заново (рисунок 1). При этом сам язык M код достаточно тяжелый для понимания и чтения, что влечет за собой дополнительные «расходы» как на разработку, так и на поддержку. [3]

Ограничения

  • Максимальная длина строки. 32 508 байт.
  • Числовой диапазон. 18 знаков в диапазоне от 10-43 to 1046.
  • Переменные. Длина и количество не ограничены. Выбор сегмента определяется ограничениями на размер файла, существующими в базовой ОС.
  • Максимальная длина ключа. 255 байт.
  • Максимальный размер узла. До 32 Kб для суммы индексов массива и данных для одного M-узла.
  • Максимальный размер блока. Определяется пользователем в диапазоне от 512 до 65,024 байт, кратно 512.

Примечания

Источники

  1. История создания аббревиатуры// Википедия [2018–2018]. Дата обновления: 23.12.2018. URL: https://en.wikipedia.org/wiki/GT.M (дата обращения: 23.12.2018)
  2. История создания GT.M// Комиздат [2018–2018]. Дата обновления: 11.05.2004. URL: http://www.comizdat.com/index_.php?id=217&in=kpp_articles_id (дата обращения: 23.12.2018)
  3. Проблема аналитики в GT.M// ХабрХабр [2018–2018]. Дата обновления: 03.08.2016. URL: https://habr.com/ru/company/rencredit/blog/306954/ (дата обращения: 23.12.2018)

Ссылки

1.comizdat.com
2.fisglobal