Re: Bug#541239: ITP: GT.M -- Database Engine withExtremeScalability and Robustness
On 08/13/2009 03:00 AM, Andreas Tille wrote:
On Wed, Aug 12, 2009 at 05:22:45PM -0400, K.S. Bhaskar wrote:
> GT.M is not optimized for health care applications! In fact, although
> it is increasingly used in health care, it is currently used worldwide
> more in banking / financial applications
Thanks for the clarification. In the past I asked several people
about Mumps and only found a connection to medicine. So just forget
my comment.
> than in health care (including
> what is, to the best of my knowledge, the largest single system real
> time core processing system that is in live production at any bank
> anywhere in the world).
So what about:
GT.M - single system real time core processing system
[KSB] No, the real time core processing banking software is not GT.M but
FIS Profile (http://fis-profile.com), which is an application running on
top of GT.M and which takes advantage of GT.M.
The problem is: We probably have more than 10 "lightwight fast webservers",
"tiny and easy to use editors", "simple and quick image viewers" inside
Debian. These descriptions are advertising features of a software which
are not really helpful for a user who browses the list of packages and
is locking for specific features of a program. The short description
you have choosen in the first place is IMHO not really helpful - at least
it would not be for me.
> 1. Schemaless hierarchical associative memory database engine.
This sounds like a specific feature.
[KSB] Yes. In GT.M, you can write:
Set ^Country("Philadelphia","Pennsylvania")="United States"
Even though it looks like and behaves like an array reference within the
proces, it is also database update that makes the data immediately
available to all processes accessing that dataase.
Software like Amazon Simple DB provide a schemaless associative memory,
but they are not FOSS (in fact, they lock you in to the vendor), and
offer eventual persistence rather than immediate and full Durability.
(A few hundred lines of code on GT.M provides a FOSS API compatible with
Simple DB that you can run anywhere.)
So, GT.M is different from other software in the Debian / FOSS world in
this regard.
> 2. Fully ACID (Atomic, Consistent, Isolated, Durable) transactions using
> an STM (Software Transaction Memory) optimistic concurrency control
> model.
This feature is shown by several other databases in Debian.
[KSB] Yes, ACID transactions have been around for a while, and even
mySQL has them now. The key difference is the software transaction
memory and optimistic concurrency control. So, in GT.M you can write
something like:
TSTart ()
Set ^Savings(ACN,"Balance")=^Savings(ACN,"Balance")+x
Set ^Checking(ACN,"Balance")=^Checking(ACN,"Balance")-x
TCommit
To get full ACID properties, you just bracket the code with transaction
markers and there is no need to lock any resources.
Again, this is an important difference between GT.M and other database
engines in the Debian / FOSS world.
> 3. Databases that scale (and are regularly used in production) to the
> hundreds of GB and small TB range with hundreds to thousands of
> concurrent users.
Other DB engines like PostgreSQL do this as well.
[KSB] OK. I was not aware that databases like PostgreSQL they could
scale to TB databases accessed by thousands of concurrent users on an
x86 GNU/Linux platform. Our users who have run comparative benchmarks
tell us that they get significantly greater throughput on GT.M than on
big name brand relational databases, but I don't know how PostgreSQL
compares with them in throughput.
> 4. Software infrastructure (built on streaming replication) to and
> deploy logical multi-site configurations of applications.
[KSB] This is perhaps the most unique feature of GT.M. The closest that
I am aware of is Oracle's DataGuard, which does not have all the
functionality of GT.M (this feature of GT.M went into live production
use in 1999; Oracle is much more recent).
All of the business logic executes on an originating primary instance.
Updates are streamed from this instance to up to sixteen secondary
instances (there is presently a 20000 kilometer distance limit). Each
of those sixteen can stream updates to sixteen more secondary instances.
And so on.
In the event of a failure, any instance downstream can become the new
originating primary instance within seconds to tens of seconds (in
practice, for network configuration reasons, you would probably want one
of the sixteen connected to the primary instance to become the new
originating primary). So this provides any desired level of application
continuity in the face of unplanned events (such as system crashes,
earthquakes, etc.)
What then makes it even more powerful is the ability to use this
capability to provide application configurations that are available even
in the face of planned events, such as system and application software
upgrades, even application software upgrades that involve a change to
the database schema. (Of course, GT.M provides the hooks that the
application software can use to set this up - GT.M can't do it on the
own). So what this amounts to is the software equivalent of changing
the oil in your car while driving down the highway.
> 5. Compiler for the MUMPS (also known as M) language - it is this that
> attracts the health care IT community and you.
;-)
I think it is perfectly OK to list all these 5 items in the long
description.
I just want to make sure that the short description leaves a glimpse of
the spcifics of GT.M over other database engines.
[KSB] Considering the above, how does this sound:
GT.M Highly scalable and robust associative memory database platform and
MUMPS implentation?
Thanks for all the suggestions.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________
Reply to: