GT.M is a high-throughput key–value database engine optimized for transaction processing. (It is a type also referred to as "schema-less", "schema-free", or "NoSQL".) GT.M is also an application development platform and a compiler for the ISO standard M language, also known as MUMPS.
GT.M, an abbreviation for Greystone Technology M, was developed by the Greystone Technology Corp in the 1980s. It is an implementation of ANSI standard M for AIX and Linux. In addition to preserving the traditional features of M, GT.M also offers an optimizing compiler that produces object code that does not require internal interpreters during execution.
The database engine, made open source in 2000, is maintained by FIS. GT.M is used as the backend of their FIS Profile banking application, and it powers banks in Spain, France, Italy, the Netherlands, Romania and India; Capital One 360 in the United States; Tangerine (Scotiabank) in Canada; Atom Bank; Tandem Bank; Sainsbury's Bank; Scottish Widows and Barclays Direct in the UK. It is also used as an open source backend for the Electronic Health Record system WorldVistA and other open source EHRs such as Medsphere's OpenVista. It is listed as an open source healthcare solution partner of Red Hat. Today it consists of approximately 2 million lines of code.
Technical overview
GT.M consists of a language subsystem, a database subsystem, and utility programs. The language subsystem and database subsystem are closely integrated, but each is usable without the other. The language and database subsystems share common data organization and typing.
Data organization and typing
Like MUMPS, GT.M has no real concept of different data types, though strings (those which are not fully numeric) must be placed in quotes to differentiate them from variables. Numbers can be treated as strings of digits, or strings can be treated as numbers by numeric operators (coerced, in MUMPS terminology). Data is treated based on context and the rules of GT.M: 1+"42" yields the result 43, the first character of 43 is 4, and 20+"30 DUCKS" is 50 (as non-numeric characters are dropped during numeric operations).
There is only one data structure - multi-dimensional sparse arrays (key-value nodes, sub-trees, and associative memory are all equally valid descriptions) with up to 32 subscripts. A scalar can be thought of as an array element with zero subscripts. Nodes with varying numbers of subscripts (including one node with no subscripts) can freely co-exist in the same array. For example, if one wanted to represent the national capitals of the United States: Set Capital("United States")="Washington" Set Capital("United States",1774,1776)="Philadelphia" Set Capital("United States",1776,1777)="Baltimore"
Variables are created on demand when first assigned to. Thus, the first Set command above would create the variable Capital. Variables have scope in the language, and are called local variables. A database access looks like an array access, for example: Set ^Capital("United States")="Washington" but the caret (^) means that it is a database access. Variables used for database access have a single global scope, and of course persist and shared between processes. They are called global variables. The first 31 characters of a variable name are significant.
The Kill and ZKill commands are used to delete subtrees of values.
GT.M uses Unicode (ISO/IEC-10646) for international character set support.
Database subsystem
The logical database of a GT.M process consists of one or more global variable name spaces, each consisting of unlimited number of global variables. For each global variable name space, a global directory maps global variables to the database files where they actually reside. An unlimited number of global variables can fit within one database file; a global variable must fit in one database file.
A database file consists of up to 224M (276,168,704) database blocks. A database block is a multiple of 512 bytes, with a maximum size of 65,024 bytes. Commonly used block sizes are 4KB, 8KB and 16KB - so, with an 8KB block size, an individual global variable can grow to 1,792GB. A global variable node (global variable, subscripts plus value) must fit in one database block and each block has a 16 byte overhead. So, the largest node that will fit in a database with a 4KB block size is 4,080 bytes. A key (global variable plus subscripts) can be up to 255 bytes.