Re: Bug#541239: ITP: GT.M -- Database Engine withExtremeScalability and Robustness
Comments below. Look for [KSB2].
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
On 08/13/2009 04:50 PM, Karsten Hilbert wrote:
On Thu, Aug 13, 2009 at 04:03:11PM -0400, K.S. Bhaskar wrote:
> [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.
No, it is not. In PostgreSQL you do exactly the same thing.
[KSB2] Thanks for the clarification.
> 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).
Huh ? How is this enforced ? Measuring wire lag ?
[KSB] GT.M only needs a TCP/IP connection for streaming.
Since the circumference of the earth is 40000 kilometers, you cannot get
more than 20000 kilometers between systems, unless you construct a data
center in space - in which case the construction costs would be
astronomical! 8-)
From a practical point of view, the greatest separation between an
originating primary instance and a replicating secondary instance that I
know of in production today is around 2000 kilometers. By the end of
the summer, I expect someone to have a separation of around 3500
kilometers. So far, all those who have multiple instances have kept
them on the same continent.
> 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.)
Sounds pretty much like Aster.
http://www.intelligententerprise.com/blog/archives/2008/07/open_source_as.html;jsessionid=VOG4M2IPJ1XEDQE1GHOSKHWATMY32JVN
[KSB2] Actually, they are very different.
While I cannot say what "a series of patent-pending algorithms and
processes that optimize the placement, partitioning, balancing,
replication, and querying across a cluster of intelligent nodes" [quote
from the URL] means, Aster focuses on business intelligence / data
warehousing, which is very different from transaction processing. With
GT.M, you can certain run queries on the various instances, even though
business logic (i.e., updates) can only be executed on one instance.
Also, GT.M has the ability to run these on heterogeneous machines,
operating systems and GT.M versions, and even different application
versions with different schema during a rolling upgrade that keeps the
application available even as it is upgraded.
<...snip...>
_____________
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: