InterSystems, producers of the Caché database, have launched Globals, a fast, proven, simple, flexible and free databases, 2 months ago. But after the initial announcement, I couldn’t find and didn’t hear much about it. This until Rob Tweed and K.S.Bhaskar took the time to explained some of the differences between InterSystems Globals and GT.M, both systems being implemented on top of the MUMPS Global Persistent Variables .
Rob Tweed: I’m not an InterSystems person — simply a long-term user and advocate of Global-storage based technologies of which GT.M, Cache and now InterSystem Globals are members, and someone who has long believed that it’s a significantly under-valued database technology, and unfortunately and sadly not known about or understood sufficiently in the wider database/IT world. However, the rise of NoSQL has provided some renewed chance of rediscovery by a wider community of developers, which I’m keen to encourage.
With respect to a comparison with BigTable etc, I guess all of us in the Global-storage technology user communities have looked at many of the new NoSQL technologies and thought it’s deja vu all over again :-) Perhaps this paper that I co-authored might help to at least provide a comparative positioning against the “mainstream” NoSQL databases.
As we note in the paper, full-blown Cache and GT.M provide many of the mechanisms needed for high-end scalability, though, as you point out, many of these appear to be lacking in InterSystem Globals, at least in its current (and relatively early) incarnation.
Regarding a comparison of InterSystem Globals and GT.M, at the core data storage level, there’s little difference: they both use Globals for data storage, so the use cases will be similar. Both GT.M and Globals are implemented in C (instead of M/Mumps), with some small bits of GT.M glue code in assembler. In terms of licensing, InterSystem Globals is free but proprietary, GT.M is free open source.
I guess the biggest differences are:
InterSystem Globals is essentially the core database engine from Cache, but with many of the features of Cache, in particular its native language (M) turned off. The concept in InterSystem Globals is that it will be accessed via APIs from other mainstream languages, instead of being primarily accessed via the M language as is the norm in, say, GT.M
K.S.Bhaskar: Although the majority of GT.M users do indeed program in M, the fact is that the GT.M database is just as accessible from a C
(KSB) As discussed above, GT.M does not restrict a user to TCP access. The primary restriction (which results from the fact that the database engine is daemonless and processes cooperate to manage the database - so there is a real time database engine linked into each processes’ address space) is that a GT.M process can have only one thread. If you can’t live with this, then you have to use TCP through a client such as Rob’s.
Another option is to use the GT.CM “database service” that GT.M includes (GNP - the GT.M Network Protocol is layered on TCP). A client is coded within GT.M itself, or you can use/adapt other clients for GNP such as Dave H’s PHP gtcmclient.
(RT): I suspect one way things will pan out over coming months will be:
- If you want the ultimate in performance and willing to sacrifice open source and the high-end scalability options, but remain free, then InterSystem Globals will be a good choice
If you want the former but are willing to pay for the extra high-end scalability technologies, then full-blown Cache will be your choice.
(KSB) This is a false choice. GT.M gives you high end scalability with a free / open source license (and support with assured service levels on commercial terms for those who want it).
(RT) The nice thing is that it will be straightforward to engineer applications that can be easily migrated between these three options with a minimum of change being needed at the application level.
Personally, I think InterSystem Globals is a great thing and nice to see InterSystems venturing into a new direction: I think that’s only to be encouraged and can only help the NoSQL community.
The text of this post has been adapted and edited based on this conversation .